Skip to main content
F
Fee
Visitor II
November 27, 2020
Solved

Issue rebooting from eMMC with STM32MP157C Silicon Version B

  • November 27, 2020
  • 2 replies
  • 2639 views

0693W000005CsNXQA0.pngHi,

I have a custom Board with a STM32MP157C marked 'B' with an attatched SD card and an eMMC (one from ISSI).

First of all I am aware that this revision is having the errata 'eMMC boot timeout too short'. I also read through this post: https://community.st.com/s/question/0D50X0000BiBhHQSQ0/stm32mp153a-failed-to-boot-from-emmc

The problem I am having is that I indeed can boot from the eMMC when resetting it and the MP1 with the NRST pad (using a switch if that matters). TF-A tells me the following reset reason:

NOTICE: CPU: STM32MP157CAA Rev.B
NOTICE: Model: STMicroelectronics custom STM32CubeMX board
INFO: Reset reason (0x14):
INFO: Pad Reset from NRST

which also makes sense.

If I let the system boot and try to reboot it via U-Boot or Linux console it won't start. After the shutdown the boot from eMMC fails and the serial boot is entered.

By using my SD-Card I know that the reset reason is MPSYSRESET when rebooting from the command line, as seen in the TF-A trace:

INFO: Reset reason (0x54):
INFO: System reset generated by MPU (MPSYSRST)

I cannot boot from the eMMC if I unplug the power from the board and plug it back in neither (this should make sure eMMC and MP1 are powered up at the same time and therefore trigger the errata). There are different reseted functions from the different reset lines but as far as I understood it the MPSYSRST should lead to an app_rst. The reset via NRST pad should generate the same app_rst, as stated in the reference manual (see the picture).

0693W000005CsNXQA0.pngSo for my understanding the same reset should lead to the same reboot behaviour.

My goal is to make sure the described behaviour is caused by the errata. Has anyone got similar behavioural with a nonconform eMMC and silicon rev. B?

Cheers

    This topic has been closed for replies.
    Best answer by PatrickF

    We tested ISSI IS21ES04G 4GB and IS21ES08G 8GB, both were failing on Rev.B, even in cold boot (With STPMIC1A power sequence).

    Maybe your power sequence is different or the ISSI internal FW timing has evolved a bit which allow cold boot on your platform with Rev.B silicon.

    I confirm we tested successfully the boot of same devices on Rev.Z silicon.

    Reading eMMC standard, I this it is probably not linked to an incompatible state as CMD0+0xF0F0F0F0F0 is accepted in all states. But I will check internally if we have some information.

    Regards.

    2 replies

    P
    PatrickF
    Technical Moderator
    November 27, 2020

    Hello,

    Which eMMC reference are you using ?

    The Rev.B issue is related to the time the memory take to answer to boot sequence, this time might be different in cold and hot boot.

    Or your eMMC is probably kept in a mode not compatible with BootROM expectation (e.g. the shutdown command might put the eMMC in a specific mode).

    BootROM use the eMMC with a JEDEC boot sequence, using GO_PRE_IDLE_STATE command (CMD0 + 0xF0F0F0F0F0), then set CMD low to request the eMMC to provide boot sector data on DAT0 pin. This command might not be enough in your case (could depend on your device and the surrounding HW/supplies)

    When using STPMIC1, the STPMIC1 HW ensure a power cycle upon NRST low detection.

    If you are using discrete components for supplies, you have to ensure your eMMC is reset when NRST pulse occur. This could be done either by doing a power cycle on the eMMC supplies or connecting NRST to the memory reset pin (need to permanently enable this pin in the eMMC RST_n_FUNCTION register). This is partly covered in AN5031.

    Regards.

    F
    FeeAuthor
    Visitor II
    November 27, 2020

    Hello @PatrickF​ ,

    thank you for your answer.

    We are using a ISSI IS21ES04G-JQLI as our eMMC. Also we have a STPMIC1A on our board.

    Unfortunately I cannot measure any data lines so I can't confirm the boot command sent to the eMMC but from it beeing able to boot from cold boot I assume that it is getting send. I also agree that the eMMC is probably in a incompatible state for the BootROM.

    Does the silicon revision z have any known incompabilities with eMMCs or can it be used with any eMMC (JEDEC spec v5.0/5.1)?

    Cheers

    P
    PatrickFAnswer
    Technical Moderator
    November 27, 2020

    We tested ISSI IS21ES04G 4GB and IS21ES08G 8GB, both were failing on Rev.B, even in cold boot (With STPMIC1A power sequence).

    Maybe your power sequence is different or the ISSI internal FW timing has evolved a bit which allow cold boot on your platform with Rev.B silicon.

    I confirm we tested successfully the boot of same devices on Rev.Z silicon.

    Reading eMMC standard, I this it is probably not linked to an incompatible state as CMD0+0xF0F0F0F0F0 is accepted in all states. But I will check internally if we have some information.

    Regards.

    S
    SimonJFisherMB
    Visitor II
    April 9, 2025

    I thought I'd restart this rather than start a new topic. I have a number of devices already deployed and want to be able to remotely reboot them. is there a workaround instead of using Linux reboot (shutdown -r) to effect a complete restart?

    Terms & ConditionsAccessibility statement