topic Re: How can I keep DDR3 RAM content when performing warm reboot? in i.MX Processors

How can I keep DDR3 RAM content when performing warm reboot?

caue — Thu, 31 May 2018 12:22:08 GMT

Hi everyone,

we're using an i.MX6Quad on a custom board with 2 GByte DDR3 RAM.
We would like to perform a watchdog WARM reset while keeping the data in the RAM valid.

In our scenario it would look like so:
1. watchdog warm reset triggered by kernel code
2. Bootrom
3. U-Boot SPL in SRAM -> should detect the warm reset cause and therefore not configure MMDC
4. U-Boot in DDR3
5. Kernel in DDR3

When connecting to the U-Boot preloader (SPL) via Lauterbach JTAG-Debugger, I can see that the MMDC has lost all of its settings like e.g. ammount of row and column bits, RAM timings etc.
Is this the expected behaviour when performing a warm reset?

My initial expectation was that the MMDC would keep all its RAM settings. I also would have guessed that the MMDC is indicating that it is in self refresh mode by asserting bit DVACK in register MAPSR.

I then checked the following settings:

SRC_SCR[warm_reset_enable] -> bit is programmed
SRC_SCR[warm_rst_bypass_count] -> Wait 16 XTALI but also changed it to 0x00 in order to make it wait indefinetly for the MMDC handshake
CCM_CCDR[17:16] -> handshake signals are NOT masked

What steps are necessary to get access to the DDR3 RAM again whithout changing its content?

best regards,
Christian

Re: How can I keep DDR3 RAM content when performing warm reboot?

Rodrigue — Mon, 11 Jun 2018 15:57:53 GMT

Hallo Christian,

In case of a warm reset, please refer to the RM 44.4.7.2.

The MMDC must issue a LPMD request (in the MAPSR). It can only synchronize with the CCM through that signal.

Once the CCM acknowledge and send the response back to the MMDC, the latter can enter in self-refresh mode.

best regards,

Rod

Re: How can I keep DDR3 RAM content when performing warm reboot?

caue — Wed, 13 Jun 2018 08:13:20 GMT

Hi Rodrigue,

thank you very much for your reply.

I read your mentioned section 45.4.7.2, it describes the neccessary steps for transitioning MMDC to self refresh.
However I think that SRC should take care of that by means of hardware, if configured correctly.

The following describes my train of thoughts, I would apprechiate it if you could find any errors or misconceptions I might have.

While doing some experimentation I set the MMDC into self refresh mode via the LPMD request as well as DVFS request using a Lauterbach-JTAG-Probe. This led to the respective ACK-Bit to assert.
After waiting a couple of minutes I cleared the LPMD/DVFS request, in turn the acknowledge bit would deassert and I could resume the programm execution without any problems thus the self refresh mechanism seemed to work when triggered manually.

In the System Reset Controller (SRC) section 60.6.1.2.5 WARM RESET one can find that the
SRC will take care of transitioning MMDC to self refresh mode via hardware handshakes (only when SRC_SCR[warm_reset_enable] is set) whenever a WARM RESET qualifying reset source occurs in the system.

In Chapter 70 Watchdog Timer (WDOG) it is stated that "Upon timeout, the WDOG asserts the internal system reset signal, WDOG_RESET_B_DEB to the System Reset Controller (SRC)"

In section "60.6.1.1 Reset inputs and outputs" figure 60-5 one can see that WDOG_RESET_B_DEB qualifies as a WARM RESET source.

This is why I concluded that the SRC would automatically put the DDR3 in self refresh once the WDOG reset occurs.

In section 60.6.1.2.5 WARM RESET, step 5 it says "Wait for mmdc_dvfs_ack signal from the MMDC. If no ack is received during warm_rst_bypass_count number of XTALI clocks, COLD reset will be generated."
That is why I temporarily set the SRC_SCR[warm_rst_bypass_count] bitfield to 0x00 in order to make it wait indefinitely for the ACK signal.
Since our system actually performed the reset I concluded that the handshake must have been occured prior to the (warm) reset.

After the reset, the BOOTROM is loading our U-Boot preloader into OCRAM. At this point I had a look into the MMDC state via JTAG.
It turned out that the MMDC lost all of its configuration and is NOT indicating self refresh (DVFS acknowledge, DVACK = 0).

The description of the MMDC hard reset (section 45.4.7.1) seems to fit the observed behaviour of our system.
What did I do wrong or what might have led to the MMDC to do a HARD RESET instead of a WARM RESET?

Best regards,
Christian