• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 100 subscribers
  • Views 1358 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Warm reset watchdog

Ken Brown13794
Prodigy 200 points
Other Parts Discussed in Thread: TPS65023, OMAP3503

So we have a number of our boards back, and we find that when you press the warm reset button, some boards reboot immediately, where others will wait maybe 10 seconds before rebooting.  (We are performing the reset with the processor booted into u-boot).

Our warm reset circuit is very standard, I think.  When pressed, it connects nRESWARM (on the 65920 PMIC) and SYS_nRESWARM (on the OMAP 3503) to ground.  When not pressed, those two signals are pulled to 1.8V_IO with a 4.7K resistor.

Interestingly, if software (u-boot) issues a reset (writing 2 to PRM_RSTCTRL) the same thing occurs.  Some boards will reset immediately, others wait 10 seconds.  An individual board will behave the same no matter whether you do software or button reset.  Either it'll be immediate reset or a 10 sec reset, depending on the board.

On boards which exhibit the 10 second reset, the boot rom reports that it has performed an MPU watchdog reset when it (eventually) launches xloader (bit 4 of the Reset reason field of the Booting Parameters Structure is set.  Entire byte value is 0x51).  On boards which do not exhibit the 10 second reset, the boot rom does not report a watchdog (Reset reason = 0x41).  So it seems clear that something in the boot rom is dying on boards which have the 10 second reset, and the watchdog is saving us.

It seems to not matter whether we are booting from our MMC card or from the on-board NAND chip.  Nor does it seem to matter whether we've programmed our warm reset sequence in the PMIC.  And the chip revision seems to be the same on all boards.

I've looked at the chip errata (SPRZ278D, revised March '09), and I think I've been able to rule out any errata that appeared to have some relevance.

Anyone else seen this kind of problem before?

Any suggestions on how to figure out why the boot rom sometime dies on reset and sometimes does not (depending on the board)?

And does anyone have any ideas regarding things that might be overlooked by xloader and u-boot that are relevant?

 

Thanks in advance,

Ken

 

  • 0
    Prodigy 10 points

    Hi,

    we have a similar problem.

    Our system has an OMAP3503 processor and a TPS65023 PMIC with LPDDR-RAM and NOR-Flash.

    When applying a software reset by writing 2 to PRM_RSTCTRL (global software reset), some of our boards always reboot properly and some do never. It seems that booting starts as some of the very first steps perform (two out of four LEDs get switched on by GPIOs), but then the system hangs up and only disconnecting from power supply heals it.

    Interestingly when writing 4 to the PRM_RSTCTRL register (DPLL3 software reset), reboot works on all tested boards properly.

    Now in the OMAP-TRM (spruf98o.pdf), Table 4-446 on page 592, bit RST_DPLL3 is described as follows: 0x1: Asserts the DPLL3 software reset and induces a global cold reset on the whole chip. The software must ensure the SDRAM is properly put in self-refresh mode before applying this reset.

    whereas bit RST_GS is only commented with 0x1: Asserts a global software reset.

    We now wonder why for DPLL3 reset (which is described as a cold reset) it is necessary to put the SDRAM in self-refresh mode and for the global software reset it is not. Could it be that it is just the other way? That the reboot problem occures because actually for a global software reset the SDRAM needs to be put in self-refresh mode and not, as described, for DPLL3 reset?

    What could happen if no attention is payed in putting the SDRAM in self-refresh mode?

    Thanks in advance,

    Markus

  • 0 in reply to Markus Mayrhofer
    Intellectual 455 points

    Hi,

    I'm having the same problem with a Beagleboard xM here.

    If I execute this command in u-boot (i.e. setting bit RST_GS of PRM_RSTCTRL register to 1):

    mw.l 0x48307250 0x00000002

    the board only hangs but does not reset. It seems Global Software Reset does not work fine or we are missing something.