STM32: SPI Issues

[S4WRXTTCS]

I'm having two issues with the SPI functionality on the STM32F405 Feather Express board running Circuit Python 5.3.

The first issue is that it seems to be leaving an old value in the buffer. For example if I connect a wire from 3.3V to the MISO pin, and then I run the following

>>> import board
>>> import busio
>>> spi = busio.SPI(board.SCK, MISO=board.MISO)
>>> spi.try_lock()
True
>>> spi.configure(baudrate=5000000, phase=0, polarity=0, bits=8)
>>> result = bytearray(1)
>>> spi.readinto(result)
>>> result
bytearray(b'\xff')

That's the correct value, and now I switch the wire from 3.3V to GND.

>>> spi.readinto(result)
>>> result
bytearray(b'\xff')

That's the incorrect value so I read it again.

>>> spi.readinto(result)
>>> result
bytearray(b'\x00')

Which is the correct value. Is there a bug with it or am I doing something stupid?
My initial troubleshooting effort was to switch the baudrate but nothing I tried seemed to work. I tried reducing the baudrate to 1MHz, and it halted as soon as I did the spi.readinto command. I also tried reducing it to 500KHz, and that also halted.

Is there a list of supported baud rates?

I didn't see it here.
https://circuitpython.readthedocs.io/en/5.3.x/shared-bindings/busio/SPI.html

[S4WRXTTCS]

I verified that this same code works perfectly fine with CircuitPython 5.3 on an Edge BadgeBoard (samd51j19)

I grounded the MISO pin, and then ran the following in REPL

>>> import board
>>> import busio
>>> spi = busio.SPI(board.SCK, MISO=board.MISO)
>>> spi.try_lock()
True
>>> spi.configure(baudrate=5000000, phase=0, polarity=0, bits=8)
>>> result = bytearray(1)
>>> spi.readinto(result)
>>> result
bytearray(b'\x00')

Then I connected MISO to 3.3VDC

>>> spi.readinto(result)
>>> result
bytearray(b'\xff')

Then connected MISO back to GND

>>> spi.readinto(result)
>>> result
bytearray(b'\x00')

[dhalbert]

I've brought this to the attention of our STM expert.

btw, when you insert code, you can surround it in triple backticks, to make it format nicely. I edited your posts to do that. If you edit one, you can see how to do that.

[hierophect]

Looking into this issue, it's unfortunately looking more complicated than I anticipated (at least the speed related crash, which seems like the greater issue of the two). What I'm seeing is that the BSY flag in the SPI2 Status Register (SR) is never being reset and is causing a hang in a HAL timeout routine (we don't enable timeouts for SPI right now, which might be an appropriate temporary fix).

It isn't obvious to me from the reference manual why this is happening. The BSY flag should be automatically cleared when the SPI device is disabled (clearing the SPE bit in CR1), which happens right before this timeout hang, and reading the registers shows that it's been disabled as intended. The errata for the F405 doesn't show any BSY errors for master mode, only slave mode, and the suggested workaround is to clear SPE, which has already happened.

I'm hoping there's some simple explanation for this that I'm missing but if not, I might need to reach out to ST.

[hierophect]

I'll also revisit older versions of Cpy and see whether I can replicate this... I don't recall any issues like this occurring when putting together the SPI system or related modules. I'd like to find out if it was caused by recent changes to the low-power/clock system, or something similar.

[hierophect]

I've discovered that neither of these issues (speed change hang or delayed read) occur when both the MOSI and MISO pins are defined. Tracking down a fix, but you can try defining a MOSI pin if you need an immediate solution.

[dhalbert]

@S4WRXTTCS We were wondering what your use case is for MISO only. Do you have a peripheral that just sends data?

[S4WRXTTCS]

I actually don't have a use case for MISO only. I was simply following example code, and didn't give it much thought.

I wanted to get that to work before moving on to testing out the Analog Devices ADXL355 on it. The ADXL355 needs both the MISO, and the MOSI pins.

I'll try defining the MOSI, and seeing if that works.

[S4WRXTTCS]

I confirmed that defining both MISO, and MOSI fixes the two issues I had. So I can continue on with my project.

FYI - The Adafruit example is what I was using to test it out, and it doesn't define the MOSI pin. This is the likely starting point of someone who gets the Feather STM32F4 from Adafruit.

https://learn.adafruit.com/circuitpython-basics-i2c-and-spi/spi-devices

[hierophect]

@S4WRXTTCS glad your project is able to move forward! Still, simplex SPI is a part of the Circuitpython API so it definitely should be working. I've put in a PR above that I believe resolves the issue, though I'm still testing and investigating it.

[hierophect]

I've confirmed that this is a HAL bug, as there's an appropriate check for this timeout in the most recent version: https://github.com/STMicroelectronics/STM32CubeF4/blob/5d01400afd60410f6e049cbd19179a67d44d53fd/Drivers/STM32F4xx_HAL_Driver/Src/stm32f4xx_hal_spi.c#L3465

I'll chat with @hathach about updating it. Nevermind, it's already up to date, I'm just behind.

[hierophect]

Updating the submodule to include the HAL fix in version 1.24.1 resolves the hang on lower SPI speeds. I still see a one write delay at high speeds (5000000) which does not occur on low speeds (500000). @S4WRXTTCS is this still a problem for your application? I'm wondering if that's just something to do with the crude nature of this test and how the HAL module handles the RXNE (RX Not Empty) register in the update. If it's still a problem for your test I can look into it further.