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.

[Dvorak.Peter]

re: 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?

The clock slew rate is the root problem.

If the clock slew rate can't be increased , then the data slew rate must match it.

 A simple way to verify this is to slow down the clock rate by factor of 2

[TDK]

For a signal at 2 MHz, the edges in your plot look awful. I wouldn't expect an RC filter with a cutoff at 340 MHz to have any affect on them.

[waclawek.jan]

> I wouldn't expect an RC filter with a cutoff at 340 MHz to have any affect on them.

+1

I'd expect some mistake, like C being 10nF instead of 10pF, or something similar.. Removing the filter (bridging, removing C) should reveal the trough.

Nonetheless, this is a problem only in conjunction with some noise, as the input Schmidt trigger has relatively high hysteresis in 'F3 - typ.100mV for FT and 200mV for TC/TT.

JW

[Dvorak.Peter]

In the above snip the falling data edge starts out later but arrives before the clock edge

One thing that may work is an RC filter on the data input to match the slew induced delay in the clock signal.

[MagSense]

The error occurs only during a certain "high power consumption" mode (approx. 8 error messages out of 300) and the rest of the time, this error doesn't happen. Wouldn't the RC filter affect the normal operations as well?

[waclawek.jan]

Have you already removed it and observed the result?

JW

[Dvorak.Peter]

RE: The error occurs only during a certain "high power consumption" mode

My guess this is a ground shift problem. The grounds between the two controllers shift by measurable amount. This effectively changes the clock receiver logic threshold and therefore the timing shift .

Can you get the person (company) responsible for the  Infineon microcontroller to fix the clock slew rate.

[TDK]

I think you’re overestimating what is possible via a user forum.
Even if the RC is not the issue, it would be good to eliminate. If ground is changing between the two chips, that is also not good. How much does ground shift?

[MagSense]

@Community member​  The RC filter was always there throughout the testing. I haven't performed any tests without those, as it was highly recommended to have them for high speed lines.

@Dvorak.Peter​ The slave is actually accepting power from the same source as the master. They share the same ground. By the clock slew rate, do you mean that the slew rate is affected by this "high power consumption" mode?

@TDK​  As of now, I did not observe any ground shift as discussed here.

[MagSense]

The capacitors are actually 10pF and I have double checked them.