SPI: Issue with my own STPM33 driver

Help archive
1

Hi everyone,

I’m using a STPM33 on some of my boards with STM32F302 or STM32F303. With RIOT OS and my driver, I’m facing issues with SPI :

  • Either I do spi_acquire() in the init process of the driver (bad practice) and everything works great. But after a while and only on some boards, I get constant values out of my STPM33. When I perform a soft (pm_reboot) or hard reset of the board, the values we get are correct again.
  • If I do spi_acquire()/spi_release() before and after each transaction, I get only constant values or 3-4 different values but always the sames. I think the STPM33 doesn’t even get initialized.
  • On EVALSTPM33 (the evaluation board from ST), if I do spi_acquire()/spi_release() before and after each transaction, everything works great. My driver is ok.

Before switching to RIOT OS, I was using a driver written by a student of my University based on ST HAL library. Everything was working very well. No issue with STPM33 with this driver.

Here are the drivers to compare:

  • Old driver spi.c file : Functions of interest are : “spi_stpm33_init()”, “spi_stpm33_writebytes()” and “spi_stpm33_readbytes()”
2

Hey Joël,

since I don’t see any responses I might as well give it a try.

First it would be helpful to know if there are any differences between your board and the eval board (ie, different mcu, pinouts, etc).

  • Try slowing down the speed (though 5MHz is probably slow enough that you won’t get corrupted).

  • Try adding an external pullup on the SCK of so that it doesn’t float (though maybe RIOT already provides an internal pullup) *note, pullup or pulldown depending on the mode

  • Try previous releases to see if a regression is introduced somewhere

There is an issue when powering off the SPI could create extra clock cycles [1] but it doesn’t seem like it. Adding some delays before release and after acquire might help eliminate this or other timing related problems.

The last thing I can think of is maybe it is something to do with the GPIO speed. I had problems before with additional clock cycles triggering because the MOSI pin would couple to the SCK pin depending on how it was wired. This caused garbage data so maybe it is a different thing. Eventually it was fixed by limiting the slew rate of the GPIO (GPIOx_OSPEEDR) to medium speed.

Good luck!

  • Kevin

[1] https://github.com/RIOT-OS/RIOT/issues/11104

3

Hi Kevin,

Thank you very much for your help. It made find the issue!

I went through all the points you mentioned. Also I compared the schematics of my custom board and the EVALSTPM33 + Nucleo-F303RE.

The issue lies on two points :

  • Slew rate (OSPEEDR) too high. I set it to 50MHz.
  • The EVALSTPM33 is full of external pull-up resistor. None on the custom board. So I changed the GPIO_MODE of MISO/MOSI/SCLK/CS according to the settings the old driver was using.

And now everything works as intended!

Your answer put on me on the right tracks!

Best regards

Joël