STM32: SPI.readinto ignores write_value, causes SD cards not to detect

[jerryneedell]

related to
adafruit/Adafruit_CircuitPython_SD#36

I know the "on-board" SDcard is not support on the feather STM32F405.
I tried attaching an Adalloger Featherwing using sdcardio and it is not able to detect the card
The also happens with the Adafruit_CircuitPython_SD library
see
adafruit/Adafruit_CircuitPython_SD#36

Press any key to enter the REPL. Use CTRL-D to reload.
Adafruit CircuitPython 6.0.0-alpha.1-111-g8f928340c on 2020-07-20; Feather STM32F405 Express with STM32F405RG
>>> import sdcardio_lib
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "sdcardio_lib.py", line 9, in <module>
OSError: no SD card
>>> 

code -- sdcardio_lib.py

import busio
import sdcardio
import board
import storage
import sys
import os

# Connect to the card and mount the filesystem.
sdcard = sdcardio.SDCard(board.SPI(), board.D10)
vfs = storage.VfsFat(sdcard)
storage.mount(vfs, "/sd")
sys.path.append("/sd")
sys.path.append("/sd/lib")

[jepler]

Good session, nRF52840 (particle xenon):

Bad session, STM32F405 feather

Notice how outside the "40 00 00 00 95" packet sent to initialize the SD card into SPI mode, the MOSI pin stays high on nRF but doesn't on STM. I believe this is because the write_value (a static 8 bit value to be output while the read is ongoing) is ignored in the stm port:

bool common_hal_busio_spi_read(busio_spi_obj_t *self,
        uint8_t *data, size_t len, uint8_t write_value) {
    if (self->miso == NULL) {
        mp_raise_ValueError(translate("No MISO Pin"));
    }
    HAL_StatusTypeDef result = HAL_SPI_Receive (&self->handle, data, (uint16_t)len, HAL_MAX_DELAY);
    return result == HAL_OK;
}

I suspect the underlying cause is the same here and in adafruit/Adafruit_CircuitPython_SD#36 and will be fixed by the same fix -- whatever that is.

[jepler]

I've taken the liberty of punting this to @hierophect but can take it back if that's preferred.

[hierophect]

I can check it out, I'll add it to my list.

[jepler]

Changing the readinto code like this works, but may not be acceptable (it puts a potentially large variable size array on the stack):

 bool common_hal_busio_spi_read(busio_spi_obj_t *self,
-        uint8_t *data, size_t len, uint8_t write_value) {
+        uint8_t *data_in, size_t len, uint8_t write_value) {
     if (self->miso == NULL) {
         mp_raise_ValueError(translate("No MISO Pin"));
     }
-    HAL_StatusTypeDef result = HAL_SPI_Receive (&self->handle, data, (uint16_t)len, HAL_MAX_DELAY);
+    uint8_t data_out[len];
+    memset(data_out, write_value, len);
+    HAL_StatusTypeDef result = HAL_SPI_TransmitReceive (&self->handle,
+        data_out, data_in, (uint16_t)len,HAL_MAX_DELAY);
     return result == HAL_OK;
 }

[hierophect]

@jepler I'm fixing this today. Do you think you could provide me with a test sketch I can use to verify the fix? Something with a clear differentiation between the desired/undesired behavior. I can use my logic analyzer to view the same waveforms you did if you give me that same sketch. If it's just the same one jerryn provided let me know.

[hierophect]

I'd like to understand the significance of write_value a little better - most of the ports ignore it (including NRF52, which was in your example), and the ones that don't pass it directly into their SPI HALs. Is there something that STM32 does here that's nonstandard?

[hierophect]

Looks like this is a limitation of the ST HAL in regards to handling the MOSI line when using an SD card.
https://community.st.com/s/question/0D50X00009XkdpZ/sd-card-using-spi-initialization-stm32f303-issue

I'll look around for other workarounds since this one seems kind of slow. Micropython, STM32Duino, and even the ST FatFS library must all deal with this issue somehow.