Reset_Handler when unlocking Watchdog at SystemInit()

[tharonhall]

I have configured my Processor Expert so I can target the 64-pin K22F device on the FRDM-K22F board, or the 100-pin "MK22FN512VLL12" MCU on our target board. I can talk to our board from KDS using Multi-Link just fine, but things fail immediately on startup.

The code attempts to unlock the watchdog at startup, but then immediately jumps to the Reset_Handler. This code presumably worked when executed on the FRDM-K22F board.

Here is the code, which was generated by PE:

/* ----------------------------------------------------------------------------

   -- SystemInit()

   ---------------------------------------------------------------------------- */

void SystemInit (void) {

#if ((__FPU_PRESENT == 1) && (__FPU_USED == 1))

  SCB->CPACR |= ((3UL << 10*2) | (3UL << 11*2));    /* set CP10, CP11 Full Access */

#endif /* ((__FPU_PRESENT == 1) && (__FPU_USED == 1)) */

#if (DISABLE_WDOG)

  /* WDOG->UNLOCK: WDOGUNLOCK=0xC520 */

  WDOG->UNLOCK = WDOG_UNLOCK_WDOGUNLOCK(0xC520); /* Key 1 */ <--- HERE IS WHAT EXECUTES AND EXECUTION GOES TO THE RESET HANDLER

  /* WDOG->UNLOCK: WDOGUNLOCK=0xD928 */

  WDOG->UNLOCK = WDOG_UNLOCK_WDOGUNLOCK(0xD928); /* Key 2 */

  /* WDOG->STCTRLH: ?=0,DISTESTWDOG=0,BYTESEL=0,TESTSEL=0,TESTWDOG=0,?=0,?=1,WAITEN=1,STOPEN=1,DBGEN=0,ALLOWUPDATE=1,WINEN=0,IRQRSTEN=0,CLKSRC=1,WDOGEN=0 */

  WDOG->STCTRLH = WDOG_STCTRLH_BYTESEL(0x00) |

                 WDOG_STCTRLH_WAITEN_MASK |

                 WDOG_STCTRLH_STOPEN_MASK |

                 WDOG_STCTRLH_ALLOWUPDATE_MASK |

                 WDOG_STCTRLH_CLKSRC_MASK |

                 0x0100U;

#endif /* (DISABLE_WDOG) */

Any thoughts on even where to start looking? Is it possible there is a bug in the PE code???

[Jorge_Gonzalez]

Hello Tharon:

From your description it seems like you are trying to step-debug through those lines?

That should of course cause a reset. You cannot step through those lines, because both accesses to the WDOG_UNLOCK register have to be made in a 20 bus clocks window:

Regards!,
Jorge Gonzalez

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[tharonhall]

Thank you for the feedback.

So the debugger does NOT suspend the watchdog during single stepping. Interesting...

I stepped to just before the instruction and placed a breakpoint on the other side of the two unlock commands so they would still be executed back to back, and it still went straight to Reset_Handler and didn't make it to the breakpoint on the far side. :smileysilly:

[tharonhall]

OK, guys. I was working late last night and the designer wasn't here. When I came back this morning he said that the Vbatt was not hooked up (we are not worried about the RTC ATM, so no big deal to not have a battery), but that included the mandatory switching diode network between battery voltage and Vcc, so sure enough, so the Vbatt section of the MCU wasn't powered even by Vcc. I wouldn't have thought that would directly effect the WDOG timer, but who knows how the power domains are routed.

So he installed the diode network and voila, the board come alive running the code that I had previously installed. So yes, it was hardware. (Derek is right, of course, as he so often is. :smileywink:)

So note, not powering a portion of the device can break in odd ways. Hope our trials help someone else avoid our pitfall.

Thanks for all the help! Painful exercise, but it was educational. :smileyhappy: I could use a little less education these days. :smileywink:

[guitardenver]

This may be to late, but you can fix this issue in software, without changing your hardware. In system_MK22F51212.c file, if you have "SYSTEM_RTC_CR_VALUE" defined, it will try to write to the RTC registers. If the RTC modual is not powered, writing to RTC registers will cause a bus error. Which will make the MCU go to the reset_handler like you are experiencing.

To fix the issue, in system_MK22F51212.h header file, comment out the definition "#define SYSTEM_RTC_CR_VALUE " and the code will no longer try to write to the RTC module.

Hope this helps someone.

[dereksnell · Accepted solution]

Hi Tharon,

You say “This code presumably worked when executed on the FRDM-K22F board”. Does that mean you’ve tested this same project on the FRDM-K22F board, and the code successfully gets through the watchdog disable code? If not, it would be helpful for you to confirm that. Then we will better understand if the issue is specific to the project, or related to hardware.

Since this project is having issues so early in the startup code, you can likely test it on other hardware like FRDM-K22F. But if there is code executing before this dependent on your hardware, you can try modifying the code so it starts up on both boards to compare. Different package settings are not important for this startup code, so you should be able to run the same firmware image on the two boards.

You can also check the reset source in the RCM_SRS registers. It would be good to verify what source is triggering the reset so we can narrow down the root cause.

Let us know what you find. Thanks

[tharonhall]

To Derek's point, and much to my surprise, Multi-Link and my P&E OpenOCD debugger in my FRDM board apparently don't care if I am trying to download code built for either 100 pin or 64 pin devices and the actual hardware is the other. I was able to confirm that code built for either 64-pin or 100-pin does run on the FRDM board but neither runs on our target board. :smileysad:

Looks like we need to look at hardware. :smileysilly:

[mjbcswitzerland]

Tharon

There are no functional differences between the K22F on the FRDM board with 64 pins and the version with 100pins (apart from the extra pins that can be used).

The same would not be true for devices with different Flash sizes because they do have quite large differences which can cause code to run on one but not on the other.

Regards

Mark

Kinetis: µTasker Kinetis support

K22F: µTasker Kinetis FRDM-K22F support / µTasker Kinetis TWR-K22F120M support

For the complete "out-of-the-box" Kinetis experience and faster time to market

[mjbcswitzerland]

Tharon

Are you trying to step the watchdog disabling code with the debugger?

If so, you will always get a reset after the first access because the watchdog expects the second access within a limited number of bus cycles, which the debugger will never achieve.

Set a breakpoint 'after' the watchdog code and let the debugger "run over" it. Then you can continue stepping from there to see whether there are any other issues.

Regards

Mark

Kinetis: µTasker Kinetis support

K22F: µTasker Kinetis FRDM-K22F support / µTasker Kinetis TWR-K22F120M support

For the complete "out-of-the-box" Kinetis experience and faster time to market

[tharonhall]

Derek,

   Oh, yes, the code has been running for some time on my FRDM-K22F board. Today is the first time I have tried recompiling it for the 100-pin part on our target board and run it on our target board.

   As far as looking at the RCM_SRS register, I can look at the general registers, but I can't look at K22F specific registers. I installed Erich's plug-in to look at MCU specific registers, but much to my dismay, Freescale is not in the list of support MCUs. :smileysad:

   Obviously the issue could be with our board. I am currently investigating the watchdog clock input source. I haven't been able to find anything in PEx, so far at least, that configures the input, since it appears an external source might be an option.

[tharonhall]

OK, so the system comes up with the Low-Voltage Detect Reset and the Power-On Reset sticky bits set, which might make sense from a reset. When it hits the first WDOG unlock instruction and goes back to the Reset_Handler, no additional sticky bits are set, including the "Watchdog" sticky bit.

[dereksnell]

Hi Tharon,

Regarding the debugger registers, If you follow the steps at this link for the EmbSysReg plugin, you should find Freescale listed in supported MCUs. Be sure to get the latest zip archive from the sourceforge page, and unzip it into your Eclipse installation directory. That will add support for the Kinetis derivatives to the plugin.

http://mcuoneclipse.com/2014/09/27/updated-eclipse-embsysreg-viewer-with-extra-freescale-svd-files/

Also, having a register view makes things easier, but if needed you can use the Memory View in the Eclipse debugger, and look at the address of registers.

Thanks

[tharonhall]

OK, so for anyone following this discussion, I previously did the initial install using the http approach that Derek references above in the link to MCU On Eclipse, which did not work. I went back and did it again by manually downloading and copying the files over the previous install and lots of stuff was missing from the http install.

Note that to get to the Freescale MCUs you MUST select "SVD(CMSIS)" for architecture and not Cortex-Mx

I hope this helps somebody somewhere! :smileyhappy:

[tharonhall]

PS - I commented out the WDOG code just to see if code execution would continue without it in the event the cause was something else and it was coincidence it resets at that line. Execution did continue just fine without executing that line.