AnsweredAssumed Answered

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

Question asked by Benedikt Franz on Feb 23, 2018
Latest reply on Mar 5, 2018 by Benedikt Franz

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

Outcomes