K64 bootloader doesn't run after reset

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

K64 bootloader doesn't run after reset

Jump to solution
1,017 Views
dimi55
Contributor I

I have been reviving an older bootloader project written in CodeWarrior (later ported to KDS) and now have trouble flashing the binary "permanently". The program is debugging fine, everything works as expected. First run (after reset) from flash runs fine, but upon resetting the MCU or switching the power on/off it doesn't run. There is nothing suspicious in linker script and startup files that I could find. Debugging step by step from entry point also doesn't look suspicious as it goes through all the inits and runs the main just fine.

In system_MK64F12.c only the watchdog gets disabled and everything else is skipped.

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 */
/* 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) */

 

Am I missing something in the procedure (in flashing the bootloader) or linker/startup files are setup wrong?

 

Labels (1)
Tags (2)
0 Kudos
1 Solution
942 Views
dimi55
Contributor I

Hi Diego,

Your comment lead me to an answer. The problem was the NMI pin that held the MCU in reset state. Disabling it and EzPort helped. The problem was nothing I suspected but your comment helped me figure it out. It was really an eyeopener.

Thanks Diego!

View solution in original post

0 Kudos
3 Replies
983 Views
diego_charles
NXP TechSupport
NXP TechSupport

Hi  @dimi55 

I hope you are doing well!

I am not aware  how your bootloader intends to write an image. For example, flash resident bootloaders use to take place the application image after 0xA000. It may be posible that both bootlader image and application image have an overlap and thats may be generating troubles.

Another thing that I am thinking is that you could check is whether your application can not boot due to an incorrect clock setting in the aplication itsef.

I am not aware if already cheked the Kinetis Bootloader:

For using KDS we do have Kinetis bootloader (flash resident and flash loader) implementations   This is the link for downloading the  Kinetis bootloader 2.0.0

You can look at this implementation in this path NXP_Kinetis_Bootloader_2_0_0\targets\MK64F12\kds\

The  Kinetis Bootloader v2.0.0 Reference Manual also provides information regarding the Kinetis bootloader settings and operation . Also  you will also find hints regarding   bootloader  clocking and  memory map under Chapter 10 Kinetis bootloader porting.

On a side note:

 Kinetis devices are now also supported by the MCUXpresso SDK and MCUXpresso IDE .Actually,  the Kinetis bootloader, has been re-branded to MCU boot. The MCU bootloader provides  the same bootloader implementations that I mentioned before, and they are included in the MCUXpresso SDK.

I hope this could  help.

My apologies for the delay

Diego.

 

 

 

 

 

 

 

 

943 Views
dimi55
Contributor I

Hi Diego,

Your comment lead me to an answer. The problem was the NMI pin that held the MCU in reset state. Disabling it and EzPort helped. The problem was nothing I suspected but your comment helped me figure it out. It was really an eyeopener.

Thanks Diego!

0 Kudos
937 Views
diego_charles
NXP TechSupport
NXP TechSupport

Hi @dimi55 

I am glad to know  that you were able to find out the cause of the issue!  

yours, 

Diego

0 Kudos