Bootloader for Kinetis K64 (Cortex M4)

[andersbergström]

Hi

I´m currently working on a bootloader for Kinetis K64. The reason that we don´t use the Kinetis bootloader is beacuse we nedded to have a custom protocol.

I never done this before so i tought i will make the bootloader in the 4 following steps:

1) Make a simple Hello-World program resident in memory at adress: 0x00C28CB0

2) Debug and start the Hello-World program to make sure it is located at the correct memory adress

3) Make a simple "Hello-World application", to be able to jump between to the Hello-World program.

4) Get the new application and write it into flash.

Im stuck at 2) and 3) since the program always starts up at adress 0x0, not where i put my second vector table for the "Hello World program" It also ends up in Reset_Handler at 0x0 when i try to jump between bootloader and application.

I use different linking files for bootloader and application but the same startup code are used ( See attached files)

When i try to jump from the bootloader to the application i use the following code:

    // Test to go to application     static void (*JumpToApp)(void) = 0;     JumpToApp = (void (*)(void))APP_ADRESS;      // Set the VTOR to the application vector table address.     SCB->VTOR = (uint32_t)APP_VECTOR_TABLE;       // Set stack pointers to the application stack pointer.     __set_MSP(APP_STACK_PTR_DEF);     __set_PSP(APP_STACK_PTR_DEF);       // Jump to the application.     JumpToApp();      

I use the following defines:

#define      APP_ADRESS     0x00C28CB0 #define      APP_VECTOR_TABLE APP_ADRESS #define      APP_STACK_PTR_DEF APP_ADRESS

Im grateful for help,

/ Anders

Original Attachment has been moved to: K64FN1Mxxx12_flash.ld.zip

Original Attachment has been moved to: K64FN1Mxxx12_flash_bootloader.ld.zip

Original Attachment has been moved to: startup_MK64F12.S.txt.zip

[andersbergström]

Thanks for the Reply Mark. It works better to merge the files with uTasker Utillities.

I will look into uTasker serial loader, and might use it in the future

[mjbcswitzerland]

Norm

It depends on how the jump is performed. If it is performed using the code that I posted above

start_application(APP_ADRESS);

is correct where APP_ADRESS is the address where the application is physically linked to.

Here is an example of a typical application linked to either 0x00000000 (when workling without a boot loader) or another other address: the first two values at 0x00000000 (or any other address APP_ADRESS) are

0x2002fffc 0x00016e55

when viewed as long words.

0x2002fffc is the initial stack pointer value (often the top of SRAM)

0x00016e55 is the start address of the application (could be anywhere depending on where the linker puts the startup code - entry point) but it is indeed an odd address.

The code loads the first long word to the SP (exacly as a HW reset does) and sets the second to the PC (exactly as a HW reset does). Where the entry point is (and that it is odd for the Cortex M4) has nothing to do with the linking address and is managed by the compiler/linker.

Regards

Mark

[ikalogic]

Hi there,

Okay, i have a simple problem -although hard to explain. I'll do my best.

May application start address is 0xA0000. My bootloader get the new firmware and places it in the right place. so far so good.

If i look at the memory of my Kinetis (K70), @ 0xA0000 i see the Stack pointer (1FFF8148), @ 0xA0000+4, i see the address of the startup code (i guess) which is 000A11BD.

When i call "start_application(0xA0000);"

It does a very strange thing. The Stack pointer takes the value: 0x4881ff1c, and the program counter takes the value 0xbd110a00.

Obviously, everything is inverted somewhere... seems like a big/small endian problem.

Have any body has similar problems before?

Any idea how to resolve this?

Thank you very much. i'm going nuts!

[mjbcswitzerland]

Hi

When you say you can read 0x1fff8148 at 0xa0000 how are you viewing it? Are you viewing it as a long word in little-endian mode or are you seeing 4 x bytes like

0x1f 0xff 0x81 0x48 ?

If the second is true it would mean that you are saving the code in big-endian order and so the SP load would be inverted to that which you require.

If you use asm(" ldr sp, [r0,#0]"); to load the SP I can't imagine that the instruction will be doing it incorrectly.

Regards

Mark

Kinetis: µTasker Kinetis support

Boot loader: http://www.utasker.com/docs/uTasker/uTaskerSerialLoader.PDF

K70: µTasker Kinetis TWR-K70F120M support  / µTasker EMCRAFT K70F120M support

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

[ikalogic]

Hello Mark,

Never mind, i found the problem. The byte order of my generated s19 file was inverted. i don't know on earth why. i can't even find an option to change that in code warrior. don't know what happened! anyway, my Qt software takes care of reordering the 4 bytes of each 32bit word, and it's working just fine...

Thanks a lot for all the help you're providing, it means a lot to many of us :smileyhappy:

[ndavies]

Mark, I was just looking at Anders original code that started this thread. I wasn't sure the jump sequence he used would generate the Odd address function call since he hard coded the jump address. He also stated he was getting a reset when he tried to jump to the application. Possibly a symptom of jumping to an even address. The odd addressing thing cost us some time when we were trying to get our boot loader up.

[mjbcswitzerland]

Norm

Yes, then it would be necessary to use the odd address. I don't expect that 0x00C28CB0 was more than a first quick attempts sicne it would need to be the entry point (possibly looked up in the map file) and so either move around on each application build or else need to be fixed by pinning its location down with linker configuration and compiler pragmas and such other nasty things (and less portable) things.

Regards

Mark

[mjbcswitzerland]

Anders

The uTasker serial loader project provides a complete boot loader framework (for the K64) which can be simply adapted to any futher protocol that needs to be developed. In case of further complications this would allow you to immediately concentrate on your loader protocol rather than first have to develop such an infrastructure.

Note that you can't start an initial program from any other address than the reset vector so you need to first have a boot loader installed (booting from the reset vector) and then test an offset application which is jumped to by that boot loader. The following code can, for example, be used for the jump on a K64:

// Allow the jump to a foreign application as if it were a reset (load SP and PC)
//
extern void start_application(unsigned long app_link_location)
{
    asm(" ldr sp, [r0,#0]"); // load the stack pointer value from the program's reset vector
    asm(" ldr pc, [r0,#4]"); // load the program counter value from the program's reset vector to cause operation to continue from there
}

This allows any application to be jumped to (knowing its offset link address). In your case you would jump using

start_application(APP_ADRESS);

The framework also includes a K64 (real-time) simulator that allows boot loaders to be tested and debugged with VisualStudio (free Express edition adequate), execising peripherals and interrupts and emulating the flash operation. There is a video showing boot loader debugging at AVR32_boot.wmv - YouTube (not on the Kinetis but equivalent and using a more complicated encrypted boot loader technology requiring such debugging capabilities more that the standard cases).

Regards

Mark

µTasker Kinetis support

[robotjosh]

Might have to use __asm for gcc.  I tried this and verified that app_link_location value is put into r0 in gcc.  It works except that loading the bootloader wipes out the main application and it jumps to a series of 0xffffffff.  That AVR32 looks pretty sweet!  I'll give utasker a look but am determined to make this bootloader happen in kds/gcc/pex.

[mjbcswitzerland]

Josh

Yes, for GCC there is the define

#define asm(x) __asm__(x)

asm() is used directly by some compilers (like IAR) and older GGC versions need

#define asm(x) _asm_(x) (with only one underline for some reason).

To my defence, I used the AVR32 before the Kinetis were available. All AVR32 uTasker projects can also run on Kinetis parts (due to its HAL layer) so AVR32 users who preferred to move to Kinetis had almost zero porting work to do.

Regards

Mark

[robotjosh]

I'm having similar problems.  The multilink debugger always erases entire flash even when you uncheck the erase flash checkbox so you cannot load two programs that take up different memory areas.  Maybe your application jump code is working but you cannot load both programs at the same time.

Seems like a lot of non-default options are still broken in kds.  -fPIC broken.  Firmware image binary broken (it generates a 536mb file for a 512kb device) so that will have to be fixed before I can generate the binary that will be written to flash by the bootloader.  Interrupt vectors in ram option is broken, anything with this option enabled will not run at all.  I've written bootloaders before without half as many problems, its starting to get comical!

[mjbcswitzerland]

Josh

If the the tools restrict loading two images seperately you can combine them into one and load that. This can be done with various tools or manually by adding two SREC files together.

The uTasker project contains boot loader utilities which has such a tool (uTaskerCombine) - it can be downloaded at uTasker Utilities and allows combining binaries specifically for such purposes.

Regards

Mark