K64 Programming Flash

How do you place code in a post? I tried the "code" block selection in the toolbar "<>" but it just garbles things up.

Let me explain my question. If someone can tell me how to post code that shows proper format -- I can then include it for clarity.

I have written my own flash programming routines in an attempt to understand the process.

I am using a K64 with NO FlexNVM

If I understand the documentation correctly, you can not execute code from the same flash block you are attempting to program. I read somewhere that code executing in RAM allows you to program and flash block without a collision error.

I believe the the code that needs to run from ram is code that actually read and writes to FTFE_FSTAT.

I wrote a small function that perform 2 functions based on an argument passed to it.

1. Read FTFE_FSTAT and check that CCIF is not zero which would indicate active flash operation in progress. Once set, clear any of the error flags from the last flash operation. Leave function with only CCIF set.

2. Enter with FTFE_FSTAT having only CCIF set. Perform FTFE_FSTAT = FTFE_FSTAT_CCIF_MASK; which should start the flash operation. Wait until FTFE_FSTAT - CCIF mis set indicating flash operation is complete. Return FTFE_FSTAT to return any errors that may have occurred.

I acquire 4 byte align space in RAM and copy the function above into that ram space. I assign a ram pointer to that RAM space cast to be my function. Now I can just call the function I described above from its ram image.

I have reserved 16 bytes a flash at address 0x410 to hold my MAC address. When I start, this address range contains all FF's.

I call my ram function and it return zero indicating a successful write .. BUT ... flash has NOT changed.

I set the Address to 0x414 which violates the 64 bit alignment requirement for phase programming as a test and get a return value indicating ACCERR error which is valid and also indicates my ram function is functioning properly.

This is the Function that is moved from flash into ram .. sorry for the formatting .

2. Click on the "Expand Toolbar" (...)3. Now click on the "More" drop-down an select "Syntax highlighter"4. Choose Language "C" and paste the code into the box.5. Close the box and continue with normal typing

I didn't see the problem with your code but this is how to do it (I stripped out just for phrase programming):

FTFL_FCCOB0 = FCMD_PROGRAM;// enter the command sequence FTFL_FCCOB1 =(unsignedchar)(((CAST_POINTER_ARITHMETIC)ptrWord)>>16);// set address in flash FTFL_FCCOB2 =(unsignedchar)(((CAST_POINTER_ARITHMETIC)ptrWord)>>8); FTFL_FCCOB3 =(unsignedchar)((CAST_POINTER_ARITHMETIC)ptrWord); FTFL_FCCOB7_4 =*ptr_ulWord++;// enter the long word to be programmed FTFL_FCCOBB_8 =*ptr_ulWord;// enter the second long word to be programmeduDisable_Interrupt();// protect this region from interruptsfnRAM_code((volatileunsignedchar*)FLASH_STATUS_REGISTER);// execute the command from SRAMuEnable_Interrupt();// safe to accept interrupts againreturn(FTFL_FSTAT &(FTFL_STAT_ACCERR | FTFL_STAT_FPVIOL | FTFL_STAT_MGSTAT0));// if there was an error this will be non-zero}

The only code that needs to be in RAM is this:

staticvoidfnFlashRoutineInRam(volatileunsignedchar*ptrFTFL_BLOCK){*ptrFTFL_BLOCK = FTFL_STAT_CCIF;// launch the command - this clears the FTFL_STAT_CCIF flag (register is FTFL_FSTAT)while((*ptrFTFL_BLOCK & FTFL_STAT_CCIF)==0){}// wait for the command to terminate}

Attached is the uTasker flash driver which is compatible with long-word and phrase programing of KE, KEA, KL, KV, KM and K parts, including PROGRAM ONCE (useful for MAC addresses that are programmed once and can't be erased), Flash swap (for K64 for example), FlexData, section programming option and soem other stuff (fail-safe parameter system and mixing external and internal Flash programming into a virtual linear address space).

A simple method to learn Flash programming is to type in these sequences in the debugger (directly accessing the Flash registers and monitoring the memory content). Once you are familiar with the actual writes to do (and possibly ones to avoid) you can then implement in code in the same sequence.

If you want to speed up your learning and progress you can simply download the uTasker project and use its Kinetis simulator (which also emulates all Flash operations) so that you can see how it works and either directly use the solutions (that have been in operation for a number of years in many varied industrial products based on various Kinetis processors) or copy them to build your own library.

Unless the area in Flash is protected (which would give an error back) I don't know of any reason why this block should not be programmed. Do you have the same issue with other addresses in the first Flash plane or is it restricted to this particular address?

What I have just done is test on a FRDM-K64F board, whereby I have attached the binary if you would like to repeat on your board (assuming you have this one - tell me in case you have a different board since it can be built for any one or any Kinetis part). I left a small amount of empty flash space before and after the flash config and tried programming these and didn't have any problem.

To repeat with the attached binary:- load using the mbed loader (drag-and-drop)- press restet button so it starts- set the terminal emulator on the OpenSD interface to 115200 Baud 8 bit, no parity and hit enter screen to get a menu (terminal emulator connected to the VCOM)- Enter 3 to move to the I/O menu which allows viewing and modifying all memory- Enter "md 3e0 b 80 to see the original content (memory display of 80 bytes from 0x3e0)- Command the write of a pattern just before with "sf 3f0 l 12345678 2" (storage fill of 2 long words of 12345678 from address 0x3f0 - this will choose the Flash programming algorithm to suit the area and write 8 bytes (phrase for the K64))- Check that it has been modified using "md 3e0 b 80"- Command another change just after the Flash config "sf 410 l 87654321 2" and again check that it worked

This confirms that in this case (on my board and with the standard algorithms) there should be no problem with writing memory locations around the Flash config area as long as they were 0xffffffff beforehand.

You always need to question what debugging tools are doing/showing you - always keep a healthy mistrust relationship and double check when in doubt with a second or third tool.

I always have internal code that can double-check things (like in the menu I used) and simulate to cross-check expected with unexpected (possibly compiler or tool influenced) occurances to avoid unnecessary loss of time when developing.