KL16 reset problem after in application programming

[ivansantanna]

Hello all,

I'm using a KL16 64Kb Flash MCU and I intend to have a Firmware Upgrade application on it.
So, I'm using the C90TFS lib to erase and program the internal MCU flash. I'm receiving the new FW from a external modem and saving it on a external serial flash. After complete the FW download and check the FW integrity, the code is jumping to a protected memory section at the end of flash memory and execute all the Flash drivers from C90TFS. Exporting the internal MCU flash memory to a file, I can check that the image recorded at internal flash after my application is iqual to the flash image before erase function (the flash image is the same recording by my routine and by JTAG device).

After procedure completed, I execute a NVIC_SystemReset(); to reset the MCU.
Everytime that I record the same firmware version that was recorded by JTAG device, I can see by debuger that the internal flash is erased and re-recorded with the same image and than the MCU resets and runs...
However, when I update the FW (put a new version using the FOTA routine) the MCU doens´t reset... I can see the firmware at the internal flash, but I think that the reset vector has been lost...
I'm erasing all the internal flash memory (from 0x0000 to 0xEFFF) including Interrupt Vector, Flash Config, and Text segments. My Fota segment starts on 0xF000 (size 0x1000).
If I'm replacing all the interrupt vector, why the MCU doesn't reboot?

Following is my memory structure:

MEMORY {
m_interrupts (RX) : ORIGIN = 0x00000000, LENGTH = 0x00000200
m_flash_config (RX) : ORIGIN = 0x00000400, LENGTH = 0x00000010
m_interrupts_ram (RW) : ORIGIN = 0x1FFFF800, LENGTH = 0x00000200
m_fota (RX) : ORIGIN = 0x0000F000, LENGTH = 0x00001000
m_text (RX) : ORIGIN = 0x00000410, LENGTH = 0x0000EBF0
m_data (RW) : ORIGIN = 0x1FFFFA00, LENGTH = 0x00001E00
}

I'm looking forward your feedback,

Best regards,

Ivan

[mjbcswitzerland]

Hi Ivan

I recommend that you try the uTasker project since it supports the KL16 and has a complete solution to do what you are doing (the "Bare-Minimum" loader) which supports SPI Flash intermediate storage and fail-safe firmware update from it (also encrypted).

I didn't see why you are having problems from your description but there is a serious issue in running the uploading code from the final sector (and deleting the boot sector) because any reset/power failure during the process will leave the device in a state that will require reprogramming with a SWD debugger. This will be unacceptable for any real product that is delivered to customers so will only be of interest in a hobbyist environment where "makers" can recover the board themselves if needed.

If you are not allowed to use existing and proven solutions you can still take the free open source version of uTasker (on Github) which allows the complete mechanism to be simulated (including internal and external SPI flash) and copy over the ideas and parts of code that are needed.

See the documents section on the uTasker web site for the "BM" loader details.

Regards

Mark

[ivansantanna]

Dear Mark, 

First of all, thanks for your quick response...

I decided to put my "loader code" at the end of flash to became easier to manage the memory,otherwise I should erase the first block (as interrupt vector and flash config) then jump the "loader code" area and than return to erase procedure for the rest of flash memory.
By my way, I can erase and program the flash from address 0x0000 up to 0xEFFF, since my "protected area" is from 0xF000...
I understood your point but, if I organize the reset vector routine to this protected area and after PE Init routine check if the loader finished to update the FW in the flash, and then goes to my app, I think that the problem reported is resolved. What do you think?
Brow, I cannot find on Github the project for KL16. Do you have the link?
Let me take advantage of this e-mail to ask you something: if I'm erasing and re-writing all the code area at flash memory, I understand that all the interrupt vector (including the reset vector) has the pointer address renewed. Why the code doesn't boot?
Should I do anything with the NVIC_SystemReset() routine? Where this routine is located in the flash? Should I fix it at the protected area? Maybe the NVIC_SystemReset() routine is been locating at diferente address at new FW version and the MCU cannot reset after finish the update process... what's your point of view according it?

Regards...

Ivan

[mjbcswitzerland]

Hi Ivan

https://github.com/uTasker/uTasker-Kinetis

A boot loader (unless there is a Flash swap block as the K64 etc.) MUST be in the first sector of Flash (and possibly more when larger) so that it can supply the reset vector and flash configuration, plus basic code to allow recovery [it is impossible to boot to other sector areas via the reset vector].

Any solution which deletes the first sector as a part of its operation leaves a window open for the product to fail in a catastrophic way. Therefore such a technique can't be used in a professional product; there is no way around this without accepting personal liability - as developer/designer - for some inevitable system failures.

Regards

Mark