Kinetis K20 won't do software reset

[charles0000]

I have tried three methods of resetting this MK20DX256VLK7 chip, and none of them seem to produce the same effect as power cycling it.

Method 1: Set the System Reset Request bit of the Application Interrupt and Reset Control Register (VECTKEY is required according to the ARM documentation)

SCB_AIRCR = SCB_AIRCR_VECTKEY(0x05fa) | SCB_AIRCR_SYSRESETREQ_MASK;

Method 2: Writing an incorrect value to the Watchdog Unlock register should cause the watchdog module to reset the system

WDOG_UNLOCK = 0xffff;

Method 3: Unlocking the Watchdog module and failing to update anything should also cause the watchdog module to reset the system

WDOG_UNLOCK = 0xc520;

WDOG_UNLOCK = 0xd928;

I am trying to switch between an application and a firmware update bootloader. Calling the entry point for the application directly ends up in the application's main loop, but none of the peripherals seem to work correctly, and this problem only happens when going from the application to the bootloader and back to the application, so it should work if I can simulate power cycling the chip rather than calling the application directly. What am I missing here?

I am using CodeWarrior 10.4 with ProcessorExpert for most of the peripheral components (specifically, CAN_LDD, GPIO_LDD, and TimerUnit_LDD).

I know there are hardware solutions for this, but for the moment I'm stuck with the board and components as they are.

[charles0000 · Accepted solution]

For anyone having a similar problem, I have traced the initial problem (the chip appearing to freeze after a software reset) to an EEE memory read that was happening before main() and was never completing. I have implemented a workaround that checks RCM_SRS0 and RCM_SRS1 to determine the reset source, and if it is software or watchdog, waits until after PE_low_level_init() to read EEE memory (even though the read works on POR and FTFL_FCNFG.EEERDY is set in both cases...). The issue of not having interrupts was resolved by using the software reset rather than calling the bootloader directly from the application.

[Carlos_Musich]

Hi Charles,

What is exactly the problem you are facing after reset? Does the application reaches entry point? Does the application reaches main? How are the peripherals behaving and which is the expected behavior? Is there a simple way to reproduce it?

Regards,

carlos

[charles0000]

When debugging, every time the watchdog is triggered, execution stops at address 0xFFFFFFFF. When I tested going from application to bootloader to application earlier (by calling each entry point directly), it appeared to reach my main loop, but either the timer or GPIO module was not working because there was no output (the timer event toggles the GPIO outputs), and the CAN module was also not working (it has a ping functionality that works over CAN). I am using ProcessorExpert's *_Init functions for each of these components, and the bootloader isn't doing anything more with the hardware than the application does except for writing to the program flash area. Also, sometimes after the watchdog is triggered, CodeWarrior tells me the device has been secured and needs to be erased.

[charles0000]

I have been able to determine that the problem with calling the application directly from the bootloader more than once is that none of the interrupts are firing (or at least it's not making it to the event handlers in Events.c). This is the case with at least two separate modules, one of which the bootloader uses and the other it does not. What could be disabling the interrupts? I was using the WFI assembly instruction in my main loop to save power when idle, but I tried removing it and it did not change the behavior.

[mjbcswitzerland]

Charles

The majority of peripherals are reset by a system reset (any of the methods) and so code will be able to run again afterwards starting at the standard reset states.

Some peripherals have some registers that hold values across resets, but not many, so these exceptions will need to be manually reset in some cases on re-initialisation.

The uTasker serial boot loaders [Kinetis Boot Loader for SREC UART, SD Card and USB-MSD loading] allow moving between application, boot loader and application (using the system reset to get from application to boot loader). Depending on what the boot loader performs it is necessary to disable some used perfipherals and clear core interrupts to ensure that they can't disturb the application when it is jumped to, but only when these peripherals have actually been configured in the boot loader phase - if the boot loader phases doesn't "touch them" they haven't been needed.

Regards

Mark

[charles0000]

The puzzling thing is that going from power-on to bootloader to application works fine, but then going back to the bootloader and back to the application fails (which is how all firmware updates after initial programming have to happen). I was under the impression that the ProcessorExpert code sets any registers it needs to known values, and I have tried calling the Deinit methods before resetting (both in the bootloader and in the application), but that does not improve the situation.

[bobpaddock]

There are a few registers, like the Watchdog that can only be written once after reset.

Perhaps running into one of those?

[charles0000]

I can only find references to write-once registers in the sleep, LVD, and watchdog modules, are there any that could keep the timer or CAN modules from working? I have also tried adding an actual watchdog component, which is updated in the timer event handler, but when the watchdog timer gets triggered, the chip just freezes rather than resets.

[anthony_huereca]

Not sure if it'll help, but while the LPTimer is *not* write-once, it is only actually reset on a POR. So a software reset wouldn't affect it.  Perhaps there's an LPTMR ISR trying to fire?

[bobpaddock]

"the chip just freezes rather than resets"

It may have end up in the hardware fault handler.
Install a handler that that can blink and LED, display a message, or output the stack and PC pointer on the terminal.

Knowing the PC would be the most helpful, it will point *after* the errant routine.

Not sure how helpful it is in the case of the watchdog, other than to tell you where the watchdog kicked.

It will be helpful if the code is stuck in an unexpected loop.

http://mcuoneclipse.com/?s=hard+fault

[charles0000]

My code turns on two LEDs when it gets reset, and I have just changed it to turn on one LED for unhandled interrupts (which includes hard fault). When the watchdog timer is triggered, no LEDs come on. When I debug it, execution stops at address 0xFFFFFFFF after the watchdog timer is triggered, but I'm not sure if the debugger is interfering with the reset process here. The debugger shows nothing but 0xFFFFFFFF for the first 0x0800 bytes of memory, even though there is actually a bootloader there and the bootloader executes and passes control to the application correctly when the debugger is not running. When I try to reset the chip while debugging, it ends up in the fault handler, but when I'm not debugging, it works (until I try to switch back to the application).