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
On 27.05.20 10:18, Kevin Weiss wrote:
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
[email protected]
https://lists.riot-os.org/mailman/listinfo/users
_______________________________________________
users mailing list
[email protected]
https://lists.riot-os.org/mailman/listinfo/users
_______________________________________________
users mailing list
[email protected]
https://lists.riot-os.org/mailman/listinfo/users
