Because of the holidays, TI E2E™ design support forum responses will be delayed from Dec. 25 through Jan. 2. Thank you for your patience.

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.

AM5728: I/O isolation and DDR3 self-refresh

Part Number: AM5728

I'm trying to determine if it's possible to temporarily reenter I/O isolation mode without loss of the contents of DDR3 memory, to be able to reconfigure padconf/iodelay at a later point in u-boot. I had hoped to use some helper code in internal SRAM that puts the DDR3 into self-refresh, enters I/O isolation, performs the reconfiguration, leaves I/O isolation, takes DDR3 out of self-refresh, and returns execution to code in DDR3.

The problem is that to keep DDR3 in self-refresh, CKE needs to be driven low through all this, but my impression is that the DDR3 CKE signals are not exempt from I/O isolation, which means they'd get pulled to VTT resulting in undefined behaviour.

Can you confirm that I/O isolation mode will indeed cause all DDR3 signals to go high-Z, including CKE?

If so, then it would probably be a good idea to recommend am57xx users to use a gpio-controlled switchable VTT supply that's disabled by default to prevent the DDR3 cmd/addr signals from being pulled to VDD_DDR/2 during I/O isolation, which could cause undefined behaviour in the ram and/or excessive current in the ram's input buffers. (It would be desirable to reset the ram if this were to happen, but it is very unclear when exactly EMIF asserts the ddr3 reset signal and whether software can request it to do so.)

  • Matthijs, i have to double check, but i believe the DDR signals are not affected by the IO isolation, as there is no padconfig or iodelay to configure on them.So after putting DDR3 into self-refresh, you could reconfigure the other IOs while the DDR IOs would retain their state and thus keep CKE low to keep DDR in self-refresh.

    Regards,

    James

  • If true this would be great news! If the DDR3 pads are not affected by I/O isolation then I don't even need to jump into SRAM and put DDR3 into self-refresh, code should be able to continue to run from DDR3 memory.

    I agree that it wouldn't really make any sense for I/O isolation to affect DDR3 pads on the AM57xx, but the existence of the ISOOVR_EXTEND bit in the PRM_IO_PMCTRL register would seem to imply otherwise. However, that register seems to have been inherited verbatim from omap4/5 and the bit mentions "OFF mode" which isn't even a thing on the AM57xx, so it may simply be a red herring.