K64 bootloader

[ad52655]

I'm using UVision 5 with a Kinetis K64.  I am working on porting the Codewarrior USB host bootloader to the Keil environment.  I have successfully done this for K60 and am nearing completion for the K64. 

Using the bootloader, I am successfully recognizing the device attached, erasing the application sector space, and loading the new application.  But upon power up, when the bootloader successfully detects an image is present in flash, it's jumping to the program counter address stored in the 5th-8th byte of the binary, but then the application resets the processor which then enters bootloader mode and continues this in an indefinite reset.

My method for jumping to the application which is working with the K60 is:

((void (*)(void))New_pc)();

where New_pc is the address of the reset vector.

When I load the Codewarrior without touching the application, it successfully jumps to the application and runs.  The Codewarrior bootloader uses:

      asm

      {

         ldr   r4,=New_sp

         ldr   sp, [r4]

         ldr   r4,=New_pc

         ldr   r5, [r4]

         blx   r5

      }

but as you can see from above, the Keil bootloader does not set up the stack pointer.  But it works for K60 and I've read that the application sets up the stack pointer.

Do I need to set up the stack pointer?  If so, why didn't I have to with the Keil K60 bootloader, which works?  If not, is the continuous resetting a hint as to what is going on?

[mjbcswitzerland]

Hi Aaron

I have always used the following for all K parts (including both K60 and K64).

extern void start_application(unsigned long app_link_location);

start_application

	ldr sp, [r0,#0]	; load the stack pointer value from the program's reset vector
	ldr pc, [r0,#4]	; load the program counter value from the program's reset vector to cause operation to continue from there

To jump to an application linked to the address 0x4000, the call is

start_application(0x4000);

This is compatible with Keil, IAR, KDS, CW etc.

I don't "see" the problem in yours but you may like to try the other method if you don't find it.

Regards

Mark

Kinetis: µTasker Kinetis support

K60: µTasker Kinetis TWR-K60N512 support  / µTasker Kinetis TWR-K60D100M support  / µTasker Kinetis TWR-K60F120M support

K64: µTasker Kinetis FRDM-K64F support  / µTasker Kinetis TWR-K64F120M support  / µTasker Kinetis TWR-K65F180M support

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

[ad52655]

Hi Mark,

I was very suspicious of that and looked over the UTasker code and have already pulled that in this afternoon and got the same results.  The most recent thing I did was implemented a unique program at flash space 0x10000.  Then I loaded another basic program at 0x0 and directly after the initialization jumped to my program at 0x10000 using my original method.  It worked flawlessly.  This basically proved to me that there is some sort of interrupt or clocking issue that is pending from the bootloader that is causing the reset.  I seen your note earlier regarding shutting down the peripherals.  My previous attempt at shutting down the peripherals was probably not thorough enough.  Thanks you for your feedback.  I'll let you know how it goes.

Aaron

[Jorge_Gonzalez]

Hello Aaron Dunkin:

How is your project going? Any new findings?

Another possible cause would be the watchdog, if it is not disabled then the MCU would reset.

If the application and bootloader are not developed in CW, you could at least load the bootloader + application and start a "Connect" session with CodeWarrior to inspect the RCM_SRSx registers to find the cause of the reset. See the tutorial from colleague Erich Styger:

:smileyinfo: Debug configurations interface has changed a little, but the process is the same.

Hot-Sync: Attach, Connect & Download | MCU on Eclipse

Let us know your progress.

Regards!

Jorge Gonzalez

[ad52655]

Thanks Jorge, I've double-checked that the watchdog is disabled, but I'll take another look.  I'll also check out that tutorial.