Watchdog and ROM bootloader

[nickdolling]

In my application, I configure the watchdog at startup.

According to the reference manual, the COPC register I am writing to as part of the initialisation is write once.. so it shouldn't be possible to modify it after this.

If I jump to the ROM bootloader, then when I restart my application using the "execute" command in blhost, I find the watchdog is now disabled (I assume by the bootloader).

How is it that the bootloader can disable the watchdog if I've already written the COPC register? 

Furthermore, how do I re-enable it after returning from the bootloader?

[nickdolling]

@jay_heng any update?

[bobpaddock]

Take a look at the bits in  Reset Control Module (RCM), particularly the Sticky bits, RCM_FM and RCM_MR.  This will tell how things got where they are as well as let the bootloader to be bypassed.
The bootloader does turn the watchdog off.


Somewhere in the morass should be the bootloader source code:

https://www.nxp.com/mcuboot

[nickdolling]

Hi Bob,

Thanks for the suggestions.

I'd long forgotten the RCM but taking a look again, it shows me that the source of the reset when coming back from the bootloader is a software reset, but I'm not sure if that helps.

If I could use this to check at startup and force another reset it might help, but I can't think how to do this other than a watchdog timeout (which is what's not working!).

I still don't understand how the bootloader can disable the watchdog when I've already done the one write to the COPC before entering the bootloader. I feel that i I knew that I should be able to use the same magic to turn it back on!

Nick

PS : I have previously downloaded the source for bootloaders 1.0.0, 1.1.0, and 2.0.0.. but I'm not sure which one to look at.. the K32L2B bootloader reports as 1.0.0 but there is nothing in the source for that target.. from memory it has the same die number as the KL17/KL27 so maybe I should be looking at those as a reference.

[bobpaddock · Accepted solution]

I don't believe the KL27 and K32L are the same die due to the differences in memory layouts.
They are similar.

It would be worth looking on NXP's GitHub account to see if there is anything newer than what is posted on the mcuboot web page.

The KL27 has a bug in its bootloader that I address with the code below, it might give you some ideas.
This is the first code executed at RESET.

static void vectors_bootloader_mr_setup( void ) __attribute__( ( used, __aligned__( 4U ), section( ".after_vectors" ) ) );
static void vectors_bootloader_mr_setup( void )
{
/*
* RCM_MR Indicates the boot source, the boot source remains set
* until the next System Reset or software can write logic one to
* clear the corresponding mode bit. While either bit is set the
* NMI input is disabled and the vector table is relocated to the
* ROM base address at 0x1C00_0000. These bits should be cleared by
* writing logic one before executing any code from either Flash or
* SRAM.
*
* A reset is forced to clear out anything that the ROM
* bootloader did, so we are sure we have the data sheet reset
* values.

* This method works around the buggy KL43/27/17 bootloaders as
* described in: "Problem Analysis and solutions for booting from
* ROM BOOTLOADER in KL series".
*/
if( 0U != ( RCM_MR & RCM_MR_BOOTROM_MASK ) )
{
RCM_MR = RCM_MR_BOOTROM_MASK; /* Clear the bits that indicated a bootloader boot via ROM */
RCM_FM = 0U; /* Boot from Flash not ROM on next reset */

SCB_AIRCR = ( SCB_AIRCR_VECTKEY( 0x05FAU ) | SCB_AIRCR_SYSRESETREQ_MASK ); /* Force a Software Reset */
}
}

[nickdolling]

Hi Bob,

Thanks for this.

> I don't believe the KL27 and K32L are the same die due to the differences in memory layouts

I was just wondering based on the fact that the mask number in the errata is the same for both. Oout of curiosity I had a skim through but I couldn't see a difference in the memory layouts. No big deal.

I couldn't see any bootloader related stuff in the nxp github account.

Anyway.. looking more into the state of the bits in the RCM, after various ways for starting up/getting into/out of the bootloader, I'm assuming the bootloader must do a software reset itself to allow it to disable the watchdog.

So, I ended up using a similar logic as you (but rather looking at whether the watchdog was successfully enabled) and doing a software reset myself... seems to have done the trick.

Thanks also for the reference to the bootloader bug, turns out that I had inadvertently found and solved the same thing myself (after much head scratching).

Thanks again for your help.

Nick

[bobpaddock]

You are welcome.

>  I couldn't see a difference in the memory layouts.

The K32L has a dedicated memory area for USB while the KL27 does not.

The K32L also has BME2 while the KL27 is BME.

> wondering based on the fact that the mask number in the errata is the same for both

Would not be the first time I've seen a copy & paste error in the documentation.
NXP really needs a prof reader.

[nickdolling]

Ooops.. yes that would have helped wouldn't it. In this case it's the K32L2B31. ROM bootloader reports as version K1.0.0.

I'm using the SDK COP_Init() and only changing the setting for the short timeout. As far as I know there is only one COPC register?

I can see after a normal POR that the COPT bits are left at 11 as expected. After re-entering from the bootloader they are set to 00 before the call to COP_Init(), and they are still set to 00 after the call to COP_Init(), so the write once seems to be working there.

Thanks.

[jay_heng]

Which Kinetis part you are using? and also which COPC regitser? i can check on my side.