watchdog reset

[100asong]

Hi,Dear sir

     I want to reset the MCU mc9s12xep100 by watchdog way.    

     My reset vector address is 0xC000 with the name _Startup() function.

     _Startup()

     {

           .....

           main();

     }

     main()

     {

         /* PLLCTL: PCE=0 */
         clrReg8Bits(PLLCTL, 2);              
         /* COPCTL: WCOP=0,RSBCK=0,CR2=1,CR1=1,CR0=1 */
        clrSetReg8Bits(COPCTL, 192, 7);      
         /* CRGINT: LOCKIE=0,SCMIE=0 */
        clrReg8Bits(CRGINT, 18);             
         /* VREGCTRL: LVIE=0 */
         clrReg8Bits(VREGCTRL, 2);

         /* ECLKCTL: NECLK=0,NCLKX2=1,DIV16=0,EDIV4=0,EDIV3=0,EDIV2=0,EDIV1=0,EDIV0=0 */
         setReg8(ECLKCTL, 64);                
         /*  System clock initialization */
         /* CLKSEL: PLLSEL=0,PSTP=0,XCLKS=0,??=0,PLLWAI=0,??=0,RTIWAI=0,COPWAI=0 */
        setReg8(CLKSEL, 0);                  /* Select clock source from XTAL and set bits in CLKSEL reg. */
        /* PLLCTL: CME=1,PLLON=0,FM1=0,FM0=0,FSTWKP=0,PRE=0,PCE=0,SCME=1 */
        setReg8(PLLCTL, 129);                /* Disable the PLL */
        /* VREGHTCL: ??=0,??=0,VSEL=0,VAE=1,HTEN=0,HTDS=0,HTIE=0,HTIF=0 */
        setReg8(VREGHTCL, 16);               
  

        while(1);//dead loop for reset.

     }

     I use BDM to run this code.I beat Start button in Ture-Time ... Debugger,and then set the breakpointer at 0xC000.But I found MCU can't reset since that it never stop at 0xc000.And after about some second,PC run at 0x524d address with command window hinting "ILLEGAL_BP" information.

     I try to run it in normal mode,and find it should reset normally.

     I have 2 qestion:1.Why the cpu can't reset in BDM mode?

                            2.Why it stop at 0x524D?

[kef]

1) COP watchdog reset uses different reset vector. If you didn't initialize COP vector, then maybe that's why CPU goes to weird address. In special mode illegal address access reset is disabled. In normal mode COP could fire, CPU could fetch wrong starting address from not initialized vector and some cycles later could reach code accessing iilegal address and reset as if it was COP reset. Check the state of ILAF bit.

2) Setting breakpoint at start of code doesn't make sense, since reset resets also breakpoints hardware. For debugging purposes you may loop at start of program. Using MODE bits you may make entry to this loop conditional, depending on operating mode.

[100asong]

Hi,Dear kef

       Thanks for your help.

        1.I had set COP reset vector address at 0xC000. I find ILAF not been set a moment ago.

        2.If I loop at start of startup,the code will stop here when it run at the first time,and the following code could not been executed.

        I think whether BDM linking with reset pin causes this issue,since that BDM pull reset at high power(5V) always and MCU low it to ground when reset occurs.And at this moment,illegal address occurs.This is my individual think,perhaps is wrong.

        Waiting for your reply.Thanks.

[kef]

•         2.If I loop at start of startup,the code will stop here when it run at the first time,and the following code could not been executed.

In debugger you can set program counter below that loop. Loop is only to catch CPU in the location that is executed after reset. Of course compiler may optimize out everything that is below dead loop. But you may make that loop executing until some volatile variable or register is not initialized, for example while(!VREGHTCL){} should be fine. To exit loop - write to VREGHTCL or set program counter below the loop.

[100asong]

Dear Kef&Lundin,

      Thanks,sir. 

      I add a loop at startup beginning part.It looks okay that I can reset the code through watchdog and it stop at loop lacation.

      But I still have question about you mentioned "Setting breakpoint at start of code doesn't make sense, since reset resets also breakpoints hardware",could you please give some explain about it? Thanks.

[kef · Accepted solution]

Debugger uses on chip debug hardware. You may read about that in chapter 8, S12X Debug. To set some breakpoints, debugger writes some settings to Debug module registers. When reset happens, Debug module is reset like any other on chip module. Of course breakpoints settings also are lost. To continue debugging with breakpoints enabled, debugger must reinitialize Debug module settings (reenable breakpoints). That's why I said it doesn't make sense to set breakpoints at start address of your code, you won't be able to catch COP reset with breakpoints.

[kef]

Tom,

CPU12(X) is able to choose proper reset vector only if there is no capacitor at RESET pin, or at least RC of capacitor and pull resistor connected to RESET pin must be short enough to allow rising from "0" level to "1" level in 64 SYSCLK cycles. See 11.5.1 Description of reset operation, table 11-17 and surrounding information in S12XE datasheet. When internal reset happens, CPU pulls RESET pin low for >128 SYSCLK cycles, then releases and after additional 64 cycles samples RESET pin state. If RESET pin is still low, then normal reset vector is taken as if it was external reset.

Are you using internal low voltage reset, no external LVD circuit is sitting on RESET pin, right?

[Lundin]

If you press "run" in the debugger and the CPU gets a reset from wdog or elsewhere, the debugger will lose the connection with the CPU, and you will have to reset the debugger as well to get it back on track.

The BDM pulls reset low during program downloads or when you click "reset" from the debugger. Otherwise this pin is pulled high by the pull-up resistor you have designed in at that pin.

Also, did you try to run your program without wdog enabled?

[100asong]

Why it is normal in simulator mode?