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.

F28035 - Watchdog reset problem



Hi,

I'm trying to implement a software reset to reinitialize all my systems. To simplify this, I thought about using the watchdog to trigger a reset on the controller. By default, watchdog is disabled. When I detect a reset condition, here's the code I call :

//Enable watchdog
EALLOW;
SysCtrlRegs.WDCR= 0x0028;
EDIS;

//Kill controller
for(;;);

When I'm hooked with the debugger and I get there, it resets to 0x3FF599, saying No source available for "0x3FF599". If I resume, it stays stuck there. 

I'm not sure what I'm missing... From what I found on E2E, it could be stuck in Boot Rom...

Also, while trying to connect on the fly to the target, it was doing the same kind of error. The OnTargetConnect in the GEL file does a Reset on the DSP. I guess the action of resetting isn't working correctly at all... 

Any help will be appreciated.

Regards,

  • Mosin,

    what you see is proper behavior. After the reset the program control goes to device bootROM, I guess you want the program control automatically back at the application - right?

    While this would happen automatically (based on the boot mode GPIO) in stand-alone mode, but since you have the debugger connected (TRSTn is HIGH) when you run through the boot ROM it follows the EMU-BOOT flow. Refer to the boot ROM chapter of the TRM or the boot ROM users guide for your device. If you want the device to go application running through the boot ROM you will have to initialize EMU BOOT MODE and EMUKEY as needed.

    since this is debug I would initialize them before the pulling the reset and remember to remove it when the debug is done.

    Hope this helps.

     

    Best Regards

    Santosh

     

  • Hi Santosh,

    I just confirmed that if I remove completly my debugger, the reset happens correctly. I'll need to read a bit more about what you're refering to with EMU KEY and EMU BOOT MODE.

    Thanks

  • Hi Santosh,

    I just tested writing 55AA and 0x0003 in the EMU KEY and BMode memory and it made the reset works while connected to JTAG. I've also noticed that these two memory location get rewritten to 0x761B and 0x2942 after the reset. I guess this is normal? So, during debug, if I always want to connect with a debugger and be able to test reset, I'd have to change the key and bmode values at boot up?

    Is there a danger with this?

    Also, if these two values aren't changed and I end up at 0x3FF599, is there a way to make it boot by writing something in a register? I tried entering 0x55AA and 0x0003 while I'm stuck at 0x3FF599 and it did nothing...

    Thanks

  • Mosin,

    those are the 0xD00 and 0xD01 locations that get re-initialized during PIE Initialization done from your main. So you will have to do this before you enable watch dog for reset and probably only do that while doing DEBUG and remember to remove this when running stand-alone. Or check TRSTn status and modify 0xD00 and 0xD01 only if TRST=1.

     

    Best Regards

    Santosh