Kinetis Microcontrollers中的主题 Re: Bootloader for Kinetis K64 (Cortex M4)

Bootloader for Kinetis K64 (Cortex M4)

andersbergström — Tue, 02 Dec 2014 08:41:20 GMT

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

Re: Bootloader for Kinetis K64 (Cortex M4)

robotjosh — Tue, 02 Dec 2014 13:44:03 GMT

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!

Re: Bootloader for Kinetis K64 (Cortex M4)

mjbcswitzerland — Tue, 02 Dec 2014 14:23:51 GMT

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

Re: Bootloader for Kinetis K64 (Cortex M4)

mjbcswitzerland — Tue, 02 Dec 2014 14:42:24 GMT

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

Re: Bootloader for Kinetis K64 (Cortex M4)

robotjosh — Tue, 02 Dec 2014 15:51:39 GMT

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.

Re: Bootloader for Kinetis K64 (Cortex M4)

ndavies — Tue, 02 Dec 2014 17:26:50 GMT

Did you modify the linker descriptor file to have your application and its vector table start at the new address? The boot loader and Applications linker descriptor files must specify different code addresses from each other.

You also need to make sure you are jumping to an odd address when you jump from the boot loader to the application. It should be APP_START+1. The Arm core Uses the Even Vs Odd address to decide which instruction set to run when it gets to the new address. All instructions are on even addresses. A jump to an odd address keeps the MCU in THUMB instruction mode, Jumping to an even address causes a hard fault on the Kinetis since it only supports the Thumb instruction set.

Re: Bootloader for Kinetis K64 (Cortex M4)

mjbcswitzerland — Tue, 02 Dec 2014 20:45:57 GMT

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

Re: Bootloader for Kinetis K64 (Cortex M4)

mjbcswitzerland — Tue, 02 Dec 2014 20:54:27 GMT

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

Re: Bootloader for Kinetis K64 (Cortex M4)

ndavies — Tue, 02 Dec 2014 21:22:13 GMT

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.

Re: Bootloader for Kinetis K64 (Cortex M4)

mjbcswitzerland — Tue, 02 Dec 2014 21:36:48 GMT

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

Re: Re: Bootloader for Kinetis K64 (Cortex M4)

andersbergström — Wed, 03 Dec 2014 14:51:52 GMT

Norm,

I modified my linker file. Please see the one I attached for the bootloader. (I never written a linker file either, so there might be something missing in it.)

To merge the two binary files together, i use the following shell script:

`cat HELLO_WORLD_BL.bin > bootloader.bin`

`cat bootloader.bin HELLO_WORLD.bin > combined.bin`

`rm -f tmp.bin bootloader.bin`

I tried both my function, and the one Mark provided to perform the Jump without any luck.

Re: Re: Bootloader for Kinetis K64 (Cortex M4)

mjbcswitzerland — Wed, 03 Dec 2014 15:26:51 GMT

Anders

If you use the jump code that I posted, don't use your entry address (0x00C28CB0) but instead use the address where you linked your application code to (eg. 0x8000 - it will usually be aligned to a 4k boundary).

When you combine your two binaries make sure that you also have the application locate at the address that it is linked to be at. I think that the cat function you use will simply add the two together which is not suitable since the program MUST be at the correct (physical) address otherwise nothing can work.

If the cat utility doesn't prove to be suitable simply use the uTaskerCombine that I linked to. It can be called with

uTaskerCombine bootloader.bin HELLOW_WORLD.bin 0x8000 combined.bin

where 0x8000 is the (example) address where the second file should be appended to and the gap between if filled with 0xff.

Another potential problem with combining binaries (if output from CW using metroworks compiler) is that they are sometimes not RAW binary but are in MOTOROLA binary format (that means that they are divided into chunks and each chunk has a small header informing where its address is). Using simple binary tools may result in the output being in a format that can't be loaded using most tools (it will be loaded but the content can't run).

uTaskerCombine will also recognise MOTOROLA binary format and always generate output file in RAW binary so that it can be loaded to the processor with any tools.

Don't forget that there is already a complete general purpose solution for the K64 in the uTasker serial loader project http://www.utasker.com/docs/uTasker/uTaskerSerialLoader.PDF so you could simply use that and then get started with the actual customised protocol. It works out-of-the-box for the K64 with CW, KDS, IAR, Keil, Atollic, Rowley Crossworks, CooCox or standalone GCC and the Kinetis can be simulated (in approx. real-time) in VisualStudio so also custom developments parts are must simpler to develop, test and debug.
There are all tools and configurations needed as well as Flash drivers, peripheral drivers and communication suites (serial, Ethernet, USB) allowing flexible loaders to be configured or constructed with minimum effort/work/investment (the project is optimised for efficiency of resource usage and so a web server based boot loader, for example, occupies only 18k of Flash).

Regards

Mark

Re: Bootloader for Kinetis K64 (Cortex M4)

robotjosh — Wed, 03 Dec 2014 15:38:31 GMT

I think you can just cat HELLO_WORLD_BL.bin HELLO_WORLD.bin > combined.bin. If this helps, here are my modifications to the linker scripts in order to be able to cat the two binaries:

For the main app add to the starting address of each memory location, I added 0x10000 to give the bootloader 64kb of space, and subtract that amount from the section size, and comment out this memory section:

/* m_cfmprotrom (RX) : ORIGIN = 0x00000400, LENGTH = 0x00000010 */

.cfmprotect :

{

. = ALIGN(4);

KEEP(*(.cfmconfig))

. = ALIGN(4);

} > m_cfmprotrom

For the bootloader linker script, it must be changed so that the binary is exactly the size of the bootloader flash space so that the concatenated main app binary starts at the correct address. Change the length of each memory section as if it were a 64kb flash device or however large your bootloader space is. Then add this section so that it generates a binary exactly the right size. .romp is the last section that is added to flash so it is used to calculate the starting address of the fill section.

.fill LOADADDR(.romp) + SIZEOF(.romp) :

{

FILL(0xAAAAAAAA);

. = ORIGIN(m_text) + LENGTH(m_text) - 1;

BYTE(0xAA)

} > m_text

You have to turn off linker file generation in processor expert after making these changes.

Re: Re: Bootloader for Kinetis K64 (Cortex M4)

andersbergström — Wed, 03 Dec 2014 15:49:51 GMT

Josh. I will try those modifications tomoroww morning.

Do you have the possibility to attach the modified linker scripts, so I can see them in their whole context? :smileyhappy:

Do i need to set the Entry Point as well in the application linker file? Right now it is set to Reset_Handler.

Re: Re: Bootloader for Kinetis K64 (Cortex M4)

andersbergström — Wed, 03 Dec 2014 15:51:10 GMT

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

Re: Re: Bootloader for Kinetis K64 (Cortex M4)

robotjosh — Wed, 03 Dec 2014 15:57:15 GMT

You shouldn't have to change the reset handler, leave defaults in the bootloader. For the main app, those interrupts and reset vector will work the same at location 0x10000 after you set the SCB_VTOR = 0x10000

These are default processor expert generated linker scripts with the changes I mentioned. I do not see how to attach the file but I can paste the bootloader linker script. The main app linker script has the simple changes I mentioned.

/* Entry Point */

ENTRY(__thumb_startup)

/* Highest address of the user mode stack */

_estack = 0x20000000; /* end of m_data */

__SP_INIT = _estack;

/* Generate a link error if heap and stack don't fit into RAM */

__heap_size = 0x00; /* required amount of heap */

__stack_size = 0x0400; /* required amount of stack */

MEMORY {

m_interrupts (RX) : ORIGIN = 0x00000000, LENGTH = 0x00000198

m_text (RX) : ORIGIN = 0x00000410, LENGTH = 0x0000FBF0

m_data (RW) : ORIGIN = 0x1FFF0000, LENGTH = 0x00010000

m_data_20000000 (RW) : ORIGIN = 0x20000000, LENGTH = 0x00010000

m_cfmprotrom (RX) : ORIGIN = 0x00000400, LENGTH = 0x00000010

}

/* Define output sections */

SECTIONS

{

/* The startup code goes first into INTERNAL_FLASH */

.interrupts :

{

__vector_table = .;

. = ALIGN(4);

KEEP(*(.vectortable)) /* Startup code */

. = ALIGN(4);

} > m_interrupts

.cfmprotect :

{

. = ALIGN(4);

KEEP(*(.cfmconfig)) /* Flash Configuration Field (FCF) */

. = ALIGN(4);

} > m_cfmprotrom

/* The program code and other data goes into INTERNAL_FLASH */

.text :

{

. = ALIGN(4);

*(.text) /* .text sections (code) */

*(.text*) /* .text* sections (code) */

*(.rodata) /* .rodata sections (constants, strings, etc.) */

*(.rodata*) /* .rodata* sections (constants, strings, etc.) */

*(.glue_7) /* glue arm to thumb code */

*(.glue_7t) /* glue thumb to arm code */

*(.eh_frame)

KEEP (*(.init))

KEEP (*(.fini))

. = ALIGN(4);

_etext = .; /* define a global symbols at end of code */

} > m_text

.ARM.extab : { *(.ARM.extab* .gnu.linkonce.armextab.*) } > m_text

.ARM : {

__exidx_start = .;

*(.ARM.exidx*)

__exidx_end = .;

} > m_text

.ctors :

{

__CTOR_LIST__ = .;

/* gcc uses crtbegin.o to find the start of

the constructors, so we make sure it is

first. Because this is a wildcard, it

doesn't matter if the user does not

actually link against crtbegin.o; the

linker won't look for a file to match a

wildcard. The wildcard also means that it

doesn't matter which directory crtbegin.o

is in. */

KEEP (*crtbegin.o(.ctors))

/* We don't want to include the .ctor section from

from the crtend.o file until after the sorted ctors.

The .ctor section from the crtend file contains the

end of ctors marker and it must be last */

KEEP (*(EXCLUDE_FILE (*crtend.o ) .ctors))

KEEP (*(SORT(.ctors.*)))

KEEP (*(.ctors))

__CTOR_END__ = .;

} > m_text

.dtors :

{

__DTOR_LIST__ = .;

KEEP (*crtbegin.o(.dtors))

KEEP (*(EXCLUDE_FILE (*crtend.o ) .dtors))

KEEP (*(SORT(.dtors.*)))

KEEP (*(.dtors))

__DTOR_END__ = .;

} > m_text

.preinit_array :

{

PROVIDE_HIDDEN (__preinit_array_start = .);

KEEP (*(.preinit_array*))

PROVIDE_HIDDEN (__preinit_array_end = .);

} > m_text

.init_array :

{

PROVIDE_HIDDEN (__init_array_start = .);

KEEP (*(SORT(.init_array.*)))

KEEP (*(.init_array*))

PROVIDE_HIDDEN (__init_array_end = .);

} > m_text

.fini_array :

{

PROVIDE_HIDDEN (__fini_array_start = .);

KEEP (*(SORT(.fini_array.*)))

KEEP (*(.fini_array*))

PROVIDE_HIDDEN (__fini_array_end = .);

___ROM_AT = .;

} > m_text

/* Initialized data sections goes into RAM, load LMA copy after code */

.data : AT(___ROM_AT)

{

. = ALIGN(4);

_sdata = .; /* create a global symbol at data start */

*(.data) /* .data sections */

*(.data*) /* .data* sections */

. = ALIGN(4);

_edata = .; /* define a global symbol at data end */

} > m_data

___data_size = _edata - _sdata;

___m_data_20000000_ROMStart = ___ROM_AT + SIZEOF(.data);

.m_data_20000000 : AT(___m_data_20000000_ROMStart)

{

. = ALIGN(4);

___m_data_20000000_RAMStart = .;

*(.m_data_20000000) /* This is an User defined section */

___m_data_20000000_RAMEnd = .;

. = ALIGN(4);

} > m_data_20000000

___m_data_20000000_ROMSize = ___m_data_20000000_RAMEnd - ___m_data_20000000_RAMStart;

/* Uninitialized data section */

. = ALIGN(4);

.bss :

{

/* This is used by the startup in order to initialize the .bss section */

__START_BSS = .;

PROVIDE ( __bss_start__ = __START_BSS );

*(.bss)

*(.bss*)

*(COMMON)

. = ALIGN(4);

__END_BSS = .;

PROVIDE ( __bss_end__ = __END_BSS );

} > m_data

_romp_at = ___ROM_AT + SIZEOF(.data) +SIZEOF(.m_data_20000000);

.romp : AT(_romp_at)

{

__S_romp = _romp_at;

LONG(___ROM_AT);

LONG(_sdata);

LONG(___data_size);

LONG(___m_data_20000000_ROMStart);

LONG(___m_data_20000000_RAMStart);

LONG(___m_data_20000000_ROMSize);

LONG(0);

} > m_data

/* User_heap_stack section, used to check that there is enough RAM left */

._user_heap_stack :

{

. = ALIGN(4);

PROVIDE ( end = . );

PROVIDE ( _end = . );

__heap_addr = .;

__HeapBase = .;

. = . + __heap_size;

__HeapLimit = .;

. = . + __stack_size;

. = ALIGN(4);

} > m_data

.ARM.attributes 0 : { *(.ARM.attributes) }

/* .fill 0x2a0c : same as below */

.fill LOADADDR(.romp) + SIZEOF(.romp) :

{

FILL(0xAAAAAAAA);

. = ORIGIN(m_text) + LENGTH(m_text) - 1;

BYTE(0xAA)

} > m_text

}

Re: Bootloader for Kinetis K64 (Cortex M4)

robotjosh — Wed, 03 Dec 2014 16:00:53 GMT

But be aware I have not tested my binary yet because I have not found a way to flash a binary using this fancy multilink fx, too fancy to deal with bin files! I'll have to finish the bootloader and test the binary and bootloader at the same time.

Re: Bootloader for Kinetis K64 (Cortex M4)

mjbcswitzerland — Wed, 03 Dec 2014 16:14:08 GMT

Josh

Just drop your binary onto the hard drive that appears when connecting the FRDM-K64F (assuming you are using, it or similar).

You can also convert your binary file into other formats using GCC's objcopy if that makes it easier for the tools.

Regards

Mark

Re: Bootloader for Kinetis K64 (Cortex M4)

ndavies — Wed, 03 Dec 2014 17:47:11 GMT

Josh, the Multilink doesn't care what format the executable file is in. It's the Development environment that specifies the file formats. The multilink doesn't know what a file format is. It only accepts the individual commands to physically flash the files onto the target. The development environment accepts various file formats and then converts it into flashing commands for the multilink.

There is a separate forum for KDS:

Kinetis Design Studio

And there is a thead on Programming binary files.

Flash from File: Downloading a file without the sources

Norm

Re: Bootloader for Kinetis K64 (Cortex M4)

robotjosh — Wed, 03 Dec 2014 18:15:01 GMT

Yes, I have attempted the procedure outlined in the Flash from File page after adding the kinetis.cfg option mentioned in this page KDS Debug Configurations (OpenOCD, P&E, Segger)

I used the elf file since that is in the example and should work. It produces this error:

Open On-Chip Debugger 0.8.0-dev-dirty (2014-08-20-11:07)

Licensed under GNU GPL v2

For bug reports, read

http://openocd.sourceforge.net/doc/doxygen/bugs.html

Info : only one transport option; autoselect 'cmsis-dap'

Error: unable to open CMSIS-DAP device

Error: unable to init CMSIS-DAP driver

Error: Error selecting 'cmsis-dap' as transport

Runtime Error: C:/Freescale/KDS_1.1.1/openocd/bin/..//scripts/kinetis.cfg:3:

in procedure 'script'

at file "embedded:startup.tcl", line 58

in procedure 'interface' called at file "C:/Freescale/KDS_1.1.1/openocd/bin/..//scripts/kinetis.cfg", line 3

Keep in mind that I want the multilink fx to flash a binary, this procedure appears to require the opensda chip included in the dev kit.