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.

DRA626: BOOT ROM watchdog behavior

Part Number: DRA626

as below description, I understand after BOOTLOADER scan the device list set by bootmode, the BOOTLOADER will enter dead loop and waiting for watchdog(3 minutes) reset. But from test result seems the BOOTLOADER scan the device list in endless loop, for example I set bootmode[5:0] = 111110b, all device in the list are empty, UART0 output CCCCCCCC consequently, never stop, so I think the watchdog never overflow.

So please help check ROM code if below description is not accurate. 

  • Hi Tony,

    It is more likely that ROM code doesn't enter endless loop to wait for watchdog. If it was, you would see only one 'C' every 3 minutes.

    Endless 'C', denotes ROM doesn't wait for watchdog , but restarts the booting list, or issues a global reset. In this case you cannot notice the watchdog restart, so I presume it is set and working as described. Watchdog is still useful if boot hangs in the middle for some reason.

    I observe the same behavior in DRA7xx.

    I'm not the expert who can confirm though.

    Regards,

    Stan

  • Thanks Stan,

    Yes, we are working with customer debugging boot hanging, expect the watchdog reset to resume, but the device is not reset automatically, and also did not observe RSTOUT_wD_OUT from pin D5 with oscilloscope, so hope BU confirm it.

  • Tony,
    What is the boot peripheral at which boot hangs?

    Stan
  • Hi Tony,
    Can you please post your findings when you have some?

    Thanks,
    Stan
  • Stanislav Stilyanov said:
    What is the boot peripheral at which boot hangs?

    The BTMODE[4:0]= 000010.

    we don't know at which boot hangs.after hanging, observed 10s interval pulse on RSTOUT_WD_OUT.

     The pulse width is 600ns.

    The test procedure is configure 50s period in watchdog, plus the boot time, so the right interval on RSTOUT_WD_OUT is about 70s. and it is the right behavior during test. but after hanging, RSTOUT_WD_OUT output interval 10s.

    Customer reproduced the hanging 8 times. each spent: 18H59‘, 35’,  6h4', 10h51', 3h16', 6h, 30', 23h,

    after hanging, DRA624 can't reset by RESETz, need PORn to recover the system.

  • Tony Tang said:

    The test procedure is configure 50s period in watchdog, plus the boot time, so the right interval on RSTOUT_WD_OUT is about 70s. and it is the right behavior during test. but after hanging, RSTOUT_WD_OUT output interval 10s.

    Customer reproduced the hanging 8 times. each spent: 18H59‘, 35’,  6h4', 10h51', 3h16', 6h, 30', 23h,

    after hanging, DRA624 can't reset by RESETz, need PORn to recover the system.

    Tony, I want to make sure I understand the test setup you are describing. The system is set to boot with BTMODE[4:0]= 000010 (UART0  then SPI0 then NAND (via GPMC) then NANDI2C (via GPMC)). You are booting a test program (from which interface? UART?) that is expected to startup and set the watchdog timer to expire after 50s and reset the device? And that test program runs for some extended period as expected (you see the RSTOUT_WD_OUT pulse low every ~70s). But then after some period of time the test stops behaving properly (and boot no linger succeeds?) and the device appears to be reseting itself every 10s?

    Is all that right? Any chance you can find out what the ROM was doing during those 10 seconds? Can you connect with CCS and get the PC, dump the ROM data structures (assuming it is still executing in the ROM), maybe look at the WDT registers, or the reset source registers, etc.?

    Regards, Daniel

  • Hi Tony,

    We haven't heard back from you, I'm assuming you were able to resolve your issue.
    If not, just post a reply below (or create a new thread if the thread has locked due to time-out).

    Regards,
    Yordan