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
On 26.05.20 09:47, Joël Carron wrote:
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 :
https://gist.github.com/Carton32/2ba95a6b064afe8e03e01fa58cda6682
Functions of interest are : "spi_stpm33_init()",
"spi_stpm33_writebytes()" and "spi_stpm33_readbytes()"
- New RIOT OS driver : https://github.com/Carton32/stpm3x
Functions of interest are in stpm3x/stpm3x.c : "stpm3x_init()",
"stpm3x_read_reg()", "stpm3x_write_reg()". *Warning* : this is the
version of the driver with spi_acquire()/spi_release() on each SPI
transaction. The version I'm using does a single spi_acquire() on line
80 and no spi_release() at all. This is the only way I've found to
make my driver works on my custom designed boards.
Does someone has any clue why my driver is failing when doing
spi_acquire()/spi_release() on each transaction with my board design ?
The only explanation I've found until now is that the hardware design
may be wrong because on the EVALSTPM33 everything works with the
Github version of the driver without changes. If the hardware is not
the issue, does someone know what could I change to make it works like
it should ? The initialization of old driver in "spi_stpm33_init()"
makes me think it could come also from here.
Thank you for your help
Best regards
Joël
_______________________________________________
users mailing list
users@riot-os.org
https://lists.riot-os.org/mailman/listinfo/users
_______________________________________________
users mailing list
users@riot-os.org
https://lists.riot-os.org/mailman/listinfo/users
