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]

> I changed the GPIO pin maximum speed settings (from high to medium) which in-turn reduced the error count to 1 (over 4 seconds measurement).

This is quite surprising and IMO is another indication that ground arrangement is wrong.

JW

[MagSense]

Does the 35A load generate electrical noise ? -> No actual electrical noise was observed.

Is the sensor connected to STM32F303CB picking up electrical noise ? -> That is the question here. In my answer to @Community member​ , as soon as I reduced the frequency of the GPIO pins, the errors that I observe on MISO line reduced. This might actually tell us something regarding some disturbance on the SPI lines. But the other functionalities of the sensor were unaffected when the error happens.

Are there any photos of the product available ? -> Unfortunately I am not in a position to share this in the forum.

Does the interference stop when the load is disconnected ? -> As mentioned in my initial post, the issue/interference happens only when the control unit is consuming high amount of power. As soon as we step down to a lower stage, the errors do not happen any more.

Does the interference stop when the sensor is disconnected ? -> If the sensor (slave) is disconnected, the communication will also be disconnected. Added to that, the sensor is actually powered by the control unit, which is also powering the master. Hence, If I disconnect the sensor, I will disconnect the power to the sensor as well.

Are there any ground loops ? -> Nothing I know of. The master and the slave share the same ground with no evident ground loops in sight.

What is the power source ? -> Power source is from a standard power supply with 48V input to the control unit. It steps down the voltage to 5V, which is used to power the sensor (slave). The slave has an 3.3V LDO, which is used to power the microcontroller. A similar setup is used on the master side as well. Since the master and the slave are spaced out by a distance of around 15 cm, individual LDOs are used.

Is the Infineon microcontroller device well documented ? -> Yes but unfortunately I do not possess the complete information regarding it. The MOSI and MISO lines are internally pulled up by 1kOhms (by the master controller).

Are there any noise suppression filters ? -> nothing on the SPI lines, apart from the RC filters that were mentioned previously.

Can you share schematics or block diagram ? -> if you need more information, you can specify it. I will try my best to provide them.

[TDK]

> But in theory, it is actually good to have a RC filter on communication lines like SPI, right?

I would not agree with this. Signaling doesn't need a filter unless you have a reason for it. With SPI, it can introduce clock skew. If your system has so much noise that a filter is necessary, perhaps differential signaling is required.

[Dvorak.Peter]

Thanks for your reply.

Can you shed more light on the mystery 35A load and how is the power adjusted and switched ?

Clearly the the load or its controller is creating some sort of pulse interference.

RE: control unit is consuming high amount of power

Is your control unit a high power (1600W) computing device or a motor drive ?

 Also in the above block diagram the slave should take 5V power and ground from the master

[MagSense]

I measured the ground potential between master and the slave, and they seem to be on the same level. So I am not sure If the ground arrangement problem arises here.

[MagSense]

I agree with your answer. But the problem persists, even if I remove the filters (say from MISO/CLK lines). There were no difference in occurrences of errors.

[waclawek.jan]

> I measured the ground potential

DC measurement is worthless in this regard. You are interested in *fast* transients at the moment when the problem occurs (i.e. when the high current is switched or generated or whatever).

JW

[TDK]

So with the filter removed, you still have an SCK line that looks like a sine wave as in the original post?

[MagSense]

At this stage its our assumption that the ground planes might be improper. Is there any possible way to detect this? Suggestions are welcome..