Writing To Program Flash in K64 Without Driver

[stephenspaceman]

I'm trying to write my own routines to write to the program flash inside a K64FX512 and I can't seem to get it to work.

The commands that I pass to the FTFE unit seem to be succeeding: the CCIF bit gets set after some delay and there are no errors in the FSTAT register.

I used the 'section' attribute to place the functions that modify the flash into RAM to avoid Read While Write Violations. I can tell by looking at the size of the sections after building that this is actually placing the functions in RAM, although I have not been able to get the debugger to work inside of the RAM functions.

I'm attempting to write 16 bytes to Program Flash Address 0x00A000.  I do an Erase Flash Sector operation(0x09), a Program Section operation (0x0B), and then read back the memory location using a pointer. But what I'm reading back is not what I wrote, and when I read back after an erase, I do not get 0xFF's, I get random data. So something is not right.

The code that I am using is attached.

Am I doing anything obviously wrong, or can anyone point me in the right direction?

Original Attachment has been moved to: FTFE_Example.c.zip

[Jorge_Gonzalez · Accepted solution]

Hello Stephen Clark:

Your code seems correct, but I had issues too when running it. It was caused by the instructions that clear previous error flags. Instead of an OR operation (|=) do a direct write like below:

FTFE_FSTAT = 0x70;

Then it works.

Mark found your code confusing probably because he did not remember that the Program Section command uses part of the FlexRAM to write data to Flash, when not configured for the EEPROM functionality.

Regards!

Jorge Gonzalez

[stephenspaceman]

Jorge,

Thank you, that was it.  I was starting to go crazy.

Mark,

Thanks for giving my question some attention.  I looked through the uTasker, and it's one hell of a project.

Stephen

[mjbcswitzerland]

Jorge

Thanks for pointing out that section programming was involved because I had indeed forgotten that the FlexRAM is used as buffer in this case.

In the Flash file that I had posted it is also done similarly (using FlexRAM) when the define USE_SECTION_PROGRAMMING is enabled.

However, generally, I don't use this method because, although a little faster when the data is of the correct size and correctly aligned, it does generally mean that interrupts have to be disabled for a longer time (when programming in program Flash). And of course it can't alway be used if the aligment and size are unsuitable for the write in question.

I did initially cringe at the

FTFE_FSTAT |= 0x70;

but I do often see such expressions (also a lot in Freescale code) where the OR is obviously redundant (or in some cases even potentially dangerous).

Only now that I have heard it to be the actual reason for difficulties have I realised that the second Flash operation (not the first) will have the 0x80 flag set (indicating that the previous command has completed) and so clearing previous errors also initiates the next command too early....

Regards

Mark

Kinetis: µTasker Kinetis support

K64: µTasker Kinetis FRDM-K64F support  / µTasker Kinetis TWR-K64F120M support  / µTasker Kinetis TWR-K65F180M support

For the complete "out-of-the-box" Kinetis experience and faster time to market

[Jorge_Gonzalez]

Hello Mark:

Thank you for your comments. I found the cause but had not yet come up with an explanation. You are absolutely right, the OR operation was triggering the Flash command earlier than expected. But actually this would happen from the first Flash operation, since the CCIF flag is 1 after the reset sequence:

When running Stephen's code, I was even getting the MGSTAT0 error, because the command was launched early with invalid values in the FCCOB registers.

About Freescale code, I have to agree, we must pay attention to this kind of details. Software needs to be developed with hardware implications on mind.

For this particular case, that bit write is hidden within the compiler's generated code, so Stephen would've need to be somehow "compiling" the code while writing it, which requires some experience.

Regards!

Jorge Gonzalez

[mjbcswitzerland]

Stephen

I took a quick look but am not sure whether you are confusing FlexNMV with data/program Flash. 0xa000 is in data/program flash but you look to be writing code partly for this and partly for FlexNVM.

Attached is the flashing interface from the uTasker project (allowing all operations in data or FlexNMV or program once areas) on all K,KL,KV and KE parts. It runs also in the uTasker Kinetis simulator where these operations can all be tested (the simulator will give indications of any incorrect usage). You may get some ideas from it.

Generally there are quite a number of threads discussing this topic so there is plenty of such code around - eg. Re: Serial number programming in production - Kinetis K10

The code running in flash is normally only about 12 bytes in size and it is easier to just copy it there when needed rather than get the linker involved.

Regards

Mark

Kinetis: µTasker Kinetis support

K64: µTasker Kinetis FRDM-K64F support  / µTasker Kinetis TWR-K64F120M support  / µTasker Kinetis TWR-K65F180M support

For the complete "out-of-the-box" Kinetis experience and faster time to market

[stephenspaceman]

Hi Mark,

Thanks for the reply.  Why does it look like I am confusing FlexNVM with the data/Program Flash?  If something looks confusing to you it is very possible that I am doing something wrong.

I am only trying to access the program flash.

I will take a look at the uTasker project.

Stephen

[mjbcswitzerland]

Stephen

When writing to program/data flash on the K64 each phrase (8 bytes) is written together with the command sequence.

I saw that you were setting data to the FlexNVM RAM buffer, which is not involved in the process.

If you program one of the demo binaries from the K64 links below you can also play with the Flash interface. Depending on which application is installed the command line interface (shell) appears on the UART, Telnet or USB-CDC and has an I/O sub-menu with the commands:

 Input/Output menu
===================
up             go to main menu
md             Memory Display [address] [<l>|<w>|<b>] [num]
mm             Memory Modify [address] [<l>|<w>|<b>] [val]
mf             Memory Fill [address] [<l>|<w>|<b>] [val] [num]
sd             Storage Display {as md}
sm             Storage Modify {as mm}
sf             Storage Fill {as mf}
se             Storage Erase [address] [len-hex]
set_ddr        Set port type [1..4] [<i>|<o>
get_ddr        Get data direction [1..4]
read_port      Read port input [1..4]
write_port     Set port output [1..4] [0/1]
save           Save port setting as default
help           Display menu specific help
quit           Leave command mode

The memory commands (md, mm, mf) are standard direct memory-mapped reads and writes so "md" can be used to read from the Flash but any attempted write will (of course) cause an exception.

If, however, the "storage" commands (sd, sm, sf, se) are used instead the operations pass through the appropriate Flash interface and so flash operations can be tested.

If FlexNVM in enabled in the project the FlexNVM will appear as linerally mapped memory, contiguous to the internal program/data Flash and so the same commands can also be ued to work with this area. In fact a "sf 7fff0 l 55 100" would (assuming the data flash ends at 0x7ffffff and there is some FlexNVM available) cause a data fill starting towards the end of the program flash and continuing to the FlexNVM data flash (although its physical memory is mapped elsewhere - and readable from the physical address with the "memory"versions - and twodifferent programming algorithms are actually used for the operations).

Furthermore, if there is additional serial based Flash in the system (various types are supported) this memory is also simple contiguously accessible in the "virtual" storage space meaning that applications don't need to be aware of what type of memory it actually is or where it is physicaly located.

This may at first glance not be spectacular in any way but it opens up capabilities without any programming effort by simply utilising the storage interface rather than the memory interface - for example the FreeMaster interface built into the uTasker project allows read monitoring and write modifcations in any memory (RAM, Flash, SPI Flash, FlexNVM etc.), whereas the standard FeeMaster interface is limited to only SRAM without major redesigns. File systems can also utilise multiple physical Flash types as if it were a single larger pool of memory.

Regards

Mark

Kinetis: µTasker Kinetis support

K64: µTasker Kinetis FRDM-K64F support  / µTasker Kinetis TWR-K64F120M support  / µTasker Kinetis TWR-K65F180M support

For the complete "out-of-the-box" Kinetis experience and faster time to market