Watchdog causes warm reset, from which the i.mx6 never recovers

[benediktfranz]

Hello everyone,

here's the situation: We have a custom i.MX6Q board with 1 GByte of LPDDR2 memory. Until recently, only half the RAM was working (there are two chips, one connected to MMDC0 and the other to MMDC1, only one CS is used per MMDC). We got the other half working but suddenly, the system would no longer return from a warm reset. I.e. when I typed 'reset' into the U-Boot console, it would print 'resetting ...' but the system never turned back on again. Same thing in the OS.

I checked the reset routine in U-Boot and the way it makes the system reset is by setting the watchdog timeout for WDOG1 to 0.5 seconds (minimum, WDOG1_WCR = 0x0004), trigger the watchdog service routine once and then enter a while(1) loop, waiting for the reset to occur. This worked just fine until we got the other half of the system RAM working (not sure if there is a direct connection, but when I reworked one board to use only half the RAM again, the reset started working again just fine).

It's really quite strange. I was able to determine that the watchdog reset does get triggered (the board power consumption drops significantly) but it does not return from the reset, i.e. it never starts up again and needs to be reset externally. I was able to devise a workaround but I'm not 100% confident in it since I don't fully understand why the reset doesn't work in the first place. When I clear the warm_reset_disable bit in the SRC_SCR register, so that any warm reset gets turned into a cold reset, the system does restart fine but, of course, the question remains, why doesn't a warm reset suffice to properly reset the system? The SRC_SCR register is set to 0x00000520, so mask_wdog_rst is set to 'wdog_rst_b is not masked' and warm_rst_bypass_count is set to 'Wait 16 XTAL cycles' - so I don't think it's one of the MMDC inhibiting the warm reset.

Does anybody have any thoughts on why the reset worked fine when only half the RAM was used and stopped working properly once the second half was added? What we did to enable the second RAM chip was change some MMDC configuration and also change the DDR Memory Map default config (BOOT_CFG3[5:4]) from 0x00 (Single DDR channel) to 0x10 (4KB Interleaving Enabled) - might this affect some of the reset behaviour settings?!

Thanks a lot for any thoughts!

Benedikt

[benediktfranz]

Hi Igor,

Thanks for your response. We did use the latest LPDDR2 Script Aid to initialise the MMDC config settings. We adjusted a few timing parameters though, but they shouldn't affect reset behaviour, right?

If the LPDDR2 chips are not in a reset condition, it would figure that the chip which prevents the reset must be second one (we recently added) because it was working fine with only the first chip in use. Either way, if I understand the warm_rst_bypass_count parameter (page 5079 on IMX6DQRM.pdf, Rev. 4 09/2017) correctly, the system should still trigger a cold reset if the MMDC does not acknowledge the warm reset request within 16 XTALI cycles, right? So a cold reset should trigger sooner or later but it never does.

[igorpadykov]

Hi Benedikt

except mmdc there are many other modules described in Table 60-4. SRC reset functionality

which may behave differently in warm and cold reset. Also external chips may stay in different

state than expecting processor after reset.

One can check if Pre-Charge All command (this is required one for each channel,
and each chip select within a channel) is present (to reset the LPDDR2 memory)
in script before use Mode Register Write command.
Since the LPDDR memory could have been in a state of trying to read memory back to the processor, or
receive Write memory from the processor when the DDR clock (SDCLK) was removed, it is necessary to
issue a Pre-Charge All command at the beginning of the LPDDR initialization cycle so that it will accept
Mode Register Write commands.

Best regards
igor

[benediktfranz]

Hi Igor,

Thanks again for your response. I had a look at Table 60-4, as well as a good read through Chpt. 60.6.1.2.1 Reset Qualification, and I couldn't find any mention of peripherals which could inhibit a warm reset, except the MMDC through mmdc_dvfs_ack. This doesn't appear to be a status bit I could poll, is that correct?

The init script does contain the precharge all command to both channels (0x00008010 to 0x021b001c and 0x021b401c).

[igorpadykov · Accepted solution]

Hi Benedikt

regarding "peripherals which could inhibit a warm reset" - it does not matter

as "warm reset" does not guarantee that module become in the state suitable

for reboot. It should be performed cold reset.

Recommended solution is to reset all power board as it is done on Sabre SD schematic

spf-27392 p.21 (PWRON).

Best regards
igor

[benediktfranz]

Okay, thanks for your help. We'll use the cold reset to make sure our system is in the correct state to reboot.

[igorpadykov]

Hi Benedikt

if all board power was not reset, then LPDDR2 memory may not be in reset condition.

Also DDR3/L memories have a separate dedicated RESET signal, which is not present in
LPDDR2. The assertion of this signal guarantees the DDR memory is in correct state for initialization.

May be recommended to recheck memory initialization script and use latest script aid from

i.MX6ULL_LPDDR2_Script_Aid 

Best regards
igor
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------