in SPI slave mode, a clock glitch causes future reads to fail - Page 1
Forum section: electronics / projects

author: technogeeky
author_rank: Frequent Contributor
timestamp: May 23, 2018, 09:33:33 pm
content: Hey folks.I'm debugging a SPI slave configuration on an ESP32. The master device is a Keithley 197. I can't control or alter the signals coming from this device, and it has a glitch.A nice full write-up of this problem isavailable here.The data I am expecting (because the multimeter reading isn't changing) is this:Code:20 30 4A 14 00 18 11 20 80 EB EB EF EB EB FB 04 0420 30 4A 14 00 18 11 20 80 EB EB EF EB EB FB 04 0420 30 4A 14 00 18 11 20 80 EB EB EF EB EB FB 04 04However, what I see is this:Code:20 30 4A 14 00 18 11 20 80 EB EB EF EB EB FB 04 0420 30 4A 14 00 18 11 20 80 EB EB EF EB EB FB 04 0420 30 4A 14 00 18 11 20 80 EB EB EF EB EB FB 04 04(... after a dozen or so readings ...)20 30 4A 14 00 18 11 20 80 EB EB EF EB EB FB 00 0020 30 4A 14 00 18 11 20 80 EB EB EF EB EB FB 00 0020 30 4A 14 00 18 11 20 80 EB EB EF EB EB FB 00 00(... forever until reset ...)After a ton of playing and debugging, I found an exact correlation with this changeover from correct reads to incorrect reads.Here is a animation of the SPI being captured and decoded on an oscilloscope. There are two long pauses: one at the very beginning, which explains how I'm triggering (yellow trace, a pulse of a few microseconds duration, on an extra GPIO, which is generated from the spi_trans_callback). This pulse is essentially as close as possible to the moment the SPI bus is done reading the bytes. The second pause shows the read during which the spi clock glitch occurs on the last bit of the last byte. After this glitch (which reads the data correctly), all following reads are incorrect.Here is the same animation, but zoomed in so you can see the exact timing. Note that the glitch is quite a long pulse compared to the normal pulses. Also note that the yellow trace normally concludes a few microseconds after the last clock pulse has fallen. But after the glitch, the yellow trace has shifted to earlier: it returns during the last clock pulse. It is true that this should be acceptable (because I'm in mode = 0, so positive polarity and rising edge), but it nevertheless fails to grab the last byte (in this case, the last two bytes) of 17.Anyone have any clues about this? Any routes to debugging this problem?

author: jbb
author_rank: Super Contributor
timestamp: May 24, 2018, 12:21:53 am
content: If your problem starts with a clock glitch, I suggest you look at why the master is making one.General question: are you using a chip select input on the ESP?

author: technogeeky
author_rank: Frequent Contributor
timestamp: May 24, 2018, 03:15:12 am
content: Quote from: jbb on May 24, 2018, 12:21:53 amThe reason I used the word 'glitch' is because as far as I'm aware, while it is perhaps less than perfect, it does not represent a problem. I am not sure what I could do about it anyway. Apparently the original LCD chip and the oscilloscope can deal with it just fine.Yes, I am using the CS input. On the oscilloscope captures, I am using a timeout method for decoding because the CS is too far off screen (I should be using the delayed time base).

author: jbb
author_rank: Super Contributor
timestamp: May 24, 2018, 04:01:59 am
content: OK, I deployed some more brain cells and suggest the following:I guess that the master is doing some kind of bit-banged SPI output and sometimes an interrupt or similar messes with the timing.Can you check the (corrct) data transmission to verify the SPI mode? It looks like your SPI receipt is happening faster than it should in the ESP for the ‘stretched’ clock. When does the MOSI line change compared to the clock edges?As an interim bodge, you could try resetting the SPI module between each frame (use the rising edge of the chip select). Maybe the ESP has a peripheral disable, or you could change it to master mode and back to slave again?