AM2434: How to configure DDR to self-refresh mode

Which SDK are you using?  I don't think DDR self refresh across resets is supported in the AM24x SDKs as this time.  Any time you perform a warm or cold reset, the device goes through a normal boot flow and the DDR will be reinitialized, thus you will potentially lose data during this time.  Can you explain more of the application?  What type of data are you maintaining across resets.  Could you put that data into internal memory?

Regards,

James

Hi James,

   We use both SDK9 and SDK10. 

   More than 10M bytes need be retaining during reset, so the capacity of using MSRAM is not enough. In addition, we have seen that other custmers have asked you before, and the response is that variables in MSRAM cannot be retaining during reset. And using flash or eeprom takes too long, so we hope to use DDR self-refresh function.

  We have tested that AM243X does indeed reset the DDR chip during reset. So to use the self-refresh function, we may need to disconnect the RESET pin between AM2434 and the ddr chip，unsure if this will cause any additional issues.

  We also hope that you can provide the detailed process of self-refresh configuration, with code is better. At present, we have only found some macro maybe related, tried to assert these bits before reset but it didn't work.

Hi James,

Customer needs to retain larger log data on DDR during reset (Warm reset trigger by MCU SDK API SOC_generateSwWarmResetMainDomain() or watchdog timeout reset), the program is not running on DDR. so hope not reset DDR and keep DDR in self refresh mode to achieve the target.

#1. What is the status of DDR0_RESET pin during reset? it is not specifically addressed, I assume it is not driven during SOC reset period, it will depend on external pull up or pull down?

#2. From TRM description of MAIN Domain Reset effects, don't know if DDR module registers will be reset/cleared by warm reset. Can DDR module be in reset isolation module?

#3. Do you have suggestion regarding this use case?

Hi James, Tony,

Per Tony and Liang's questions, do you have a way to disable DDR reset behaviour before warm restart? The DDR reset firmware behaviour is from your hardcoded boot code?Please confirm???

Is there a way to disable it?If so, could you please provide the detailed procedure to disable it?

Typically, for the warm restart/software restart/Watchdong restart, I don't want to reset DDR, so for the AM243X MCU, please advise.

Thanks

Kelven

Kelven, the low power modes which you are asking for are not available in the AM243x SDKs.  Low power modes such as deep sleep (which includes support for self-refresh) are available in AM62x.  

Regards,

James

Hi James,

Thank you for your quick response.

If we use AM62x as a reference, do you think that we could implement the deep sleep mode on AM243X SDKs?

Thanks

Kelven

Hi James,

If so, could you please provide the design reference for AM243x deep sleep mode?

Thanks

Kelven

Hi James,

From Tony's questions as the followings, could you please provide the response?

Customer needs to retain larger log data on DDR during reset (Warm reset trigger by MCU SDK API SOC_generateSwWarmResetMainDomain() or watchdog timeout reset), the program is not running on DDR. so hope not reset DDR and keep DDR in self refresh mode to achieve the target.

#1. What is the status of DDR0_RESET pin during reset? it is not specifically addressed, I assume it is not driven during SOC reset period, it will depend on external pull up or pull down?

#2. From TRM description of MAIN Domain Reset effects, don't know if DDR module registers will be reset/cleared by warm reset. Can DDR module be in reset isolation module?

#3. Do you have suggestion regarding this use case?

1. The DDR0_RESETn signal is hi-z during a warm reset.  

2. The DDR module on AM243x does not have isolation feature.

3.As stated previously, the low power modes you are requesting are not available on AM243x.  We do not have any design reference for these features as they are not implemented for AM243x.  

Is there any way you can avoid a warm reset in your application.  Why does the processor have to be reset?  If you need to perform some low power modes, i suggest you look into AM62x or other Sitara processors which support more sophisticated low power modes.  Is there a requirement to use AM243x?

Regards,

James

Hi James,

Thank you for your response.

Here is a big problem for DDR0_RESETn pin status of AM243x EVM board as the following:

#1. We have captured DDR0_RESETn pin behaviour during AM243x booting as the above picture showed, the Phase 1 is MCU initialization and 1st booting period, there is pull-high on the DDR0_RESETn pin, as you said, the DDR0_RESETn pin should be Hi-Z during warm reset, the DDR0_RESETn pin status should be High, but actually, the pin status level is 0.24V as the picture showed, the Phase 1 is MCU behaviour, which is NOT controlled by our firmware, so could you please explain why the DDR0_RESETn pin status is 0.24V during Phase 1?

Thanks

Kelven

I'm a little confused by when the scope shot was taken.  If Phase1 is during initialization when the bootloader is running, then there would be a time when the DDR initialization is executed and the RESETn signal is driven low.  There should not be an external pullup on the RESETn signal, it should be pulled low on the board.  The 0.24v may be a result of the drive low fighting with the external pull up.

Regards,

James

Hi James,

       Phase 1 started before our bootloader(sbl_ospi) running, and end after bootloader running Bootoloader_runSelfCpu(), and there is a pull-up on the reset DDR_RESET pin, so we said "the Phase 1 is MCU behaviour, which is NOT controlled by our firmware". After sbl_ospi running Bootloader_runSelfCpu(), Phase 2 started.

I would suggest to step through the code sequence to determine what software event correlates to each edge of DDR_RESETn.  Check the state of the DDR PLL and PSC.  

Regards,

james

Hi James,

    Let me explain the code strategy corresponding to the above  DDR-RESET waveform test.

    For the purpose of testing, we deleted the DDR in sbl_ospi sysconfig and added it to the application sysconfig, so you can see that phase1 is longer and phase 2 is shorter. In addition, we confirm that phase1 is not a behavior of our firmware through following methods:

     1) Adding a delay at the start of sbl_ospi, PHASE 1 will change to longer.
          

     2) Debug sbl_ospi, DDR RESET PIN level remains under PHASE 1 until called Bootloader_runSelfCpu() to load application.

     3) Delete application sysconfig DDR, the DDR RESET PIN will remain in the PHASE 1.

    For PHASE 2, we found that it triggered by ddr_start. 

So, We think PHASE1 is your chip strategy or BUG, which cannot be modified on our side, PHASE2 alse does not yet know if any registers can be modified to mask.

It looks like what is happening is that there is an internal pull down during PHASE1, and then at the beginning of PHASE 2, the PHY takes over, drives the RESET low as part of the beginning of init, and then drives it high for normal operation.  Do you see this behavior for both cold reset and warm reset?

Regards,

James

Yes, we checked both code reset and warm reset, same behavior.

Ok, thanks.  So without the isolation feature, you won't be able to control the RESET signal across a device reset.  

Regards,

James

Thanks for your help. Next we will try to find a solution on the hardware. After verification, if there is any more problem, we will update here. If not, we will close this topic.