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

[mark4th]

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 !!!!!!!!!!!!!!!!!!

[mark4th]

ty for the help mark, I have been fighting with this for a month.   while my overall project is based on existing code there is still a lot of work that i need to do here and after a month of fighting I have not even made it out the starting gate.  And... while it has been said that a poor workman always blames his tools I think I have cause to do so here.  I realize I have made mistakes but I have never worked with any tool that was THIS hard to work with. (try using the in circuit emulator for the 4 bit NEC 75x (i think only three of them were ever built).

However, i am not using mcuxpresso, I tried, its so heavily locked in to their god awful software destroying kit that it pretty much refuses to do anything with any project that does not make use of it and for my actual project the SDK has absolutely NO place. I have been using KDS.

With regard to the erasing of the vectors being part of my problem Im not buying that entirely, the SAME CODE which previously had no problems writing data to flash now does not write anything.  I almost never SAW any data being written to flash but if I quit out of KDS I could run a mem8 command on the memory I had written using the JLinkExe command that comes with the segger tool.

also, for the record, i almost never code for instruction efficiency other than code SIZE.  I think people who optimize down to the opcode level are one sandwich short of a picnic except in very very rare instances where it is absolutely required (yes, games programmers ARE one sandwich short of a picnic : )   I chose to do most of my development in pure assembler because i have never liked anything about the C programming language, it is extremely rare I ever write any of my own code in C.  I can develop much faster in assembler or.... MUCH faster using the forth systems I develop in assembler.

[mjbcswitzerland]

Hi

You could try with IAR - the Kickstart version (up to 32k code size) is free and its debugger is much more capable and easier to use than the one in MCUXpresso.

Regards

Mark

[kerryzhou]

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.
-------------------------------------------------------------------------------

[mark4th]

I do not use of the MCUXpresso SDK, All my code (100% of it) is pure assembler and does not use ANY header files from any SDK what so ever, I tried to use MCUXpresso to debug my code but all it does is refuse to work with me because "That is not an MCUXpresso project".

I could install it again, and install the SDK and run the hello workld but last time i looked even a simple project as this is populated with a HUGE pile of highly obfuscated C sources and header files.  The code generated by this SDK is HORRENDOUS.  I do not doubt that it 'works' but it is generic code designed to work on any processor and in that regard its ability to 'get it done' is good.

For my purposes, even reverse engineering the generated object code in order to discover how it does things would be utterly counter productive.  Looking at project B to see why project A does not work is not a good way of debugging code.

MCUXpresso is so tightly coupled to that SDK that it pretty much refuses to cooperate with anyone thats not using it.  I could not even get it to upload my already existing elf file to the target for a debug session, all it ever did was bitch about it not being derived from the SDK.

I do appreciate the help but I have utterly abandoned any attempts to use that IDE.  What I need to know is not 'what does that thing over there work' but 'why does this thing over here NOT work' lol.

 < edit > oopts forgot to mention, my target is the FRDM-K64F < /edit >

[mjbcswitzerland]

Hi

You could try with IAR - the Kickstart version (up to 32k code size) is free and its debugger is much more capable and easier to use than the one in MCUXpresso.

Regards

Mark

[mark4th]

looked at iar and it looks really nice except.... im developing in linux, all my tools are linux based.  will looksee if it will work under wine :smileyhappy:

[mark4th]

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!