STM32F769I-DISCO > microSD + FatFS > failed in "samples/subsys/fs/fat_fs" > CMD0 and 0x01

[yasokada]

Describe the bug

Using STM32F769I-DISCO, the microSD and FatFs project fails

1. Sending CMD0 command
2. Receiving 0x01

To Reproduce

Please see the following article for the detail.

• 2020 Jan. 14 Zephyr > STM32F769I-DISCO > microSD + FatFS > failed in "samples/subsys/fs/fat_fs" > CMD0 and 0x01

If there is any necessary information, I will add to the above article.

[yasokada]

Any progress or any schedule to tackle this problem?
I tried to solve this myself, but it is not easy for me to solve.

[erwango]

Sorry, it's not easy to investigate without the appropaite HW.
Anyway you could share an application that allows to reproduce the issue w/o CK-40?

[yasokada]

Do you mean, you cannot obtain CK-40, or microSD modules of any kind?
If you have (or can have) one of any microSD module, I will consider to buy and test on my side.

Without hardware, it seems difficult to debug. In this case, I will have to consider any way to use two STM32 boards for this, but it takes time.

I hope you would put information which is delaying this debug.
(I understand you are busy for other works...).

[FRASTM]

I can find stm32f769i_disco with sd card. However I still get

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

even with proj.conf and stm32f769_disco.overlay as mentioned.

[FRASTM]

on the stm32f769i_disco board the SPI2 port is available on ARD connector CN9 on D13, D12, D11, D10.
SPI2_SCK could be configured with STM32_OSPEEDR_VERY_HIGH_SPEED in the drivers/stm32/pinmux_stm32f7.h
Note that PA12 (D13) SPI2_SCK is also assigned to the led LD3 pin

However receiving 0xC0 from the card as a response R1 to the CMD0 'go_to_idle_state' command is very strange : bit 7 should always be 0 in R1 response code.

[erwango]

@yasokada Did changing SPI_SCK pin speed changed anything to your issue ?

[yasokada]

@erwango

Did changing SPI_SCK pin speed changed anything to your issue ?

I don't think so, but this weekend, I will check this.

[yasokada]

@erwango

I set up the environment as of Jan 14, 2020.

I can check the behavior changing SPI_SCK.
How can I change SPI_SCK?
at .overlay file (spi-max-frequency = <24000000>) ?
or in other way?

&spi2 {
        status = "okay";
        cs-gpios = <&gpioh 6 0>;

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

[FRASTM]

for testing in the boards/arm/stm32f769i_disco/pinmux.c could have
{STM32_PIN_PA12, STM32F7_PINMUX_FUNC_PA12_SPI2_SCK |
STM32_OSPEEDR_VERY_HIGH_SPEED},

[erwango]

@FRASTM

for testing in the boards/arm/stm32f769i_disco/pinmux.c could have
{STM32_PIN_PA12, STM32F7_PINMUX_FUNC_PA12_SPI2_SCK |
STM32_OSPEEDR_VERY_HIGH_SPEED},

Since this seem to be a magic, solution for a number of cases,
can you push this change upstream (extended to whole series )?

[yasokada]

@FRASTM @erwango

I tried the magic solution.
Partly success, but failed in others.
The following is the serial output.

    *** Booting Zephyr OS build zephyr-v2.1.0-868-gf014eeeb89fc  ***
[00:00:00.005,000] <inf> spi_ll_stm32: CS control inhibited (no GPIO device)
Sector size 512
Memory Size(MB) 1876
Disk mounted.

Listing dir /SD: ...
[DIR ] SYSTEM~1
[DIR ] SOMEDIR
[FILE] HOGEHOGE.TXT (size = 0)
[FILE] FUGAFUGA.TXT (size = 0)
[00:00:00.030,000] <inf> sdhc_spi: Found a ~1876 MiB SDHC card.
[00:00:00.032,000] <inf> sdhc_spi: Manufacturer ID=27 OEM='SM' Name='00000' Revision=0x10 Serial=0x928d5504
[00:00:00.032,000] <inf> main: Block count 3842048
[00:00:00.060,000] <inf> sdhc_spi: Found a ~1876 MiB SDHC card.
[00:00:00.061,000] <inf> sdhc_spi: Manufacturer ID=27 OEM='SM' Name='00000' Revision=0x10 Serial=0x928d5504
[00:00:01.030,000] <err> os: ***** USAGE FAULT *****
[00:00:01.030,000] <err> os:   Illegal load of EXC_RETURN into PC
[00:00:01.030,000] <err> os: r0/a1:  0x00000000  r1/a2:  0xe000ed00  r2/a3:  0x200205f0
[00:00:01.030,000] <err> os: r3/a4:  0x00000000 r12/ip:  0x200205f0 r14/lr:  0x080055f9
[00:00:01.030,000] <err> os:  xpsr:  0x20020400
[00:00:01.030,000] <err> os: Faulting instruction address (r15/pc): 0x00000000
[00:00:01.030,000] <err> os: >>> ZEPHYR FATAL ERROR 0: CPU exception on CPU 0
[00:00:01.030,000] <err> os: Current thread: 0x200202a8 (unknown)
[00:00:01.126,000] <err> os: Halting system

[erwango]

@yasokada

To me this seems different from the error you faced previously. Can you check if you're receiving 0x01 on CMD0 ?

[yasokada]

@erwango
@FRASTM

I'm receiving 0x01 on CMD0 (see the attached image), five times in a row.

So, with the modification on pinmux.c as proposed by FRASTM, the SPI works fine.
But there is another problem with SDHC driver. That may be another topic from this one.
(we can close this topic ?)

[erwango]

So, with the modification on pinmux.c as proposed by FRASTM, the SPI works fine.
But there is another problem with SDHC driver. That may be another topic from this one.
(we can close this topic ?)

@yasokada, yes please let's open a new issue for this specific problem.
We'll kep this one open and close it with the fix. @FRASTM, can you take care of pushing the fix ?

[FRASTM]

i have put the PR #23493

[yasokada]

@erwango
cc: @FRASTM

@yasokada, yes please let's open a new issue for this specific problem.

Yes. After checking what's happening, I'll open a new issue for it.