KL17: Updating bootloader from application fails with erased flash

[Alexander_S]

Dear community,

When trying to update the bootloader from the application (not vice versa) in the internal flash of a MKL17Z128 (M0+ core, 128 kB flash), the flash content is shown correctly via the debugger interface directly after flashing. But after a reset or power cycle the complete flash is erased, zero page, bootloader and application area.

What I did was relocating and adapting the existing bootloader to be an application, which then in turn is used to update the bootloader. Also, updating the application from the bootloader, with identical flash routines, works fine. I use flash-routines placed in RAM and interrupts are disabled during flashing. The exact same code works fine, when updating the vectors page or when updating the application from the bootloader. But something fails when updating the bootloader area from the application.

Flash memory layout is as follows:

• 0x0 - 0x400: vectors page
• 0x400 - 0x6000: uTasker serial bootloader area
• 0x6000 - end: application area

Working set-up is a MKL17Z128, MCUXpresso 13, Segger J-Link connected via SWD, UART doing Modbus for the software update on the target.  

When updating the bootloader, at first, the updater-application is loaded into the target via the bootloader. Then, the updater-app takes over, and, to secure the process against power loss during flashing, re-writes the vector page so it always is started after power-up. Up to this point everything works fine and reproducible.

Then, the updater-app clears the bootloader area and starts writing the new bootloader. From here things get weird. Even if I only clear the area, but do not write anything to the flash, the flash memory shown by Segger's J-mem seems to be as  expected, but after reset, a power cycle, or sometimes just by disconnecting and re-connecting the software connection to the debugger (not the SWD cable), the flash is shown as erased. This is correct as the target won't boot anymore and the bootloader needs to be flashed again.

I also tried to re-start the target with the bootloader updating app installed to make sure, the correct interrupt vectors are active. But it did not change the result.

The problem is, why is the flash content erased after the reset, but shows the correct content before? Is it the debugger connection showing incorrect information, or is it the µC and it's flash controller going amok?

Another thing I did not find out is, why is the vector page mostly empty and the VTOR set to 0x0, although there are interrupt routines which obviously work correct? I studied the documentation from NXP and ARM about the Cortex-M, the M0+ and the Armv6-M architecture reference manual, but did not find the missing link here.

Any hints for where to look for the problem are greatly welcome.

Regards,

Alexander

[Alexander_S]

Hi Jing,

Thanks for your answer. I do not apply Flash security at the moment, so if the bits are set, it should have happened as a failure. I'll check it though as soon as possible.

Best regards,

Alexander

[jingpan]

Hi @Alexander_S ,

It sounds really weird. Did you check the FTFA+FSEC[SEC] bit after a power cycle? If this field is 00 or 11, the flash is secured, then you can't read flash.

Regards,

Jing

[Alexander_S]

Hi @jingpan,

thank you for your reply. The register contains 10 after (and before) power cycle. So that does not seem to be the problem.

Kind regards,

Alexander

[jingpan]

Hi @Alexander_S ,

Can you give a example project? This sounds really interesting.

Regards,

Jing

[Alexander_S]

Hi @jing 

The project is an adaptation of SW licensed from @mjbcswitzerland, so I'd need to ask for his permission or support, before I can send the complete project.

Also, I have only 5 days left at my current company and I'm not sure, how much time my successor will have to invest in this problem. But the bootloader-updater is needed anyway, so chances are there, that it will be pursued.

Let me update my reply, when I heard Mark (@mjbcswitzerland) and/or my colleague.

Kind regards,

Alexander

[mjbcswitzerland]

Hi Alexander

It is Ok for you to supply the project source to NXP.

Regards

Mark