SPI – bit shift issue in MISO line of STM32F303x (Slave) - with MOSI unaffected

[MagSense]

Scenario –

Currently I am using STM32F303CBxx as my slave and an Infineon microcontroller as a master. The communication takes place via SPI with the clock frequency as high as 1.985 MHz (approx.). The master and slave are inside a closed metal compartment, where one of the control unit consumes higher amount of current, as high as 35 A.

Communication Protocol

The protocol for the communication is as follows.

 

Actual Communication and related issue

From the above picture (measured data from picoscope), the decoded SPI message from the MISO line is as follows,

0x34 0x6F 0x00 0x12 0x38 0x77 0x1E 0x12

For CRC, I am using the XOR checksum (CRC8). When I check the above message for the validity (using a normal xor checksum calculator online), the xor byte becomes invalid (0x12)

Moreover, the expected message is as follows-> 0x34 0x6F 0x00 0x12 0x38 0x77 0x0F, with a CRC byte value of 0x09.

If I observe the 7th byte -> 0x1E -> 0001 1110, 1-bit shift happened towards the left, as the expected value was 0F -> 0000 1111. This bit shift happens at the 8th byte (CRC) as well.

12 (invalid CRC) -> 0001 0010 (measured) -> 0000 1001 (expected) -> 09 (valid CRC).

The bit-shifting issue happens only on the MISO line of the SPI, when the current consumption is on a higher range (more than 20 A, for example). The clock line does not get disturbed, as I always get valid messages on the MOSI. It should also be noted that the other functionalities of the slave (there are other measurements running in parallel) are unaffected.

This bit-shifting originates most of the time in the 7th or 8th byte of a packet, but rarely occurs in the 1st byte as well.

For example, take a look into the above highlighted transaction.

The decoded MISO message is 0x60 0xAC 0x01 0xF0 0x01 0x96 0x04 0xAE. The complete packet is shifted to the left by exactly 1-bit. If I shift the message by 1-bit to the right, I receive the following message -> 0x30 0x56 0x00 0xF8 0x00 0xCB 0x02 0x57. This is a valid transaction and the message holds true.

What could be the source of such bit-shift error? Does this occur in the microcontroller itself?

Any recommendations regarding finding the source of such errors, are highly appreciated.

Please let me know if additional information is required.

Thank you.

[waclawek.jan]

What is the CPOL/CPHA setting?

JW

[MagSense]

Hi,

The CPOL is High (1) and the CPHA is trailing edge (2 edge : 1).

Regards,

MS.

[waclawek.jan]

On second thought, observing MOSI vs MISO, CPOL/CPHA is probably correct.

The bit shift is most likely caused by the 'STM32 "seing" an extra clock; that this happens "when current consumption is on a higher range" indicates suspected noise/common ground issues.

The depicted SCK slew rate is suspiciously slow.

Try to get a galvanic isolated oscilloscope, placing the oscilloscope's ground clip as close to the STM32's ground as possible, and observe SCK (even stationary), directly on the STM32's pin, during the "high current" or transitions of it. Then try to observe the "glitch" as above. The probe+oscilloscope MUST be fast enough for the slave SPI capabilities, i.e. analog bandwidth above 100MHz and adequate sample rate.

JW

[MagSense]

Hi JW,

I did almost the exact measurement you suggested. I used special shielded cables, which were directly soldered onto the SPI connectors, with GND shield connected to the microcontroller GND. The bandwidth of the oscilloscope I used is around 70 MHz (12-bit resolution).

BLUE -> MISO

RED -> CLK

GREEN -> MOSI

Even I suspected such a "glitch" on the CLK line might be the culprit, but I was unable to capture this on the scope. There, the CLK signals looked fine. Even if we consider that such a glitch occurs on the CLK line, it should affect not only MISO but also MOSI. Right?

[waclawek.jan]

SCK is generated by master, so it's output (MOSI) is probably derived from internal version of SCK and unaffected (in STM32 it's not this way and MOSI is generated from a feedback from the SCK pin, but that's IMO a deviation, I've never met this approach before).

The SCK is suspiciously slow. slower than MOSI. Is there any way to make it's slew rate higher, maybe a pin setting in a master? Is there any extra hardware on SCK?

JW

[prain]

what is the idle state for clock? in picture it starts from low state but ends with high state. is this correct? make sure no clock edges are ignored.​

[MagSense]

Hi JW,

Thank you for your response. I am using a RC filter at the slave, with a cut-off frequency of 340 MHz and RC Time constant of 5e-10 seconds.

Unfortunately, I cannot change any settings with the master. There are only the RC components on the SCK and nothing else.

Regards,

MS

[waclawek.jan]

> I am using a RC filter at the slave,

Try to remove it.

JW

[waclawek.jan]

prain,

> it starts from low state but ends with high state.

Yes I've noticed that too, but CPOL=1, and there is a (barely noticeable) yellow trace which is probably NSS - within it, the clock is already high at the start, so that should be OK.

Also, the bit shift occurs midway in the message. Would the idle state of SCK the culprit, the shift would occur at the beginning.

JW