samples: disk: unable to access sd card

[FRASTM]

Describe the bug
The samples/subsys/fs/fat_fs/ application cannot access the SD card through SPI bus,

To Reproduce
This sample is using a ci_shield to mount a SD card through SPI on a nucleo stm32f411

$ west build -p auto -b nucleo_f411re samples/subsys/fs/fat_fs/ -DSHIELD="ci_shield"

See error:

Error mounting disk.
[00:00:00.007,000] <err> main: Storage init ERROR!
[00:00:00.009,000] <err> fs: fs mount error (-5)

Expected behavior
`[00:00:00.005,000] spi_ll_stm32: CS control inhibited (no GPIO device)
Sector size 512
Memory Size(MB) 1886
Disk mounted.

Listing dir /SD: ...
[DIR ] SYSTEM~1
[FILE] TEST.LOG (size = 3072000)
[DIR ] TEST
`

Using the zephyrproject-rtos /fatfs latest branch including commit zephyrproject-rtos/fatfs@1369778

More info : PR ##26741 is helpful to adapt a SD card on a nucleo board

[FRASTM]

The second sdhc_spi_detect fails, in the disk_spi_sdhc_access_init is returning the error code -5

(This is not the case when reverting commit c64e0ce from PR #27685 )

[de-nordic]

@FRASTM I do not think that this is problem with FAT FS, shouldn't this be called "Unable to access SD Card"?

[FRASTM]

yes, at the beginning the pb occurs with the sample fat_fs,

[de-nordic]

yes, at the beginning the pb occurs with the sample fat_fs,

Thanks for clarification! So the issue probably is not even with the samples but the general SD access via SPI.

[de-nordic]

This is probably similar issue: #27112

[henrikbrixandersen]

This is probably similar issue: #27112

Unlikely since the author of that issue report talks about Zephyr 2.3.0, which does not contain c64e0ce.

[henrikbrixandersen]

@FRASTM Does the SPI controller driver used for accessing the SDHC card support SPI_HOLD_ON_CS properly? The Zephyr SPI SDHC disk access driver heavily depends on that.

[FRASTM]

thank you @henrikbrixandersen for pointing that. Trying CONFIG_SPI_HOLD_ON_CS=y gives not the solution, though. Could you please describe a bit the way for the spi driver to support SPI_HOLD_ON_CS.

[henrikbrixandersen]

@FRASTM SPI_HOLD_ON_CS is not a Kconfig option. It is a SPI transceive operation option:

zephyr/include/drivers/spi.h

Line 104 in 36aa42f

#define SPI_HOLD_ON_CS BIT(13)

[FRASTM]

well, the sdhc_spi_init() in the disk_access_spi_sdhc.c has :

data->cfg.operation = SPI_WORD_SET(8) | SPI_HOLD_ON_CS;

[carlescufi]

@erwango @FRASTM could you please debug this a bit further to see if it's related to the particular SPI driver?

[NZSmartie]

Also wanting to confirm a similar issue while giving 2.4.0-rc1 with a Nordic nRF52840 a try. The SD card does not mount:

[00:00:00.106,536] <err> fs: fs mount error (-5)

When reverting c64e0ce, it works again

[00:00:00.505,218] <inf> sdhc_spi: Found a ~982 MiB SDHC card.
[00:00:00.506,469] <inf> sdhc_spi: Manufacturer ID=2 OEM='TM' Name='SD01G' Revision=0x28 Serial=0x9e50e185

The DTS for the SPI is:

&spi1 {
	compatible = "nordic,nrf-spi";
	status = "okay";
	sck-pin = <29>;
	miso-pin = <31>;
	mosi-pin = <30>;

	cs-gpios = <&gpio0 16 GPIO_ACTIVE_HIGH>;

	sdcard: sdcard@0 {
		compatible = "zephyr,mmc-spi-slot";
		reg = <0>;
		status = "okay";
		label = "SDCARD";
		spi-max-frequency = <24000000>;
	};
};

[henrikbrixandersen]

@pabigot You mentioned that you verified commit c64e0ce on Nordic SPI in #27685 (review). Any idea on what goes wrong for @NZSmartie above?

[NZSmartie]

I'll have a dig/debug into the situation tomorrow. I've been looking into the nrfx spi driver and so far it looks to respect SPI_HOLD_ON_CS indirectly by spi_context_cs_control()

zephyr/drivers/spi/spi_context.h

Lines 176 to 200 in 016b542

	static inline void _spi_context_cs_control(struct spi_context *ctx,
	bool on, bool force_off)
	{
	if (ctx->config && ctx->config->cs && ctx->config->cs->gpio_dev) {
	if (on) {
	gpio_pin_set(ctx->config->cs->gpio_dev,
	ctx->config->cs->gpio_pin, 1);
	k_busy_wait(ctx->config->cs->delay);
	} else {
	if (!force_off &&
	ctx->config->operation & SPI_HOLD_ON_CS) {
	return;
	}
	k_busy_wait(ctx->config->cs->delay);
	gpio_pin_set(ctx->config->cs->gpio_dev,
	ctx->config->cs->gpio_pin, 0);
	}
	}
	}
	static inline void spi_context_cs_control(struct spi_context *ctx, bool on)
	{
	_spi_context_cs_control(ctx, on, false);
	}

from here

zephyr/drivers/spi/spi_nrfx_spi.c

Line 165 in 016b542

spi_context_cs_control(ctx, false);

[pabigot]

I'm not sure what board's being used in #27841 (comment) because the nrf52840dk_nrf52840 has a different spi1 configuration.

A clear problem in @NZSmartie's DTS is specifying the chip select as active-high. CSn should be active-low.

What works for me is this:

tirzah[22]$ cat boards/nrf52840dk_nrf52840.conf
CONFIG_LOG=y
CONFIG_DISK_ACCESS_SDHC=y
CONFIG_DISK_ACCESS_SPI_SDHC=y
CONFIG_SPI=y
tirzah[23]$ cat boards/nrf52840dk_nrf52840.overlay
#if 1
&arduino_spi {
  status = "disabled";
};

&spi2 { // nordic,nrf-spi
  status = "okay";
  sck-pin = <47>;
  miso-pin = <46>;
  mosi-pin = <45>;
  cs-gpios = <&arduino_header 16 GPIO_ACTIVE_LOW>; /* D10 */
#else
&arduino_spi { // = spi3 : nordic,nrf-spim
#endif
  sdhc0: sdhc@0 {
    compatible = "zephyr,mmc-spi-slot";
    reg = <0>;
    status = "okay";
    label = "SDHC0";
    spi-max-frequency = <100000>;
  };
};

Note I'm switching from spi3 to spi2 because spi3 (which only supports nordic,nrf-spim) doesn't work, and it didn't work before #27685 either. Looks like CSn is asserted except for a very brief period right before the transaction begins. (#27685 clearly took a step towards fixing SPIM, since before that patch CSn was inverted relative to its behavior afterwards. But SPIM doesn't deassert CSn after the transaction.)

[NZSmartie]

A clear problem in @NZSmartie's DTS is specifying the chip select as active-high. CSn should be active-low.

Oh hmm. I haven't paid too much attention to the SPI CS line, their spec is rather vague about the pin itself[1]. I was following the Device tree example set by most boards and most but one that specify GPIO_ACTIVE_HIGH.
Taking the OLIMEXINO-STM32 as an example. the schematic pulls the CS line low with a 1M resistor, I guess I need to read the MMC spec as well.

zephyr/boards/arm/olimexino_stm32/olimexino_stm32.dts

Lines 80 to 91 in c6b1375

	&spi2 {
	status = "okay";
	cs-gpios = <&gpiod 2 GPIO_ACTIVE_HIGH>;
	sdhc0: sdhc@0 {
	compatible = "zephyr,mmc-spi-slot";
	reg = <0>;
	status = "okay";
	label = "SDHC0";
	spi-max-frequency = <24000000>;
	};
	};

It still doesn't explain why GPIO_ACTIVE_HIGH works reliably in 2.3.0

Another interesting note. After setting cs-gpios = <&gpio0 16 GPIO_ACTIVE_LOW>; and using a Sandisk 32GB SDHC. It works without problems:

[00:00:00.170,166] <inf> sdhc_spi: Found a ~30436 MiB SDHC card.
[00:00:00.171,478] <inf> sdhc_spi: Manufacturer ID=3 OEM='SD' Name='SE32G' Revision=0x80 Serial=0x3c540a16

I guess the OEM SD card has some quirks that was compatible with the previous CS handling?

---

[1] Physical Layer Simplified Specification Version 7.10 - 7.2.1 Mode Selection and Initialization

The SD Card is poweredup in the SD mode. It will enter SPI mode if the CS signal is asserted (negative) during the reception of the reset command (CMD0).

[NZSmartie]

Also, the OEM SDCard times out during initialisation with GPIO_ACTIVE_LOW I'm still checking it out. It's a bit hard to get a logic analyser on the signals in my board, It's already a bodge job on a prototype, and don't have any test pads spare 😅

[pabigot]

In Zephyr 2.3.0 the active level flags from devicetree were ignored, and the SPI infrastructure set the configuration at runtime, defaulting to active low. ("asserted (negative)" in the spec you quoted means active low; active high would be "asserted (positive)".) Note that most non-SPI uses of GPIO are indeed active-high.

It could well be the card, there are many standards and classes. I've had to go back to class 4 cards from five years ago to get some interfaces to work. In any case all I can confirm is that on current master the sample works correctly on Nordic boards when using the nordic,nrf-spi driver.

[pabigot]

It appears that, if CONFIG_SPI_STM32_USE_HW_SS=y, STM32 driver is not respecting SPI_HOLD_ON_CS: logic analyzer traces show CS is being deasserted between the transmission of an R1 command and the read of its result. This produces unexpected results.

With software control of SSn this doesn't happen, but the response to the command is still not the expected result.

[Barmaley13]

I'm pretty new to Zephyr but I am seeing similar error.

Error mounting disk.
[00:00:00.006,000] �[1;31m<err> main: Storage init ERROR!�[0m
[00:00:00.007,000] �[1;31m<err> fs: fs mount error (-5)�[0m

I was trying to run fat_fs sample on nucleo_f411re board.
Added following files as board overlays.

nucleo_f411.conf

CONFIG_LOG=y
CONFIG_SPI_LOG_LEVEL=0
CONFIG_DISK_ACCESS_SDHC=y
CONFIG_DISK_ACCESS_SPI_SDHC=y
CONFIG_SPI=y
CONFIG_SPI_STM32=y
# CONFIG_SPI_STM32_INTERRUPT=y
CONFIG_SPI_1=y

CONFIG_DISK_ACCESS=y
CONFIG_FILE_SYSTEM=y
CONFIG_FAT_FILESYSTEM_ELM=y

and nucleo_f411re.overlay

&spi1 {
	cs-gpios = <&gpiob 6 (GPIO_ACTIVE_LOW | GPIO_PULL_UP)>; /* D10 */

        sdhc0: sdhc@0 {
                compatible = "zephyr,mmc-spi-slot";
                reg = <0>;
                status = "okay";
                label = "SDHC0";
                spi-max-frequency = <24000000>;
	};
};

I just wired wrapped SD card breakout board to spi1 and using D10 as a chip select. It seems like SPI bus does not work properly. I was not able to trigger it at all on v2.4.0-rc2. I was able to trigger spi on v.2.2.0 but it does not look right...

miso looks like sck and cs looks like data...

Would love to debug this further if someone can provide pointers.

[github-actions]

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.

[PureEngineering]

I would like to repoen this issue. as still seeing this issue.