SD Card boot is not working, I get `SD_InitDetailedErrorDesc ( 0x0000001B )` when using the ROM Code Trace Analyzer. What does this mean?

[hreysenbach]

I have a custom board with a STM32MP157AAB3 and I am trying to boot it with the SD card.

I have tested the SD card on a STM32MP157C-DK2 and it boots to Linux fine.

When I probe the SD card lines, I can see the clock is toggling for a long time and the CMD pins is also toggling however nothing happens on the D0 pin, it is held high (3V3)

[hreysenbach]

Here is the full boot log:

< @ 00007461 | [INFO] - BOOTCORE_BootRomMaskVer ( 0x00000000 ) >
< @ 00008741 | [INFO] - BOOTCORE_BootRomVer ( 0x0000020E ) >
< @ 00009910 | [INFO] - BOOTCORE_FreezeIWDG12Clocks >
< @ 00011322 | [INFO] - BOOTCORE_HwResetPOR >
< @ 00023852 | [INFO] - BOOTCORE_ChipModeSecOpen >
< @ 00026186 | [INFO] - BOOTCORE_LogicalResetSystem >
< @ 00028034 | [INFO] - BOOTCORE_BootActionColdBootProcess >
< @ 00085084 | [INFO] - BOOTCORE_BootCfgOtpWordValue ( 0x00000000, 0x00000000 ) >
< @ 00086620 | [INFO] - BOOTCORE_BootPinsFirstSelSd >
< @ 00087678 | [INFO] - BOOTCORE_OtpPrimarySrcForceNothing >
< @ 00088732 | [INFO] - BOOTCORE_OtpSecondarySrcForceNothing >
< @ 00089833 | [INFO] - BOOTCORE_OtpBootSrcDisableMaskVal ( 0x00000000 ) >
< @ 00090971 | [INFO] - BOOTCORE_OtpBootUartInstanceDisableMaskVal ( 0x00000000 ) >
< @ 00093297 | [INFO] - BOOTCORE_BootCfgAfmuxOtpWord1Value ( 0x00000000 ) >
< @ 00094654 | [INFO] - BOOTCORE_BootCfgAfmuxOtpWord2Value ( 0x00000000 ) >
< @ 00096066 | [INFO] - BOOTCORE_BootCfgAfmuxOtpWord3Value ( 0x00000000 ) >
< @ 00097547 | [INFO] - BOOTCORE_BootCfgHseValue ( 0x00000000 ) >
< @ 00100497 | [INFO] - BOOTCORE_EnabledSrcMaskVal ( 0x00000650 ) >
< @ 00101844 | [INFO] - BOOTCORE_BootModeNOBOOTCSTANDBY >
< @ 00640343 | [INFO] - BOOTCORE_StartupWaitTime ( 0x00002700 ) >
< @ 00641908 | [INFO] - BOOTCORE_ReOpenDebugValue ( 0x00000000 ) >
< @ 00644154 | [INFO] - BOOTCORE_Pll12StartNotDisabledByOtpBit >
< @ 00646201 | [INFO] - BOOTCORE_Pll1Started >
< @ 00650942 | [INFO] - BOOTCORE_Pll1Locked >
< @ 00652314 | [INFO] - BOOTCORE_Pll2Started >
< @ 00656995 | [INFO] - BOOTCORE_Pll2Locked >
< @ 00658577 | [INFO] - BOOTCORE_CkMpuSsSwitchedOnPll1 >
< @ 00660044 | [INFO] - BOOTCORE_CkAxiSsSwitchedOnPll2 >
< @ 00660623 | [INFO] - BOOTCORE_Pll12StartReqStatusPllStarted >
< @ 801821036 | [ERR ] - SD_OverallRetryCnt ( 0x00000000 ) >
< @ 801821454 | [ERR ] - SD_InitDetailedErrorDesc ( 0x0000001B ) >
< @ 801821853 | [ERR ] - SD_InitFailed >
< @ 801837634 | [INFO] - BOOTCORE_HseNoBypass >
< @ 801842670 | [INFO] - BOOTCORE_HseFrequencyDetected ( 0x00000018 ) >
< @ 801843068 | [INFO] - USB_Init >
< @ 801913516 | [INFO] - BOOTCORE_PllUsbLocked >
< @ 805504991 | [INFO] - UART_PeripheralSerialBootLoopStart >

[PatrickF]

Hi @hreysenbach​ 

Please check carefully the HW around SD card. There is obviously some differences.

Is the card correctly supplied with 3.3V ?

Do you use the default pins which allow SD-Card to boot (CLK=PC12, CMD=PD2, D0=PC8) ?

Any HW (like level translator) in between STM32MP15 and SD-Card ?

Btw, I see from your trace that your board have HSE in crystal mode (auto-detected by BootROM). This will create issues later on (TF-A I guess) as Device Tree must be aligned with that (DK2 Starter package is using oscillator and HSE defined in bypass mode).

See also https://community.st.com/s/article/FAQ-STM32MP1-Bring-up-procedure

Regards,

In order to give better visibility on the answered topics, please click on 'Select as Best' on the reply which solved your issue or answered your question. See also 'Best Answers'

[hreysenbach]

Hi @PatrickF​ 

I do see some minor differences between our board and the dev board (STM32MP157C-DK2), the dev board has pull-ups on all of the lines while my board has a pull-up on D3 only and pull-downs on CLK, CMD and D0.

There is no additional hardware between the STM32MP1 and the SD card and the card is getting 3.3V. There is also a 10uF cap on the VDD and VSS pins.

It's strange that the BootROM is detecting a crystal because we are using a 25MHz oscillator. I've just seen that the BootROM is detecting a 24MHz clock instead too...

I did find that the SDMMC1_CLK line was running at ~170kHz when it should be running at 16MHz (please correct me if I am wrong) so maybe something strange is going on with the clocks. So I will investigate that next to confirm that the oscillator is working correctly

[PatrickF]

Hi,

pull-down will ruin weak internal pull-ups (40K) and likely create trouble. Please refer to AN5031.

170kHz is ok during card initialization (standard specify that it should be below 400kHz).

Few facts about HSE:

• BootROM detect HSE digital oscillator when OSC_OUT is grounded. please refer to AN5031 or RCC section in product reference manual. I think you leave it open.
• BootROM cannot make distinction between 24 and 25MHz (as measurement is done using HSI which is not precise enough), so 24MHz is chosen from the possible values list. To use 25MHz, you should setup OTP. Please refer to AN5031 or https://wiki.st.com/stm32mpu/wiki/STM32_MPU_ROM_code_overview#USB_boot. This is not a big issue unless you plan to use USB boot. But 25MHz should be carefully described in your DT settings.
• We recommend to use 24MHz unless an absolute must have on your system. All our SW deliveries are for 24MHz and most 3rd party modules (SOM) come with 24MHz default frequency.

Regards,

In order to give better visibility on the answered topics, please click on 'Select as Best' on the reply which solved your issue or answered your question. See also 'Best Answers'

[hreysenbach]

Hi @PatrickF​ ,

Thank you for your help, it was indeed the pull-downs that were causing the problem. When I removed them it booted to TF-A. I did notice that the pull-downs are present when using a level shifter so I think there was some confusion about that: We are planning on changing the oscillator to a 24MHz (and to tie the OSC_OUT pin to ground like the dev board) based on this conversation, thank you for your advice. We were planning on using the USB boot but rather the UART boot would this cause an issue?

[PatrickF · Accepted solution]

Hi,

CLK could work with either pull-up or pull-down as single direction push-pull driven. CMD and Dx requires pull-ups to work as they are bidirectional with even some open-drain phases during initialization.

I think UART boot should work with non-24MHz crystal as if I remember well bootrom uses HSI for it or autobaud mechanism.

We recommend to have USB (OTG: USB_DP2/USB_DM2) present on your design as this is the only interface (UART is way too slow) for flashing the product using CubeProgrammer. Unlike other STM32 MCUs, the STM32 MPUs use STLINK only for debugging, not for flashing.

Usually, in a real product, a removable SD-Card is not the flash used for regular boot. eMMC, parallel-NAND, Serial-NOR or Serial-NAND are present.

Regards.

[hreysenbach]

Hi @PatrickF​ ,

Perfect, we'll add those pull-ups on the next revision.

Great to hear about the UART. I'll double check the documentation to be sure.

We have access to the USB pins but we need a breakout board which hasn't been designed yet. We were planning on uploading TF-A and U-Boot and then using Ethernet to upload the kernel and rootfs once we can get to the U-Boot console. We are using the SD Card only for development and have QSPI NOR for booting in the application. The SD Card allows faster changes for the device tree and other boot and kernel related files.

Thank you again for your help. It's been really useful and insightful 😀