SPI receive callback - yet another mystery

[Smoun.1]

Hi

I've got another question on this project.

I have a Nucleo H7 board communicating with a Nucleo F3.

In the middle I have a BoostXL DRV8301.

I say in the middle because it is configured (SPI) and enabled (EN-Gate pin) with the H7. However the PWM generation is done through the HRTIM on the F3.

I had some weird noise issues which I think were coming from the fact the DRV8301, the H7 and F3 have all their own 3.3 bus. The symptoms were that communication is perfect as long as the DRV8301 is disabled (motor is off). But as soon as I enable the driver (and the motor is actually getting power), the SPI communication between the H7 and F3 goes south with only about 20% of valid data. The F3 needs 3x 16bit words from the H7, and so to ensure data is valid, I am sending the 3x 16bit words, twice. I have a verification on word 1 and 4, 2 and 5 and 3 and 6. If all 3 tests match, then data is considered valid. So when I say ~20% if valid, this is what I mean, these tests are only valid 20% of the time.

The strange part is that the oscilloscope (even though the signals look pretty bad) is capable of decoding this, and on a 1second sample acquired and analyzed in excel, 100% if valid.

That's the background. I decided to cut off the STlink from the Nucleo F3 and supply the F3 with the 3.3 from the BoostXL/DRV8301, and using an external STlink on the SWD/SWC pins for programming/debugging.

Results on the oscilloscope are much better, well can't do better than 100% on the data side of things, but the SPI signals look a LOT cleaner. However, (without changing the code) the SPI_cpltRX callback is no longer firing at all!!!

• Looking at the debugger while data is streaming, only the first 4 16bit words are changing. So of course, the callback which expects 6x 16bit words is not firing.

Again, nothing has changed on the firmware, only changed the power supply.

Of course all GND from the boards are tied together.

What's really weird is that this happens regardless of the DRV8301 being enabled or disabled. As opposed to before where when the driver was disabled, the data was getting captured perfectly by the F3, with no reject whatsoever.

The configuration of the SPI on the F3 is Receive only, Slave mode. With NSS hardware. (I initially tried an EXT GPIO to trigger a GPIO callback and start receiving data in blocking mode - which was no better and no worse than the hardware NSS route with SPI callback; however, I figured the non blocking way of NSS hardware would probably be cleaner so I stuck with it).

Any idea what a slight change in power supply could have triggered on this system?

There is definitely 6x 16 bit words on the oscilloscope, not just 4.

I am tempted to try the EXT interrupt route again which at least would allow me to see more of what's going past the first 4 words.

Cheers