This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM5748: Issue with potentially damaged SD card due to Linux restart when in 1.8V IO mode (e.g. SDR104)

Part Number: AM5748

As was discovered by TI ( I guess end of last year, at least it was the first time some related info was included in the SDK release documentation) there is a risk of damaging the SD-card on the AM5748 eval-kits in the case when a faster SD-mode is used (one which uses 1.8V IO voltage, e.g. SDR104) and Linux suddenly reboots without a power cycle. Scenario like this:

  • Linux host system negotiates e.g. SDR104 mode after startup
    • IO voltage starts at 3.3V and after negotiation is dropped to 1.8V as per specification
  • SD card is running in SDR104 mode during operation
  • Unexpected crash and reboot of Linux occurs (e.g due to a watchdog timeout because of a SW bug or an intentional “soft” reboot, “ctrl-alt-delete”)
  • CPU makes a soft restart, without power-cycling the SD card
    • Hence SD card remains in SDR104 mode
  • Linux boots again and 3.3V is applied as IO voltage communicating with the SD card.
    • SD card is damaged due to still being in SDR104 mode when host applies 3.3V on the IO lines

The solution TI implemented in latter SDK releases was simply to not allow anything faster that HS mode, which limits to 25MB/s and uses 3.3V only (change in device tree settings). This far we have used the same strategy on our CPU-module with AM5748, but this is a performance-limiting factor of course, and we want to be able to run SDR104 mode in the end as this greatly improves flash performance. In order to remove this potential failure we must make sure the Vdd to SD-card is cycled every time Linux reboots.

In order for tthis to be implemented we need some way of being sure we capture all reboots and make sure they initiate a power-cycle of the SD card.

From a SW perspective it basically boils down to two different scenarios:

  1. Normal reboot, requested by SW (e.g. reboot commando issued for some reason, as far as we understand Linux the ends up in these commands: https://linux.die.net/man/8/reboot   
    http://man7.org/linux/man-pages/man2/reboot.2.html  
  2. A reboot due to watchdog timeout (using the Sitara core watchdogs)

Could you please elaborate on how the reboot commands are implemented in the TI SDK distro? Will they eventually end up in a complete reboot, starting from MLO/Uboot in the primary boot-source, or something “higher up”, e.g. just rebooting from Linux Kernel? As far as we can see something is changing the setting in the PMIC in order to change the LDO1 back to 3.3V from 1.8V during the reboot process (if SDR104 mode was used during normal execution).

Our SD implementation is basically equivalent to the one used on the AM5748 dev-kit. As I see it we need to implement some type of “gating” of SD Vdd which we make sure cycles the SD power (and possibly cycles the IO voltage at the same time). But we need to find some mechanism that can initiate this process early in the boot-stage.

BR Jimmy

  • Hi Jimmy,

    Reboot essentially does a SoC reset so this starts all the way from MLO/U-boot.
    That said it is only rebooting the SoC and not touching the PMIC. So the voltages
    are in tact.

    Log:https://pastebin.ubuntu.com/p/ZfJxtdmk72/

    Do you plan to implement a software mechanism to catch a reboot and pull the voltage down to 3.3.V?

    SPL is the earliest i can think of for any voltage gating mechanism.

    Regards,
    Keerthy

  • Hi,

    Thanks for the response!

    I have however a bit hard to understand how the SD card in fact can get damaged if there is no change to the PMIC LDO1 output and hence the IO voltage of the SD card? This issue is present on the TI AM5748 IDK, and also documented in the most recent IDK release notes, where the Device-tree was changed in order to only allow HS-mode. We have also seen this happen on the AM5748 IDK before this change in Linux was introduced, i.e. SD cards breaking after a sudden reboot. Could you elaborate on how and when the LDO1 voltage level in PMIC is changed?

    In principle we want to implement a solution which allows us to use the SDR104 mode without any risk of damaging the SD-card. I guess our basic question to TI is how the combination of AM5748 and companion PMIC TPS6590378ZWS shall be implemented in order to use a SD-card in SDR104 mode without risking to damage the SD-card due to a warm reboot.

    Best Regards, Jimmy

  • Jimmy,

    You can refer to the DRA76 EVM for an example of how the SDCard related supplies are connected to avoid the reliability problem.

    Regards,

    Kyle

  • Hi,

     

    Thanks for the update and reference schematic. A few follow up questions from my side:

     

      1. The only real difference I can see compared to the AM5748 IDK schematic is the power-switch, U96, which controls the Vdd to the SD-card, and which in its turn is controlled by a CPU GPIO (H_MMC_PWR_ON), is this correct or have I overlooked some other important difference?
      1. Since the enable input of U96 is pulled to IO_3V3 (Vin of U96) U96 will essentially supply VIO_3V3_SD as soon as IO_3V3 is available, unless the CPU pulls H_MMC_PWR_ON to GND. In this way the main CPU can reset the SD card, is this the correct understanding of the intention of this circuitry?
      1. In order to make sure SD card is in fact power-cycled at a warm CPU reboot, is there then some low level code which sets the GPIO H_MMC_PWR_ON to GND for a certain period of time, or what mechanism makes sure the SD card is power-cycled?
      1. In the case of AM5748 there is a possibility to boot-strap the CPU to boot directly from SD-card, in this case I assume it is the BOOT-ROM itself that sets up the pins related to the MMC1 interface and starts to communicate with the card at default speed, and in order for this to work properly my view is that the SD-card has to be power-cycled before this stage, how is that achieved using the design provided in the example?

     

    Thanks!

     

    BR Jimmy

  • The SD card spec is a little vague when specifying IO voltage tolerance. It does state the peak voltage on all lines is VDD +0.3V (not specific to operating voltage). However – in some addendums referring to LVS cards, its states the card may or may have 3.3V tolerance. To avoid any possible damage, the processor IO and card IO voltages need to be kept in sync.

    Note: As part of the card negotiation process, the card needs the ability to be reset. The only way to perform this is to power cycle the card (VDD). Therefore – it is recommended to support a mechanism to cycle VDD (via regulator or load switch enable)

    If processor IO power is set to default (3.3v) on any reset condition: To keep in sync, the card IO voltage need to be reset by toggling the power (VDD) to the card. This can be done by gating the card’s VDD enable with WarmResetz (and possibly PowerOnResetz, depending on system). Ensure the Cards VDD has time to ramp/stabilize before commands are issued.

    If processor IO power remains unchanged on warm reset condition: I don’t believe anything needs to be done. Software will reboot, and will to negotiate to lower voltage level (but will receive no voltage change is required since already at 1.8V).

    Because cards can be ejected/re-inserted…software must monitor the card detect. If the card is ejected, the processors IO must be reset to default (3.3v) to prepare for when the card is re-inserted.

    To answer your previous questions:

    1 and 2:  As mentioned, card power cycle (VDD) is required to support low voltage modes, as its only way to reset the card.  It is important to ensure the card is enable by default is used as a boot source.

    3.  No - there is no code (in ROM) that ensure the VDD is cycled.  That is why I mentioned gating enable with WarmResetz and/or PowerOnResetz (to reset the card if the processor IO voltage is reset to 3v3).  This is not done in Jacinto EVM example, and we've not seen any issue (EVM quantity is not large).  However - It is recommended to ensure the SD card is reset to stay in sync with processor IO levels.

    4. Yes - the SD card is possible boot source for AM5748,  Yes - ROM will setup the pins for MMC and communicate with card in default mode (SD).  The ROM does not do any voltage negotiation.

    Please let me know if you have additional questions.

  • Thanks for the explanation!

    Now I think we have all information required in order to update the design to fulfill the spec.

    BR Jimmy