Hard Fault on Memory Write K64F

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Hard Fault on Memory Write K64F

Jump to solution
1,104 Views
nhinshaw
Contributor III

Hello,

 

I am currently doing development on a custom boot-loader for my K64F, and I noted a hard fault when writing in certain memory locations.  In this case, there are two portions of an S19 that when flashed cause a hard fault.  these two lines are

53 33 0D 00 04 57 EC 00 00 00 00 01 14 00 00 96

followed by the second line

53 33 29 00 04 57 F4 EC 57 04 00 00 A0 00 20 08 00 00 00 F4 57 04 00 00 05 FF 1F 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06

 

both records seem to align properly, the first address, going to 0x457EC, aligns as two 32 bit values, while the second, at 0x457F4, aligns 9 32 bit values.  neither value should overwrite the other, as they are in different 32 bit spaces, which led me to changing my write to take each 32 bit chunk and write it individually to the flash, allowing me to debug which chunk crashes the program.

Write execution followed this order, First packet is sent, both pieces are wrote to their memory locations, 0x457EC, 0x457F0.  followed by the second packet being sent.  As its sent, the address at 0x457F0 turns red.  As "third write occurs", it is erased, and as the next write of the second packet occurs, we hit "hard fault" where the program has crashed.  From the variable view, the addresses are being stored correctly, and the U32 i am writing is the correct data to be wrote.  Any idea what could be happening?  attached are the PNG's referenced, as well as the S19 file i am attempting to flash.

 

-Thanks

Nate Hinshaw

Original Attachment has been moved to: K64FRedLight.afx.S19.zip

0 Kudos
1 Solution
914 Views
mjbcswitzerland
Specialist V

Hi

It sounds as though you are not respecting the K64's phrase programming requirement (16 bytes aligned) and so if you write two long word straddling a phrase it will cause Flash corruption and hard faults on subsequent reads from the phrase. This requires an erase to recover the Flash sector.

It is best to add a small RAM buffer to collect the phrases and then program each as it becomes full so that there is no dependency on the SREC content and the actual Flash programming operation is transparent to the application layer.

I have attached the Flash driver from the uTasker project as reference which does this (compatible with all K, KE, KL, KV etc. parts) so no porting is required when moving between devices.

Alernatively you can get a complete solution [industrially proven in many custom K64 projects]  with UART SREC, iHex, KBOOT, AN2295 developer's loader loading for the K64 from the serial loader project (which also allows SD card, Ethernet, USB-MSD, USB-Kboot, USB-memory stick - also in parallel with UART operation) from http://www.utasker.com/kinetis/FRDM-K64F.html / http://www.utasker.com/kinetis/TWR-K64F120M.html [documentation at http://www.utasker.com/docs/uTasker/uTaskerSerialLoader.PDF].

Regards

Mark

View solution in original post

4 Replies
914 Views
nhinshaw
Contributor III

Thanks for all the help Mark!

-Nate

0 Kudos
914 Views
nhinshaw
Contributor III

Sure enough, if I manually align Lines 92 and 93 of the S19 file from

S30D000457EC000000000114000096 and

S329000457F4EC57040000A0002008000000F45704000005FF1F0000000000000000000000000000000006

to

S331000457EC0000000001140000EC57040000A1002008000000F45704000005FF1F00000000000000000000000000000000F0

followed by flashing that line as a block

my program flashes and executes just as I would expect.  How would i check the srec lines against misalignment?  I don't know how to look at the two lines and be aware that they need to be combined

-Best

Nate

0 Kudos
914 Views
mjbcswitzerland
Specialist V

Nate

It is not an SREC issue (you need to be able to accept any alignment) but a programming implementation issue - just save the data to be programmed into a RAM buffer and wait until the buffer fills to a natural size before programming the content to flash and you shouldn't have any problems.

You could write a program that takes an SREC input and converts it to an aligned version (filling in any gaps and such) but this is a workaround and is more difficult than correcting the issue at the source.

Regards

Mark

P.S. See fnWriteInternalFlash() and its buffer ulFlashRow (declared as below, with FLASH_ROW_SIZE of 8 for the K64)  [in the file that I attached] to see how it can be easily done.

static unsigned long ulFlashRow[FLASH_ROW_SIZE/sizeof(unsigned long)] = {0}; // FLASH row backup buffer (on long word boundary)
915 Views
mjbcswitzerland
Specialist V

Hi

It sounds as though you are not respecting the K64's phrase programming requirement (16 bytes aligned) and so if you write two long word straddling a phrase it will cause Flash corruption and hard faults on subsequent reads from the phrase. This requires an erase to recover the Flash sector.

It is best to add a small RAM buffer to collect the phrases and then program each as it becomes full so that there is no dependency on the SREC content and the actual Flash programming operation is transparent to the application layer.

I have attached the Flash driver from the uTasker project as reference which does this (compatible with all K, KE, KL, KV etc. parts) so no porting is required when moving between devices.

Alernatively you can get a complete solution [industrially proven in many custom K64 projects]  with UART SREC, iHex, KBOOT, AN2295 developer's loader loading for the K64 from the serial loader project (which also allows SD card, Ethernet, USB-MSD, USB-Kboot, USB-memory stick - also in parallel with UART operation) from http://www.utasker.com/kinetis/FRDM-K64F.html / http://www.utasker.com/kinetis/TWR-K64F120M.html [documentation at http://www.utasker.com/docs/uTasker/uTaskerSerialLoader.PDF].

Regards

Mark