booting from ROM (FTFA_FOPT[7:6]=11) disables watchdog

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

booting from ROM (FTFA_FOPT[7:6]=11) disables watchdog

2,005 Views
danieltruong
Contributor IV

I have the following puzzling issue and wonder if somebody had similar experiences and willing to share your thoughts:

I implemented a watchdog timer in my program to reset the processor if it ever went astray. One condition for the watchdog to work is you have to manually set the directive DISABLE_WDOG to 0 (i.e. enable the watchdog) in file "system_MKL27Z4.h", otherwise the following piece of code in file "system_MKL27Z4.c" will get executed at start up:

….

#if (DISABLE_WDOG)

  /* SIM->COPC: ?=0,COPCLKSEL=0,COPDBGEN=0,COPSTPEN=0,COPT=0,COPCLKS=0,COPW=0 */

  SIM->COPC = (uint32_t)0x00u;

#endif /* (DISABLE_WDOG) */

....

As a result, the watchdog is disabled by default.

Since register SIM->COPC  can only be written once, it can't be rewritten by user to enable the feature.

Everything was working fine until I decided to make a change to "boot from ROM" in order to enable the firmware upgrade feature from external host. Then the watchdog feature stops working, i.e. SIM->COP register can't be written in my application (it remains as 0 as if it was written by 0 somewhere in the startup program).

The change I made was to modify the Flash Configuration Area in the file “startup_MKL27Z4.S” as follows:

...

/* Flash Configuration */
.section .FlashConfig, "a"
.long 0xFFFFFFFF
.long 0xFFFFFFFF
.long 0xFFFFFFFF
.long 0xFFFFFFFE                //was 0xFFFF3DFE

......

This means that contents of reg FTFA_FOPT was altered to force the processor to boot from ROM, where codes from ROM will conduct a dialog with the host (via USB in my case) to facilitate any firmware upgrade on the field.

If I changed back to original form (FF to 3D) then the watchdog feature came back and the program was running fine.

My platform is:

Processor MKL27Z256xxx

SDK_2.2.1_FRDM-KL27Z

KDS v3.2.0

If anybody knows what I'm talking about or had prior experience about this issue, please share your thought. Your help would be greatly appreciated.

Thanks,

Daniel

14 Replies

1,323 Views
robertpoor
Senior Contributor I

Daniel:

Have you considered loading a flash-resident bootloader and using that instead of the ROM resident bootloader?

I mention this only because I'm going down the path of creating a flash-resident bootloader for the KL27Z, and it seems that might solve your problem.

As it stands, I'm still struggling to get port the flash-resident bootloader to the KL27Z, but making progress.  Maybe with two people working on it, it would go faster... :smileyhappy:

- Robert Poor

0 Kudos

1,323 Views
danieltruong
Contributor IV

Hi Robert,

I'm actually resolved to the approach that allows me to boot from either flash or ROM depending the state of NMI pin at power on. I was finally forced to use a switch on the NMI pin, which I don't like.

So by default (without pressing the NMI switch), the board is booting from Flash. I've heard about "flash-resident bootloader", which probably gives the user some flexibility, but not sure how it can help me in this case. You apparently know a lot more than me in that regard. Can you please elaborate a little bit more? I'm really intrigued by your idea.

Thanks,

Daniel

0 Kudos

1,323 Views
robertpoor
Senior Contributor I

I'm sloooooowwly figuring out the whole flash-resident bootloader. 

The basic idea is that you program your part once with the flash-resident bootloader.  It resides in low memory.  To use it, you have to tweak your application to relocate it just above the flash-resident bootloader in memory, usually starting at 0x8000 or 0xA000.  Happily, those changes are localized to startup_MKL27Zxxx.S and MKL27Zxxx_flash.ld.  You can read a bit of what's involved in Jorge Gonzalez's "How to adapt KDS applications for KBOOT bootloader" and Erich Styger's "Getting Started: ROM Bootloader on the NXP FRDM-KL03Z Board".

Of course, there is no existing flash-resident bootloader for the KL27Z for the simple reason that the KL27Z has a ROM bootloader, so why would anyone need a flash-resident bootloader?  

Well, in your case, you need a flash-resident because you need to work around the COP bug.  In my case, I need it because I have (only) a non-standard serial port (i.e. half-duplex) with which to communicate with the device.

My favored approach is to port the flash-resident bootloader for the KL25Z to the KL27Z, but I'm still working up some small test cases to make sure I'm on the right track.  Let me know if you'll want to see the ported version...

0 Kudos

1,323 Views
kerryzhou
NXP TechSupport
NXP TechSupport

Hello Daniel,

  When you boot from the ROM, how did you check the watchdog is already be disabled? Debug or any other way?

  Please tell me more details, I will check it on my side, thank you!


Have a great day,
Kerry

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

0 Kudos

1,323 Views
danieltruong
Contributor IV

Kerry,

I have a debug message that displays the content of register SIM->COPC right after the COP is initialized. The register is supposed to have a value of 0x26 (note bits [3:2]=COPT=01). However, with the boot from ROM option, that register has the value of 0x00 (COPT=00=disabled).

Daniel

0 Kudos

1,323 Views
kerryzhou
NXP TechSupport
NXP TechSupport

Hello Daniel Truong,

     These chip: KL03, KL13Z128/256, KL43, KL27Z128/256 will disable the watchdog after boot from ROM.

    Actually, our errata already add the according description:

http://www.nxp.com/docs/en/errata/KINETIS_L_1N71K.pdf 

pastedImage_3.png

Wish it helps you!

Have a great day,
Kerry

 

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

1,323 Views
danieltruong
Contributor IV

Kerry,

Thanks for the errata information. It is indeed the root cause of the problem. The mask set number of the chip is exactly 1N71K. 

For the workaround solution, it is recommended to use the option to boot from Flash instead of ROM. I changed back the FTFA_FOPT register to 0x3D to make it boot from Flash. And the COP can be enabled and used throughout my program.

However, if I do this, I have to give up the capability to upgrade firmware thru the ROM bootloader. Not sure how to achieve this with a "flashloader".

0 Kudos

1,323 Views
kerryzhou
NXP TechSupport
NXP TechSupport

Hi Daniel ,

   Please don't worry about the BOOTSRC_SEL =00.

  You won't give up the capability to upgrade firmware thru the ROM bootloader. Just configure FOPT[NMI_DIS]=1 and FOPT[BOOTPIN_OPT]=0.

 You can find the detail description from the reference manual:

pastedImage_1.png

When you want to use the ROM bootloader, just press the NMI pin, hold on it, press the reset pin, release reset pin and then release NMI pin, the MCU will enter the ROM bootloader.


Have a great day,
Kerry

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

0 Kudos

1,323 Views
danieltruong
Contributor IV

Kerry,

That's a great idea. However, in my application, due to physical constraints of the board, I could only implement 1 multi-purpose switch (on, off, event trigger). Because of this, the switch can't be in the reset or NMI pin position as usual.

In the case you mentioned, I may need not 1 but 2 switches in the reset and NMI positions. I can't afford to have that mechanism.

Thanks,

Daniel

0 Kudos

1,323 Views
kerryzhou
NXP TechSupport
NXP TechSupport

Hi Daniel,

   If you don't want to add 2 switches, I think you also can leave two test point in these two pin, then you also can use external wire to realize it.

   But if your hardware already finished, and don't want to modify it, that's really a headache.

   Then, you just need to use the external debugger to do the mass erase again.


Have a great day,
Kerry

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

0 Kudos

1,323 Views
danieltruong
Contributor IV

Kerry,

The external wires don't work in a production board. This firmware update mechanism is intended to support FW upgrade on the field when the product has been launched.

Based on the recommended workaround in the errata above, the MCU must be booted from flash to have COP enabled. I wonder how I can implement the FW updading via a Flash bootloader. If you know how to do this, please let me know.

Thanks,

Daniel

0 Kudos

1,323 Views
kerryzhou
NXP TechSupport
NXP TechSupport

Question: how I can implement the FW updading via a Flash bootloader.

Answer:

  1. Erase all the flash at first, or erase the FOPT to boot from ROM, then reset, the code will boot from ROM again.

  2. In the application code, give some external condition, then call the ROM.

pastedImage_1.png


Have a great day,
Kerry

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

0 Kudos

1,323 Views
danieltruong
Contributor IV

Hi Kerry,

when I jump back to Boot ROM from the Flash, it won't work the same as booting straight from ROM, ie. It doesn't talk to the host SW to set up the firmware upgrade.

Since I don't have access to the code in ROM, I have no idea what happened.

I'm back to square one. Either Boot from ROM and be able to have firmware upgrade from host, but must give up WDog. Or boot from flash and have WDog, but must give up FW upgrade capability. Or must implement a switch at NMI pin to force FW upgrade mode when the switch is pressed at power on.

Daniel

0 Kudos

1,323 Views
kerryzhou
NXP TechSupport
NXP TechSupport

Hi Daniel,

  Give me your test project, I will try it on my side.

  Or you can tell me the detail modifications in the ksdk, especially about the debug message which displays the problem.

Have a great day,
Kerry

 

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

0 Kudos