SPI garbage

[shantanu@india]

Hi,
32 bytes are being exchanged in SPI mode between a ESP8266 and a 18F24K22 @1 sec. All 32 bytes are supposed to be utf-8/ascii. The ESP is the master and is bit banged. The PIC MSSP module is generating interrupt to read the bytes received and write back the data. The SCK is 100 kHz. Strangely, after 2/3 hours of perfect communication the ESP is starting to read non-ascii garbage. Restarting the ESP doesn't solve the problem, restarting both together solves the problem.
Should I restart the MSSP module after every communication block of 32  bytes to force synchronization? I have used a resistive attenuator at the MISO pin of the ESP to reduce from 5.0V to 3.3V level.
Any ideas?

[trastikata]

If it is a SPI communication, then it is synchronized by the CS pin?

Try to stretch the clock's active phase also introduce delay after the change on CS pin. I found out for myself that (for different devices) the rise and fall times on bit banged pins are not as on dedicated hardware SPI modules and cause troubles at high MCU clock speed.   

[shantanu@india]

Thanks Trastikata.
Actually I'm not using CS due to pin shortage.

[RGV250]

Hi Shantanu,
Not sure if you have just missed this bit out, you say you have tried resetting the ESP and both but have you tried just resetting the PIC on its own?

Bob

[tumbleweed]

Actually I'm not using CS due to pin shortage.

That could be a problem. The SPI slave select (SS) resets the bit clock counter, and without it there's no way for the slave to get back into sync with the master short of resetting the MSSP module.

One glitch on the SPI CLK and you won't know whether a byte is valid or not, so it's hard for the slave to detect when to reset the module... you may not get your 32-byte packet.

This is especially bad at powerup/resets when the master and slave are initializing the pins. Without the SS, if the slave is setup before the master it can get out of sync right off the bat.

[top204]

I've used address only SPI interfaces in the past because I had no pins left on an 80 pin device, and the slave firmware has to be very carefully written with timeouts etc, and a packet mechanism to verify what was sent had the correct reply, to stop losing sync. It worked well for 80 boards being communicated with sequentially, but the master also had to be written carefully to help prevent sync loss.

The CS line mechanism removes all the sync issues because when it is high, the SPI peripheral can be reset or its buffer flushed, if required.

[trastikata]

If the CS is not available, you still have to use at least 2 pins - then can you not convert to USART (either software or hardware) - this will take care of the clock sync loss?

[tumbleweed]

You could, but probably not at 100KHz with a software UART. Plus, on the receive side a software UART is problematic. Not the most reliable of methods.

[trastikata]

Another thought - if the data is 32 bytes and being sent every second, then you can reset the MSSP module when a pause larger than X milliseconds is detected.

[shantanu@india]

Another thought - if the data is 32 bytes and being sent every second, then you can reset the MSSP module when a pause larger than X milliseconds is detected.

Exactly what i am thinking

[shantanu@india]

Getting much better results by a 3-pronged strategy:
1) Making the MSSP interrupt and the the UART interrupt mutually exclusive(time displaced ). The PIC reads the modbus data only after completion of a SPI read/write cycle of 32 bytes.
2) Reducing the SPI communication rate from 100kHz to 50kHz
3) Resetting the MSSP module after every communication cycle.
My take on SS pin is that it is not essential. Otherwise Microchip wouldn't have provided a 'Slave without SS pin' mode in the SSP1CON1 register configuration. SS pin is required when the SPI master communicates with multiple slaves. Whatever misreads that are still occuring now(maybe 1 in 1000) have their roots in electrical noise due to voltage level change from 5.0 to 3.3V or badly written bit banged SPI routine in Micropython. I am planning to write it myself.

[shantanu@india]

Just to update.
Absolutely perfect SPI communication with PIC slave at 100kHz @ 100 msec with payload of 32 bytes. Reading multifunction meter through RS485 modbus without any glitches.Slave select (SS) not required for MSSP module.
The secret is not to let interrupts clash. The receipt/transmission of 32 bytes through the MSSP module(interrupt driven of course) sets the stage for the modbus communication which takes around 25 msecs. (12 bytes for 3 float values) The uart receive buffer is read after about 30 msec so that it can be send back to the master in the next SPI cycle.
The trick is time management.
Another advantage of a PIC configured as a SPI slave is that it can detect gaps in communication and hardware reset the master, in this case a ESP8266. The watchdog feature of ESP leaves a lot to be desired.