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

[mjbcswitzerland]

Hi

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

[mark4th]

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 ?

[mark4th]

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.

[mjbcswitzerland]

Hi

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

[mark4th]

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,

[mjbcswitzerland]

Hi

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

[mark4th]

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?

[mjbcswitzerland]

Hi

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

[mark4th]

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 ?

[mjbcswitzerland]

Hi

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

[mark4th]

loader.bin and .map as requested. 

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

[mjbcswitzerland]

Hi

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

[mark4th]

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:

[mjbcswitzerland]

Hi

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

[mark4th]

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

[mjbcswitzerland]

Hi

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

[mark4th]

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:

[mjbcswitzerland]

Hi

The new version could be loaded and I have some results.

1. The wait routine works correctly - I can see that it "does" wait until the command has completed before returning (that is, it does spin in the loop and doesn't return too early)
2. Although I never saw this before I think that the problem has something to do with the pipeline operation of the processor whereby it is executing the flash programming at the same time as it is filling its instruction pipeline from Flash. This means that while it is executing your instructions in SRAM (correct) the processor is still fetching further instructions (speculation) from the original code flow before the jump. It fails to be able to access the flash once you have started the operation and everything freezes.
If you put a break-point on your call to the SRAM code (BLX R0) and let it run it will be fine. If you however put a break-point a little before here and let it run it will fail. Also if you step the code everything is fine because stepping is way slower than the pipeline operation.

To prove this you can do a few things:
A. Put a few dummy instructions at the start of you RAM code so that the pipeline recognises that there has been a change in program flow and stops loading program code from the original path.
B. Disable the speculation operation using

    FMC_PFB0CR &= ~(BANK_DPE | BANKIPE);                                 // disable speculation logic
    FMC_PFB1CR &= ~(BANK_DPE | BANKIPE);
you could also disable cache with
    FMC_PFB0CR &= ~(BANKDCE | BANKICE | BANKSEBE);                       // disable cache
    FMC_PFB1CR &= ~(BANKDCE | BANKICE | BANKSEBE);

but I don't think it has anything to do with caching.

C. Add memory boundary instructions at the start of your wait routine - reference http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dai0321a/BIHJDAAE.html

which tend to be used a lot in assembler code to control such things.

I can't prove this since I can't change the code but I am confident that you will be able to solve it with one of the techniques above.

Regards

Mark

[mark4th]

I have not yet tried to disable the speculative fetches but I do have an update. 

Previously my elf file had all the sections linked out of order.  I would get a blank, unassigned space of 1k of zeros immediately after the elf section/program headers.  This space was not assigned to any section within the elf, it was simply a 1k of padding which I assumed was allocated for the .vectors section which is exactly 1k in size but which for some reason was never put there.  for reasons that will be apparent shortly i no longer think this blank space was intended for .vectors at all and I am at a complete loss as to why it is being injected into my target elf file.

Because the elf sections were linked out of order the debug tool would refuse to burn any section lower down in flash memory than it had already burned so I would never get my .vectors section being flashed.  My fcf was included in my .text section but i have moved it out to its own section as the fcf is not really executable so should not be flagged +x.

Anyway, to recap, my elf file previously looked like this  [elf headers][1k blank space][.text][.vetors]... .. .

I now have [elf headers][64k blank space][.vectors][.fcf][.text]... ...

As you see, my sections are now in the order specified in the SECTIONS command of  my linker script but now, instead of one k of blank, unassigned, utterly pointless space i have SIXTY-FOUR K of utterly pointless zero padding immediately following my elf program/section headers. 

This means that I am now able to load my elf file and see .vectors populated, the flash config field populated and .text populated.  However, I am still observing the same failure mode.  I can not run this code in any way other than to single step it. 

I will try disabling the speculative fetches shortly and will post an update but this is HIGHLY frustrating, I see no other project that needs to do this, why would I need to?  Im not holding my breath that this will solve the problem because I did put memory barriers at the start of my ram function (ALL three!) but it is worth a shot.  it is however an utterly unacceptable solution as it will impact on the performance of the end product but it might provide some clues if it does duct tape the issue.

< edit >

Unless I am doing it wrong, disabling speculative fetches does not affect any change what so ever.  Run  my code at full speed and it gets lost in space. Single step it and it executes each opcode in the expected order..  However while my flash erase works just fine still my flash write is utterly failing to write anything what so ever to the flash now.

Now I am noticing that for one breakpoint that is added to my code by the debug configuration that the program counter no longer stops ON the opcode with the breakpoint but rather stops 4 opcoes later.  Am i suddenly debugging on a god aweful PIC microcontroller now and need to implement skid buckets all over the place?

seriously is this the standard of tooling with NXP?

Debug does not allow me to set the Font for the register display but allows me to set it for everything else

debug automatically assumes that its going to be for C code when there is NEVER ANY C CODE IN MY PROJECTS... ****EVER****

It very kindly TURNS OFF "single stepping opcodes" every new debug session.

The debug sessions CONSTANTLY reset for no reason what so ever and if you forget to hit that damned "single step opcodes" selection you just screwed yourself.  or rather NXP did it for you.

Someone from NXP please chime in any time, what the HELL is wrong with my flash write code - previously I could write to flash reliably as long as i single stepped the code to do it.  Run it full speed and BOOM out to lunch.  Now... single stepping does not go out to lunch but not one damned byte is written to flash.... NOT ONE!!!!!!!!!!!!!!

I can erase sectors just fine but now the SAME FREEEKING CODE that worked as long as i single stepped is failing to write to flash.

I can not even begin to express how god damned frustrated I am with this entire experience.  I have NEVER in thirty years of embedded development had the issues with debugging as I am with these horrendously COUNTER PRODUCTIVE tools.   NOTHING ever works the same way two times in a row!!

Load code (worked)

Set breakpoint (worked)

run  to breakpoint (worked)

set new breakpoint (worked)

run to new breakpoint (OUT TO LUNCH!!!!!!!!!!!!!!!!!)

no way to reset the damned target so... REPROGRAM THE TARGET

set brekpoint (worked)

run to breakpoint (OUT TO LUNCH!!!!!!!!!!!!!!!!!!!!!!!)

No I will NEVER use your xpresso garbage, that is so tightly coupled to your HORRENDOUSLY OBFUSCATED SDK, not if you paid me a billion dollars.  I HAVE a project that I have gotten working on a raspberry pi, a beagleboard xm, a beaglebone black, a cubie board, which I have successfully ported to AVR32 and others. NO PROBLEMS PORTING!!! debugging on these is a DREAM!!!

Your tools are the most horrendously counter productive garbage I have ever used and your fobbing help off on the "community" tells me you dont give a damn so... why would I or anyone else ever use ANY of your products.  UTTER GARBAGE to debug because nothing works the same way twice in a row!!!!!!!

To the very helpful people who did put their time in on my issues to help me I am very appreciative but the frustration upon frustration upon frustration that developing for this target is causing me I do not think im going to bother.  Ill just throw the target in the trash where it belongs.

NXP doesnt give a **** so why the hell would I.

[mjbcswitzerland]

Hi

I noticed that when I tested your code you erase the first sector of Flash and then write a pattern to it (starting at 0x400). Since the erase deleted the reset vector it can only run once and then the code needs to be reloaded again (without the reset vector, the processor can't start).

If you don't yet have proven flash code it is advisory to do tests in a different sector (preferably in the second flash block) because that would remove strange things due to boot-up code and it also allows the program to run in the first flash block whilst the second flash block is being processed. If that works you can then move the sector into an unused area in the first block (where the RAM code execution now becomes imperative) and finally, when others have been proven, to the final location.

Based on which variation(s) work(s) and which one(s) cause strange effects it may be possible to deduce better the cause of difficulty.

Note also that instruction efficiency is not of great importance in the flashing code since flash operations themselves are very long in comparison - adding a few NOPS and such is insignificant in the routine's overall execution time.

Regards

Mark