i.MX535 Reboot Lockup

[G1z]

We are experiencing a condition where the i.MX535 will lock up during repeated reboot cycles. To reproduce this, in our test environment a script is executed late in user-space startup to reboot the board.  We use the busybox /sbin/reboot command to cause the reboot, which is implemented using a zero length timeout on the watchdog (see arch_reset() in the linux 2.6.35.3 kernel). If we reboot the board enough times, eventually the processor will lock up and not restart. Asserting RESET_IN to the i.MX535 (or a POR) will restart the processor.  We are using u-boot 2009.08, and linux-2.6.35.3, from LTIB 2.6.35_11.09.01, patched with the latest patches in that branch.

The hardware is based on the QSB and uses the MC34708 PMIC. During the lock up state the reset signals from the PMIC are not asserted, all of the voltage rails are good and do not experience any type of drops or abnormal behavior during the reboot. The only change in HW is the DDR clock rate. During normal operation the clock is running at 400MHz. When the processor locks up it drops to 333MHz, the default frequency. When a successful reboot occurs the DDR clock does quickly change from 400MHz down to 333MHz and then back to 400MHz. When a reboot fails the processor never tries to read data from external memory.

It almost appears as if the processor is getting stuck in the internal boot ROM during startup. Has anyone seen this type of lock up before?

[JorgeRama_rezRi]

Hi Geff,

This looks like a PMIC issue more than a processor issue. The processor needs the POR and RESET_IN signals to boot, which are controlled by the PMIC, so something must be holding them down on that side. Could you please send scope shots of the following signals in good and bad resets?:

- WDI

- RESETB

- RESETBMCU

- 1V8_SW5 (if you are using this voltage as RESETB and RESETBMCU reference as it is in the QSB. If not, please monitor the voltage you are using instead)

- SPIVCC (this voltage is needed for proper WDI detection)

My first thought would be the WDI signal toggle time is not enough for a proper reset, so a useful test would be to increase the time of this signal if you system allows it.

Were you able to implement your workaround?

Best regards.

Jorge.

[txbest]

Hi Geff!

     I have met this problem too.My processor is i.MX536.

     There is a chance (about 1/10)that when you reboot the board by typing "reboot" command ,the Linux system can not start up normally.Until we power it down,then power on,the system can start up

     Did you have any solutions about this issue?

[G1z]

We are testing a patch that configures a GPIO as a watchdog output (on the MX535 its GPIO_9). This is connected the watchdog input (WDI) pin on the MC34708 PMIC. The PMIC is configured to go thru a cold reset cycle when the WDI is asserted low. The resulting cold reset in the PMIC toggles the RESETB and PORB signals to the processor.

This looks like it might be a work around, but I'm still not sure what the root problem causing the lockup might be.