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: They share the same ground.

My concern is that at 35A it is quite easy to drop say 0.5 volt on a ground connection.

If this connection is shared by one of the micros then the data levels are changed. (And the slow clock edge is sampled at different voltage )

Can the SPI clock frequency be lowered to 1 MHz or lower ?

[waclawek.jan]

How? Did you physically removed them and measured them?

JW

[MagSense]

Yes. Removed them and checked the valus using LCR meter.​

[MagSense]

At the moment, I am trying to solve this with the same frequency, as the update rate plays a key role here.

[Dvorak.Peter]

So what is more important speed or reliability?

A unmodified SPI running at half speed should confirm the clock slew problem.

For 2 MHz clock, the pin speed setting must be increased in the source controller

Check the data sheet for the Infineon microcontroller

[prain]

I think a differential signaling method is better in your situation. something like RS422. you can easily make miso, mosi sck , nss lines differential. Transceiver chips like ADM2582 are a good feet for such frequency range

[waclawek.jan]

Then the R is not what it should be, or you have something else connected to the line, too. The difference in slew rate between SCK and MOSI must have some physical reason.

JW

[Dvorak.Peter]

RE:

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

 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.

Can we have more information on the following:

Does the 35A load generate electrical noise ?

Is the sensor connected to STM32F303CB picking up electrical noise ?

Are there any photos of the product available ?

Does the interference stop when the load is disconnected ?

Does the interference stop when the sensor is disconnected ?

Are there any ground loops ?

What is the power source ?

Is the Infineon microcontroller device well documented ?

Are there any noise suppression filters ?

Can you share schematics or block diagram ?

[MagSense]

I conducted a different test, where I adjusted the filter for 10 MHz cut-off frequency (47R and 330pF). No filters were used on the MISO line. The errors on the MISO is now drastically reduced (from several hundreds in few seconds to less than a hundred over few seconds).

Then I modified the FW of the slave, where 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).

During all this time, the MOSI was unaffected. The errors appeared only during the "high power" mode. This might relate to what was discussed earlier with the difference in slew rate.

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

[MagSense]

Thats actually a good solution but unfortunately I cannot leap over from SPI. I have to stick to it. :expressionless_face:Its not in my hands.