update binary with full flash size using flashloader and the KinetisFlashTool

[JulianS]

Hello,

I am working with the flashloader for MKV58F1M0xxx24 and I ran into an error.

What I am trying to do is an update using the KinetisFlashTool with the factory perprogrammed flashloader as well as the flashloader I build from the SDK (v2.8.0) in order to test the update mechanism.

I observed the behaviour of the flashing process with a debugger and found out, that the flashing process always fails, when my update binary is in the following range:
(FlashSize - 0x400byte) < BinarySize < FlashSize

In case the question arises, why I try to update such big binaries that fill the entire flash space:
This is because I fill the whole flash memory that is not needed by my application with a chosen pattern for furher usage.

The update process fails in memory.c while the function find_map_entry is executed. The error takes place, when the address+length of my update does not fit the address range of the flash (line 344). This is only because of some mysterious 0x400 byte offset in the size of my binary. So when I am trying to flash my binary of exactly 1MB, the FlashTool seems to append some (to me unknown) 0x400 byte, causing the range check to fail.

When I don't consider this 0x400 byte increment in the size of my binary, I am not able to perform the flashing process without getting the error:

kStatusMemoryRangeInvalid (10200): Memory range conflicts with a protected region.

So my workaround for the error is as simple as this: I force my application to not exceed a binary size of 1023kB by reducing the accessable flash memory section in my linker file by 0x400 byte. I don't like this workaround, as I lose 1kB of flash space for my application.

I would be pleased if I could get some information about this issue, as I don't see any kind of update-size restriction in any manual about the flashloader.

My assumption is, that it is not possible to use the KinetisFlashTool and the flashloader to updates a binary in the stated range, but I would be happy to be proven wrong

Kind regards,

Julian

[jingpan]

Hi @JulianS ,

First of all, It's not good to program 0xff to all blank area and them program data/code to this area again. Program 0xff is also a kind of program. Programming twice make cause flash read out unstable.

I tested on my TWR-KV58F evk. I use MCUxpresso IDE to download Flashloader image to RAM and then use KinetisFlashTool to download a 1M byte image. It works fine, doesn't report any error.

Regards,

Jing

[JulianS]

Hello Jing,

thank you for your reply!

I understand your concerns about reprogramming a flash section that is already programmed. But I don't see the correlation to my issue, as I am writing a binary, where specific (unused) sections in my flash memory are filled with a pattern that does not equal 0xFF... When updating my binary the flashloader does a pre-erase operation before flashing my binary, so this should have the same effect as a normal flash process.

I also tested my issue with a 1Mbyte binary of random data (see the Attachments) and get the same error:

The only adaptions to the flashloader I made are changes in the pin multiplex, as I am using a custom board with different pins for UART functionality. I don't get why I see a different behaviour to your setup...

Kind regards,

Julian

[jingpan]

Hi @JulianS ,

I tested your binary. It passed the test too.

Did you modify the Flashloader project from SDK? I use MCUXpresso and SDK2.8.0.

Regards,

Jing

[JulianS]

Hello Jing,

thank you again for your support.

Yes I used the flashloader from the SDK2.8.0 and made some changes in the pin multiplex in order to get the flashloader like it is defined in the factory preprogrammed flashloader of the µC. I edited pin_mux.h & pin_mux.c for the uart pins and additionally I defined FREEDOM as a preprocessor symbol...

I also use the Kinetis Flash Tool from the SDK2.8.0.

Please see my attachment for a comparison of the flashloader project I am using.

Kind regards,

Julian

[JulianS]

ignore this reply...