PIC16F677: Mysterious clock period loss in SPI slave mode

[koesterk]

Hi guys,

I found a mysterious phenomenon in the PIC16F677 while running in SPI slave mode (CKE=0, CKP=1). Above a certain incoming SPI clock speed I can't hit the short period between "Buffer Full" and the first bit latch of the next byte any more. The CPU is running at 8 MHz and a stream of 5 bytes is coming in/going out on a continuously running clock (this is mandatory for my application).

The test software I wrote is rather trivial: Waiting in an endless loop for "BF" becoming active, then just a simple port toggler.

For SPI clocks below 80 kbps it works fine. The delay between the last bit latching and the port toggler is measured to ~4µs. In this case there is enough time to read the incoming RX byte and write the next TX byte to SSPBUF before the first bit of the next byte is latched.

Above 80 kbps the time between the rising edge of the last bit and the port toggler increases by approx. one SPI clock period, i.e. at least 14..15 µs. In this case I have no chance to fill the SSPBUF in time (100kbps = 10 µs clock period).

Quite interesting that I2C works fine on this device with 100kbps.

Does anybody have an idea why the SSP interface generates its interrupt delayed by one period? I played on master side with the latency between SS becoming active and the first bit going out but it does not help. Are there any restrictions regarding SPI that might cause such an effect?

Thanks a lot and best regards
Klaus

[/code]

[RLScott]

I assume that interrupts are disabled and that your tight loop waiting for BF is as tight as possible, such as:

[Guest]

Robert

first of all thank you very much for your reply. I did exactly what you assumed: A while loop waiting for the interrupt flag going high and a port toggler afterwards. In total I can expect a maximum latency of 3..4µs.

When I made my measurements I started with 50.000 bps and increased the value in steps of 10.000. Up to 80.000 bps I saw what I expected: roundabout 4 µs delay between last SPI bit latched and the port pin going up. For 90.000 bps I saw an overall delay of ~15µs, for 100.000 bps I measured 14 µs.

In my application the controller sleeps most of the time an wakes up by SPI data coming in. Above a certain limit (between 80k and 90k) it seems that the SPI peripheral loses one SPI clock cycle (i.e. 11µs @ 90k, 10µs @ 100k !!!).

I already reported this behaviour to Microchip. Until now they haven't answered yet. It seems to me that it was a good question. ;-)

I found a similar behaviour described in the errata of the F677, but with a different SPI setup. Unfortunately the described workaround does not work in my case.

Anyway, meanwhile I could convince my colleagues programming the SPI master to accept 50k as maximum speed. Thus, I could finish my software today. When Microchip replies I will forward their answer to this forum. I fear it's a bug in the SSP state machine but let's wait what they write.

Thanks again and best regards
Klaus