Custom Bootloader for Kinetis MKE06Z microcontrollers on IAR EWARM issue

[ngiussani]

I've been having some trouble in the implementation of a custom bootloader for a Kinetis MKE06Z microcontroller, not in the bootloader itself but in the relocation of the application code and the behavior after jumping to it. The application is completely coded in C.

The bootloader executes everything as expected, determines if it should run or jump to user application. This is the sequence that implements the jump:

__disable_interrupt();
SCB->VTOR = RELOCATION_VECTOR_ADDR & 0x3FFFFE00;
JumpToUserApplication(RELOCATION_VECTOR_ADDR);

where:

void JumpToUserApplication(uint32_t userStartup) {

/* set up stack pointer */
asm("LDR    r1, [r0]");
asm("MOV    r13, r1");
/* jump to application reset vector */
asm("ADDS   r0,r0,#0x04 ");
asm("LDR    r0, [r0]");
asm("BX     r0");

}

as implemented in Frescale's AN4767.

So far, so good. Once the jump is executed, I trace the application behavior (on the Disassembly Window) and find out after some instructions, it gets stuck at some specific address with a jump instruction, which ends up being an infinite loop. I then run it step by step to determine which was the instruction that causes this malfunction. It's very strange, as it is running OK and suddenly jumps to a RAM address. A couple of cycles and then jumps to the infinite loop. I took note of the addresses with the instruction causing this strange jump and the one with the infinite loop. I look at the core registers and find out there is an exception, and notice it's the number 0x03 (Hard Fault). Then switch to debugging the user application.

Once in the user application, I start debugging. The user application works fine running like this (no jump from the bootloader). Then I look for the relevant addresses and discover that the routine causing the hard fault when jumping from bootloader is from IAR: __iar_data_init3. The thing is, it's part of a precompiled library and I'm not sure if it's safe to remove it (by removing the __iar_program_start and replacing it directly with the call to main on the startup file.

The real question is: why does the application behave like that after the jump from the booloader but not if there is no such jump? Why does this routine jumps to a RAM address (when it shouldn't)?

Of course, it may be a little to specific, but hopefully there's someone that can help me.

[ngiussani]

It seems that something IAR does with the linker configuration is not very clear to me, but has something to do with this problem. The thing is I relocated .text segment:

define symbol __ICFEDIT_intvec_start__ = 0x00001800;

define symbol __ICFEDIT_region_ROM_start__ = 0x00002000;

define symbol __ICFEDIT_region_ROM_end__  = 0x0000FFFF;

define region APP_ROM = mem:[from (__ICFEDIT_region_ROM_start__)  to (__ICFEDIT_region_ROM_end__)];

place at address mem:__ICFEDIT_intvec_start__ { readonly section .intvec };

place at start of APP_ROM { readonly section .text };

It seems that the linker doesn't appreciate this and something make the app misbehave when jumping from other app. Instead of this, keeping the original .icf file and editing within the GUI only the .intvec_start solved the problem, but code starts right next to the vector table. Not an issue, but I wanted to relocate code a little farther.

[mjbcswitzerland]

Hi

Check the uTasker's IAR serial loader (and application) for the FRDM-KE06Z as comparison (it is available as anonymous download at the link including IAR KE06 support). You may then be able to identify some difference that explains your problem.

Essentially I wouldn't normally expect any risk of a hard fault after the jump because interrupts are not yet involved. But it may be that your stack pointer is bad when the IAR startup code starts, which could cause sub-routines that the library functions call to fail due to a bad RAM access (carefully check that you are using the userStartup pointer correctly; r0 must point to a valid initial stack poiter value).

The start-up routines initiase system bss and variables so it is not possible to removed these!

Regards

Mark

http://www.utasker.com/kinetis/FRDM-KE06Z.html

[jeremyzhou]

Hi Nicolas,

According to your statement, it seems that the issue was caused from the application code, not the boorloader code.

And before answer your question, I'd like to get  the more information about the issue.

Did you already try some other application codes or not?

Does the issue still exist when try other application codes?

I'm looking forward to your reply.
Have a great day,
Ping

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