AN2295 bootloader compatible with KE06 family? No success in finding documents!

[michaelwilson]

Does anyone have further documentation regarding the compatibility of AN2295 bootloader with the KE06 family of controllers?

In my search, I have stumbled upon the Kboot which would be replacing the AN2295 for Kinetis mcus, also found uTasker implementations for using Kboot and AN2295 at the same time but I would rather not go this route. I've seen countless examples and documents for FRDM-KL25Z step by step tutorials (including excellent ones by Erich Styger at McuOnEclipse, and for many K'x' (K02-K64) series. But no real concrete examples that show how to make AN2295 work with KE06Z. I did find AN4767 (FRDM-KE02Z ) short application note but did not find it useful enough to clarify my issues.

I am stuck here!

1) KE06 does not have a SIM_SDID register, instead it has the SIM_SRSID and may have a different format. What part should be sent to IDENT command?

2) All the examples (including the AN4767 note) discuss the FLASH (FMC) procedures needed to program the memory. Will including the sources "flash_kinetis.h and flash_kinetis.c" will work when using KE06?

3) Is it necessary to also relocated the backdoor key?

m_cfmprotrom  (RX) : ORIGIN = 0x00000400, LENGTH = 0x00000010  (to start at 0x1400) ??

Successful here ->

I have configured the linker file to move the memory to 0x1410 and relocated the vectors on the app to be loaded, but so far I have to trick the pc program with the SDID of the wrong mcu. Successfully sending 32k bytes via UART to the KE06.

Using KDS 3.0, with KE06Z 64K memory, 44pin.

BlackNight​

http://cache.freescale.com/files/microcontrollers/doc/app_note/AN2295.pdf?fsrch=1&sr=1&pageNum=1

http://cache.freescale.com/files/32bit/doc/app_note/AN4767.pdf

http://cache.freescale.com/files/microcontrollers/doc/app_note/AN2295SW.zip

[mjbcswitzerland]

Michael

1. The IDENT doesn't send any information about the chip (at least not protocol version 8). If you have any communiation that sends a part number just send one matching a chip that it knows.
When reading the application note AN2295 beware that it doesn't always match the operation (it has some deviations either due to mistakes or due to points not being updated as the protocol developed) - it is best to take a working loader of a board that is supported and copy what it does.

2, The Flash drivers included in the SW pack are not suitable for the KE parts - the KE parts have a different Flash controller with different registers and a different operation. Beware that it also needs a clock to be initialised based on the bus speed otherwise it is possible to damage the flash when not set up accurately (worst case, but probably unlikely to really kill anything).

3. Application loaded with bootloaders do not have a flash configuration - the bootloader is the only code that can do this. Most people just move the flash configuration to some random location in code where it does nothing and also doesn't harm anything The cleanest method however is to completely remove it.

Regards

Mark

[michaelwilson]

Thank you for the reply and insight into these issues.

IDENT: After reading the KE02Z AN4767 example code and notes, I see that the IDENT command configured here sends a known mcu 0x14A and not the KE02 SRSID register. So I'm good here.

I compared the reference manuals for both mcus and it appears that the flash driver (FMC) used in the KE02 is very similar to the KE06. So I'm willing to be that I am on the right track. Now the difficult part is importing the example code for their FRDM-KE02Z 64KB flash into a KDS project. Then I will try to change the "derivative" along with MKE02Z2.h to MKE06Z4.h and hope that it works! :-).

Unfortunately I am having trouble linking all the files together in the KDS project, it keeps complaining that things like common.h don't exist when clearly it is included properly.

I will keep everyone updated on my status as I really want to learn how to progress with this bootloader.

[mjbcswitzerland]

Hi

Yes, the Flash in all KE parts is the same so KE02 and KE06 programming code is compatible.

Regards

Mark

[michaelwilson]

Wow!

The flash memory module is called FTMRH in the KE02Z and FTMRE in the KE06Z!

This causes all kinds of compile errors when adding the example source flash.c and flash.h to my project, after replacing the "H" with "E" all but two errors exist.

It seems like the KE06 does not have the following register: 4002_0007 Flash Error Status Register (FTMRH_FERSTAT) which is required for this flash source code.

Temporary Roadblock! :-(

[mjbcswitzerland]

Michael

The KE02 has the same Flash controller as the KEA08 and KEA64.

The KE04 and KE06 have the one from the KEA128.

For the user they are compatible since the registers are jiggled-about in the memory map (header) and the KE06 doesn't have an error status register. However there is no need to use this register in the actual code - it will only signal an error if the flash driver is trash (which it won't be in your case) [the register is of more use when developing a new driver since it can be seen when the driver does something wrong but later it is of little interest]. Therefore simply comment out the line using it and then you have nothing to worry about.

Regards

Mark

[michaelwilson]

Mark:

Thank you very much, you have been so helpful in clarifying my issues!!

So I commented the code as you mentioned and I was able to compile and use the program flash routine available in flash source to load a new program. It seems to be flashing correctly. However, I suspect the method by which I am jumping to the program vector is not correct. Also, the pc program continues to warn about the image not fitting when I verified the image is only 3kb in size starting at Mem 0x8000 and my bootloader is 10kb. Weird!

Two variants of the assembly code are used as example and this one was the only one that compiled. In fact, I had to change "adds to add" due to a thumb16 error.

I have to read more to understand what exactly is happening when the address 0x8000 is passed on to this function. I don't see why we are also adding 0x04 to the register or how the function argument is actually loaded in r1 or r0.

[code taken from an4767 kinetis ke02z]

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");

}

[code taken from an2295sw for kinetis k60]

static void JumpToUserApplication(LWord userStartup)

{

    unsigned long* ptr_jump = (LWord*)userStartup;

    /* set up stack pointer */

    asm("LDR      r13, [r1] ");

    ptr_jump++;

    /* jump to application reset vector */  

    asm("BX       *ptr_jump");

}

It looks like a I have some reading to do from previous discussions: https://community.freescale.com/message/113048#113048

[mjbcswitzerland · Accepted solution]

Michael

Here is a better commented version of the same KE jump code which should make it more understandable. Although the assembler is slightly more efficient in this version, it is essentially doing the same thing (by the way, r13 is another name for the stack pointer).

    asm(" ldr r1, [r0,#0]");    // get the stack pointer value from the program's reset vector
    asm(" mov sp, r1");         // copy the value to the stack pointer
    asm(" ldr r0, [r0,#4]");    // get the program counter value from the program's reset vector
    asm(" blx r0");             // jump to the start address

You won't be able to use the version from AN2295SW since it is Cortex M4 code, which is not suitable for the KE's Cortex M0+ core.

From the warning the tool is giving it looks like you have a memory block set up for 0x8410..0x7bf0 but trying to write to the address 0x8400 (outside of the block).

The 0x400..0x410 range probably has something to do with the Flash configuration area. As mentioned earlier there is no such area for the application so probably there is some rogue configuration that can be removed from somewhere.

There are two thing that help when starting debugging the operation when transitioning from loader to application:

1. Look at the actual SREC content that was prepared and loaded, to check that all addresses are as expected.

2. After loading, use the debugger to look to see what is actually programmed in Flash from the start address (0x8000 in your case) and check that it is identical to the SREC data at the expected addresses.

Usually any deviations are clear and can be sorted before hoping that the jump works and the application actually runs (when there could be in fact either nothing actually there or things are simple in the wrong place).

Regards

Mark

[michaelwilson]

For all practical purposes, the bootloader is working! :-)

I was able to flash the KE06, then jump to new application.

Thank you Mark for all of your help in explaining how this works! :-)

Still get a few warnings in the PC program "image will not fit" despite re-configuring where the memory block is defined.