Kinetis MicrocontrollersのトピックRe: How do you write to flash on a K64f? What am I doing wrong?

How do you write to flash on a K64f? What am I doing wrong?

mark4th — Sat, 02 Nov 2019 20:21:28 GMT

I have read the documentation over and over and over and over and over. I have looked at other peoples code to write to flash, none of which is suitable for my purposes (all C code and there is zero C code in my project) so I am implementing it myself in assembler. I do not know what I am doing wrong but for every attempt to write or erase flash I get ACCERR.

I will never use processor expert because this is one size fits all code and is HORRENDOUS. It is also an impediment to understanding. i do not ever click a "do this for me" easy button.

The ONLY initialization I do for the processor is to disable interrupts and the watchdog timer. i have not attempted to modify clocks in any way. I would be slightly annoyed if flash write access can only be done after some clock initialization because there is absolutely nothing what so ever that I can find in the documentation that suggests this is the case and as stated before, ive been over that documentation multiple times.

Both of the following functions result in ACCERR. The call to ftfe_wait (not posted) initializes r7 to x040020000. I have also tried to write each byte of the FCCOB registers individually with no change in the end result. flash not modified and ACCERR.

ftfe_erase:
str lr, [sp, #-4‌]!

bl ftfe_wait @ wait for previous command complete

movs r0, #0x09 @ erase sector from address 0x000000
str r0, [r7, FCCOB]
movs r0, #CCIF @ run the command
strb r0, [r7, #FTFE_FSTAT]

ldr pc, [sp], #4

ftfe_prog:
str lr, [sp, #-4]!
bl ftfe_wait              @ wait for previous command complete

mov r0, r5                @ r5 = destination address

lsl r0, r0, #8            @ shift addres up 8 bits to make room for...
adds r0, r0, #7           @ program phrase
str r0, [r7, FCCOB]

ldr r0, [r9], #4
str r0, [r7, FCCOB + 4]
ldr r0, [r9], #4
str r0, [r7, FCCOB + 8]

movs r0, #CCIF            @ run the command
strb r0, [r7, #FTFE_FSTAT]

ldr pc, [sp], #4

P.S. these forums seem to be constructed in such a way as to make it as CLOSE to impossible for anyone to get any kind of help I have NEVER seen any other forums that are this FREEEKING obfuscated to use. WHERE IS THE FORUM FOR THE K64F !!!!!!!!!!!!!!!!!!

Re: How do you write to flash on a K64f? What am I doing wrong?

mjbcswitzerland — Mon, 04 Nov 2019 21:48:33 GMT

You are writing the command/address in the wrong order.

For example, when erasing the first sector at 0x000000

it is not

movs r0, #0x09

but

movs r0, #0x09000000

Regards

Mark

Re: How do you write to flash on a K64f? What am I doing wrong?

mark4th — Mon, 04 Nov 2019 23:48:46 GMT

Ok my errors are all gone! yay!

but nothing gets erased, nothing gets programmed

im using a jlink edu to debug within KDS and have a memory window on 0x400 as i single step through the code.

If i try press F6 on my write_stuff_to_flash: function the debug session goes out to lunch. ALL memory addresses show as zero, all registers show as zero and the disassembly shows at address -1 press the red square to abort deubg is TOTALLY not helpful.. is there a way to simply HALT the processor ?

Re: How do you write to flash on a K64f? What am I doing wrong?

mark4th — Tue, 05 Nov 2019 00:06:26 GMT

update, had a slight oopts in my flash write code which is now fixed and the data is absolutely being written to flash.

i verified this using JLinkExe, connecting to the target and doing a mem8 dump on addres 0x0400 for 256 bytes... my data is there.

however, as i am single stepping through the code doing the actual writing the memory display of the data at 0x0400 never changes from 0xff ff ff ff ff.....

and as stated before, if i press F6 when the program counter points at my flash_write function to execute the entire function in one go rather than single stepping every opcode therein the debug session goes totally out to lunch,

I can even set a breakpoint and click the RUN button, the breakpoint is never hit.

Re: How do you write to flash on a K64f? What am I doing wrong?

mjbcswitzerland — Tue, 05 Nov 2019 01:24:19 GMT

When programming in the same block of flash as the code is running in you need to execute the code from RAM instead.
Therefore you need to copy your code (in Flash) that is doing the flashing work into RAM (and create a Thumb call to it) and jump to it. Also you must ensure interrupts are blocked (unless all code that can be run as interrupts - including vector table - are in RAM).

If this is not done it may work when single stepping since the Flash command is executed when the processor is stopped (and not needing to access Flash while the operation is still in progress) but it will fail if run normally. The flash is not available to the processor when it is being operated o and any attempt to access it by the processor causes a serious and non-recoverable fault....

To be exact, you just need to execute just the part that commands the operation and waits for its termination (which you are presently missing) from RAM. Below is (assembler) code that does it, as reference:

static unsigned short fnFlashRoutine[] = {                               // to avoid potential compiler in-lining of the routine (removing position independency) the machine code is used directly
    0x2180,    // MOVS r1,#0x80 load the value 0x80 (command complete interrupt flag) to register r1
    0x7001,    // STRB r1,[r0,#0x00] write r1 (0x80) to the passed pointer location (r0)
    0x7801,    // LDRB r1,[r0,#0x00] read back from the same location to r1
    0x0609,    // LSLS r1,r1,#24 shift the register content by 24 bits to the left so that the command complete interrupt flag is at bit 31
    0xd5fc,    // BPL -4 if the command complete interrupt flag bit is '0' (register content is not negative value) branch back to read its value again
    0x4770     // BX lr return from sub-routine
};
‍‍‍‍‍‍‍‍

which is called with

fnFlashRoutine((volatile unsigned char *)FLASH_STATUS_REGISTER); // execute the command in flash

That is, with a pointer to the Flash status register in r0.

Regards

Mark

Re: How do you write to flash on a K64f? What am I doing wrong?

mark4th — Tue, 05 Nov 2019 02:09:56 GMT

the part of the code doing the writing to flash is running from ram and writing data that is in ram into flash, the interrupts are also disabled and so is the wdt. I can verify that the writes DO take place. I just can not debug the overall project other other than single stepping the code that does the flash write - anywhere else, if there is a bl foo i can press F6 and run the entire foo function and break on the next opcode. do that for any of the flash functions in ram and the debug session gets utterly lost in space, totally out to lunch.

Also, single stepping the flash writes/erases does not show any changes in the memory display window. I can not see ANY changes what so ever to flash within the debugger but exeting back to shell and running JLinkExe i can do a memory dunp and the data is shown to have been written correctly.

I have not tried to just RUN the code and to hell with debugging it to check through JLinkExe if the complete flash write is successfull or not but if it is that is literally 1/10000000000 of what i need to debug. i need to debug what happens AFTER the flash is written too and single stepping through 8k of flash writes 8 bytes at a time would be a nightmare,

Re: How do you write to flash on a K64f? What am I doing wrong?

mjbcswitzerland — Tue, 05 Nov 2019 12:00:34 GMT

If the flashing code is running form SRAM there should be no problems but what doesn't look correct in your code is that you check for the flash being busy "before" starting the new command but you don't wait until the new command has completed "before returning". If you return to Flash based code before the flash operation has completed it will immediately crash (the flashing operations can take several us to several ms to complete) - make sure also the wait code is in the SRAM and you don't return until the operation has terminated.

How the debugger displays flash content depends on how it is updating its window - to be sure one can command an update/refresh after modifying flash content so that it is synchronised.

Also, the K64 is probably using caching and so reading the Flash may return old cached values, meaning that the debugger has not seen that the content has changed because also the cache doesn't yet know that content has been modified. This can be overcome by invalidating the cache after each flash operation by writing the "invalidation flags" to FMC_PFB0CR (and FMC_PFB1CR if present).

Regards

Mark

Re: How do you write to flash on a K64f? What am I doing wrong?

mark4th — Tue, 05 Nov 2019 17:10:44 GMT

First of all I would like to personally thank you for the help you have given, VERY much appreciated!

secondly... :smileyhappy:

All of the changes you suggested were already made last night but there are still some funky issues (see below sources).

Im pasting the complete sources for this here not just snippets in case it is useful for others in the future.

This code is included as a binary into a loader project which is very specific to my use case (so you make your own : ) which makes calls into this code via two pointers at the start of this code. see sources

p.s. i know im only erasing 4k when my data is 16k ish ... this will be easy to fix :smileyhappy:

@ ramflash.s - functions to write flash data running from ram
@ ------------------------------------------------------------------------

@ ------------------------------------------------------------------------
@ the entire contents of this file are moved to ram. the only part that
@ actually needs to be in ram though is the ftfe_wait function
@ ------------------------------------------------------------------------

@ after assembly the .text section for this file is extracted to a
@ binary and then included into the loader build - at run time loader
@ will relocate this into its ram run-time address and make calls into it

@ ------------------------------------------------------------------------

.set FMC, 0x4001f000
.set PFB0CR, 4

.set FTFE, 0x40020000

.set FTFE_FSTAT, 0x00 @ flash status register

.set CCIF,        0x80      @ command complete interrupt
.set RDCOLERR,    0x40      @ FTFE Read collision error
.set ACCERR,      0x20      @ Flash access error
.set FPVOIL,      0x10      @ Flash protection violation
.set MGSTAT0,     0x01      @ Memory controller command complete status

.set FTFE_FCNFG, 0x01 @ flash configuration register

.set CCIE,        0x80      @ command complete interrupt enable
.set RDCOLLIE,    0x40      @ read collision error interrupt enable
.set ERASAREQ,    0x20      @ erase all request
.set ERSSUSP,     0x10      @ erase suspend
.set SWAP,        0x08      @ swap
.set PFLSH,       0x04      @ FTFE configuration
.set RAMRDY,      0x02      @ ram ready
.set EERDY,       0x01      @ ee ready

.set FTFE_SEC, 0x02 @ flash security

.set KEYEN,       0xC0      @ backdoor key security enable
.set MEEN,        0x30      @ mass erase enable
.set FSLACC,      0x0c      @ freescale failure analysis code
.set SEC,         0x03      @ flash securithy

.set FTFE_FOPT, 0x03 @ flash option register

.set FCCOB, 0x04 @ flash common command object register

@ ------------------------------------------------------------------------

.syntax unified
.thumb

.section .ramcode, "awx" @ defined in the linker script

@ ------------------------------------------------------------------------
@ first two ints are pointers to the two functions that loader will call

.int ftfe_prog @ write to flash
.int ftfe_erase @ erase flash

@ ------------------------------------------------------------------------

@ start execution of command
@ wait for ftfe command to complete.
@ invalidate cache (err... i think?)

ftfe_wait:
movs r0, #CCIF @ run the command
strb r0, [r7, #FTFE_FSTAT]

0:
ldrb r6, [r7, #FTFE_FSTAT]
ands r6, r6, CCIF
beq 0b @ wait for command to complete

@ if only the GNU assembler allowed me to construct a MASK from a set of
@ BIT NAMES without i need to make use of the horrendous abomination of
@ a C pre-processor I would not have to have magic numbers. As soon as
@ this project is complete i can throw every single GNU development tool
@ in the trash where it belongs (at least for this target)

movs r6, #0x70 @ clear error status
strb r6, [r7, #FTFE_FSTAT] @ bad mojo to ignore potential erros

movw r0, #:lower16:FMC    @ invalidate the cache (i think ?)
movt r0, #:upper16:FMC
movs r1, #0x00f80000      @ funny thing is, as soon as i added this bit
ldr r2, [r0, PFB0CR]      @ of code it was no longer needed. the flash
orr r2, r2, r1            @ writes became instantly visible in the
str r1, [r0, PFB0CR]      @ debugger before i invalidate %&*U&#!

bx lr

@ ------------------------------------------------------------------------
@ program 8 bytes from address pointed to by r5 to address r9

ftfe_prog:
str lr, [sp, #-4]!

movw r7, #:lower16:FTFE @ also returns f7 = FTFE base
movt r7, #:upper16:FTFE

mov r0, r5 @ r5 = destination address
add r0, r0, #0x07000000
str r0, [r7, FCCOB]

ldr r0, [r9], #4
str r0, [r7, FCCOB + 4]
ldr r0, [r9], #4
str r0, [r7, FCCOB + 8]

bl ftfe_wait @ run command

ldr pc, [sp], #4 @ oooh i could do a tail call optimization !!

@ ------------------------------------------------------------------------

ftfe_erase:
str lr, [sp, #-4]!

movw r7, #:lower16:FTFE @ also returns f7 = FTFE base
movt r7, #:upper16:FTFE

movs r0, 0x09000000 @ erase sector 000000
str r0, [r7, FCCOB]

bl ftfe_wait

ldr pc, [sp], #4

// =======================================================================

There are still some funky things going on however because the ONLY way this code currently works is if i single step through all 16k of data being flashed... one opcode at a time *$^&($&!

If I execute these functions at full speed (pressing go or pressing f6) my entire debug session goes lost in space. The same thing happens if i flash it then run it full tilt boogie from JLinkExe (set program counter and run).

Im thinking it must be getting stuck waiting on CCIF somehow?

Re: How do you write to flash on a K64f? What am I doing wrong?

mjbcswitzerland — Tue, 05 Nov 2019 19:21:10 GMT

If you post a binary of your code that runs on a FRDM-K64F (if you use default clocking it will run on any board) I will be able to tell you what the problem is.
You will need to tell me the location of the routine ftfe_wait or the flash location of whatever code that calls the operation in question.

Regards

Mark

Re: How do you write to flash on a K64f? What am I doing wrong?

mark4th — Wed, 06 Nov 2019 14:36:58 GMT

was going to put that together after I got home from work but crashed lol. ill see if i have the energy to do this tonight :smileyhappy:
tyvm!

Re: How do you write to flash on a K64f? What am I doing wrong?

mark4th — Fri, 08 Nov 2019 07:17:11 GMT

I have a zip file with code that you can either build or use the pre-built binaries (elf) but my experience with debugging this code has made things far far far more frustrating. i try single step the first few opcodes an d BOOM reset, out to lunch. I try run then full speed and BOOM reset, out to lunch.

I comment them out and my flash erase still works but NOTHING is being written to flash any more. Switched back to the actual project this is based on and im again having horrendous issues trying to debug the code. Cant have the code to disable the WDT because that hozes the debug. Erase works great but the damned programming is now failing here too.

why is this so damned difficult, i have NEVER in 30 years of embedded software had the problems im having with these horrendous development tools. WHY would anyone want to use ANYTHING based off of eclipse and why would anyone with a conscience push such a tool on society :smileysad:

I have no idea what the hell is going on here, code i could run full speed over but not single step i cant do either with and its EXACTLY THE SAME OPCODES!!!

Where do i post my zip file ?

Re: How do you write to flash on a K64f? What am I doing wrong?

mjbcswitzerland — Fri, 08 Nov 2019 18:41:43 GMT

Please post a binary (not elf) together with the map file. I prefer not to build since often it may take hours to get a foreign project to build on a different system (due to paths and other unexpected things).

To post, do the following:

1. Activate the "Use advanced editor" option (top right of edit box)
2. Then you will see an "attach" menu where you can select your local files(s)

Regards

Mark

Re: How do you write to flash on a K64f? What am I doing wrong?

mark4th — Sat, 09 Nov 2019 21:52:03 GMT

loader.bin and .map as requested.

I cant tell now if my troubles are the jlink edu, the target or my own incompetence :/

Re: How do you write to flash on a K64f? What am I doing wrong?

mjbcswitzerland — Mon, 11 Nov 2019 02:21:16 GMT

1. The bin file doesn't match the map file - it is much too small. Post the .elf instead so that I can convert it to a bin file.

2. You have no flash configuration in your project. You should have 16 bytes at 0x400 to configure the security and other options. Your m_foo should start at 0x410 instead since it would otherwise give a random flash configuration which could, in the worst case, brick the processor forever.

Regards

Mark

Re: How do you write to flash on a K64f? What am I doing wrong?

mark4th — Mon, 11 Nov 2019 14:36:18 GMT

Sorry, when you asked for a bin file only i assumed you wanted only the .text section and thats what I posted, if you load that in at 0x8000 and set the program counter to 0x8000 that would give you my setup almost identically (other than you would need a sane flash config field of course : )

Anyway, see attached elf as requested, and again, tyvm, im going nuts here :smileyhappy:

Re: How do you write to flash on a K64f? What am I doing wrong?

mjbcswitzerland — Mon, 11 Nov 2019 19:05:04 GMT

I tried generating the complete content from the .elf but it seems like there is nothing more than the .text section in the .elf as well.

So I added a reset vector and flash config and loaded the code to 0x8000, starting with PC set to 0x8000.

However this code cannot operate since it uses un-initialised registers and so crashes after a few instructions and doesn't get as far as trying to work with flashing code.

The code that I see is (with my comments):

LDR R2, [R4, #0x4] // load R2 with unitialise R4 (assume 0) + 4, which is the initial program counter if this were the reset vector in Flash - assume loads 0x8000.
LDR R3, [SP, 0x10] // load R3 with Spack pointer + 0x10. Value of SP is unknown and SRAM hasn't been initialied so the value in R3 is random (assume SP is at top of SRAM 0x20003000)
CMP R2, R3 // compare the initial program address with random value
BEQ.N 0x8016 // possibly initialisation that allows flash or SRAM based initialisation
MOVS R3, #16
STRB.W R3, [R4, 0x22] // store the random value in R3 to a flash address (PC + 0x22) - always provokes crash

I expect that the entry point is not 0x8000 but somewhere else, whereby I find _start [0x80dc] in the map.

After trying this as entry point I also find code that uses random pointers and so crashes after a few instructions.

Do you have any more information about what needs to be done to allow the code to be used (eg. priming RAM or SP - which is the actual entry point?) or is there missing code?

It may be easiest in this case to post the complete project so nothing is missing.

Regards

Mark

Re: How do you write to flash on a K64f? What am I doing wrong?

mark4th — Mon, 11 Nov 2019 19:21:02 GMT

ok, now im very confused, the code you have at 0x8000 is not whats supposed to be there, do you have the debuggerr set to expect ARM object code or thumb2? the code is all thumb2

0x8000 should start wtih....

cpsid i
movw r1, #0x2000 @ *** get rid of magic numbers
movt r1, #0x4005
movw r0, 0xc520 @ disable watchdog timer
strh r0, [r1, #14]
movw r0, 0xd928
strh r0, [r2, #14]
movw r0, #0x1d2
strh r0, [r2]
b _start

or something very similar, i think i have done edits on that code since I sent it to you and this is what i have now.

edit: just verified the elf I sent you by doing "arm-linux-eabi-objdum -D loader" and scrolling to the disassembly of 0x8000, I think you are interpreting thumb2 object code as though it were 32 bit arm code... (just a guess, not sure why your tools would do this though)

edi2: attached zip with project sources and linker script and makefile

Re: How do you write to flash on a K64f? What am I doing wrong?

mjbcswitzerland — Mon, 11 Nov 2019 23:48:49 GMT

I took a look and see various problems with the project that need to be solved to make it easily testable.
1. Concerning your watchdog unlock difficulties please read the start of page 34 of http://www.utasker.com/docs/KINETIS/uTaskerV1.4_Kinetis_demo.pdf
2. I get no main() in the binary and I think it is because your reset vector and flash parameters are being optimised out by the linker since they are not referenced by any other code. You need to ensure they are not optimised away by using the KEEP attribute. Eg.

.vectors ALIGN(__Vector_segment_start__ , 4) :
{
__vector_table = .;
KEEP(*(.vectors .vectors.*))
}

This also explains why I don't have the code that you expect to be the first to run.

3. I don't think you are putting the flash config anywhere so you need to ensure that they are in a similar sector at 0x400 that is not optimised out
4. I get no main code in the binary and that is why I can't start testing anything. If you solve the vector table being in the code it will also solve main being optimised out (since this will be referenced by the vector table).
5. As far as I see you need to load both code to the flash and also load code to SRAM so that the ram code can operate. This is possible using the debugger but is impractical for general testing and can't operate in a real situation. You need to put the RAM code into the source and then copy it to the SRAM location during run time for the main program.

Presently I can't actually test any operation.

Regards

Mark

Re: How do you write to flash on a K64f? What am I doing wrong?

mark4th — Wed, 13 Nov 2019 05:35:20 GMT

the problem is NOT that there are sections missing, i have a .vectors section and my flash config field IS at address 0x400. The problem i believe is the crippled development tools I am forced to use. My elf file contains a .text section with a load address of 0x400. At this address is the flash config field. This is followed by a bunch of 0xff bytes all the way up till 0x8000 where my actual code starts. Following the .text section within the elf file is the .vectors section with a load address of 0x00. (out of order linking!)

Problem is these asinine tools REFUSE to backtrack in memory and burn .vectors AFTER .text has already been flashed so... .vectors is simply discarded silently.

I have attached a new loader elf file with NO .vectors section but a .text section that starts at 0x00.

I would ask here for an NXP representative to explain to me exactly why their tools refuse to flash out of order elf sections when NOBODY has ANY CONTROL what so ever over the LINK ORDER of any section but I doubt any representatives from NXP ever bother to chime in here when they have someone as helpful as you doing all their work for them for free :smileysad:

Re: How do you write to flash on a K64f? What am I doing wrong?

kerryzhou — Wed, 13 Nov 2019 07:50:02 GMT

Hi Mark Manning,

So you meet the flash operation problem in the K64 chip?

What's the detail K64 part number you are using now? Do you have tried the official SDK flash project which can be downloaded from this link:

Welcome | MCUXpresso SDK Builder

I suggest you try the official SDK project at first, I don't recommend you use the PE tool, as I know, the PE tool won't updated in the future.

Have a great day,
Kerry

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------