K70: Cannot write to flash (timing issue?)

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

K70: Cannot write to flash (timing issue?)

Jump to solution
1,980 Views
martinpi
Contributor III

Hello everyone!

I am in progress of switching from a K60 Tower to a K70 "homebueilt" PCB.

With the K70, I have problems writing to the internal flash.

The K60 is a K60FN 120MHz and the K70 is a K70FX 150MHz.

The first problem occured when I tried to run a "hello - world" - program (a bareboard project, gnerated by Codewarrior 10.2) in flash raher than in RAM.

It seemed to start normally (when I set the debugger to start at the program entry point rather than running to main() ).

But, unlike the K60, the program flash was not programmed and shows all FF's and therefore the program doesn't run.

This is a problem which others have reported as well, and so far no solution (any help welcome!).

Next, I tried to port my flash programming routines from the K60 (where they run flawlessly) to the K70, still executing out of RAM under the CW debugger.

I do not touch the upper parts of memory so I am sure I do not get in conflict with FlexNVM.

On both platforms, I start from a "bareboard project" and leave all clock settings etc. on factory defaults.

The only necessary change, so far, was to disable the watchdog.

My flash programming routines write directly to the FTFE registers.

I know that the flash region I am witing to must be cleared before I may program them. So part of my routine is an "erase sector" command, then I verify with the "read all 1s" - command and also check with the debugger's memory browser if all bytes read FF.

I am careful to close the debugger's memory browser before continuing, as this might cause a read collision error.

I use the "phrase programming".

I wait for the CCIF bit in the FSTAT register to show a 1 and clear any errors by writing 0x30 to the FSTAT register. 

I write to the FCCOBx registers, and then I set FSTAT to 0x80.

In a loop I wait until the CCIF bit shows a 1 and check for errors.

When I single-step, the programming works.

When I let it run in a loop to program a number of bytes, let's say 128 bytes which means that I invoke phrase programming 16 times,

it usually works once or a few more times out of these 16 times.

After that, I see that the flash is not programmed, even though the FSTAT reads 0x80 again, i.e. completed and no errors.

Some earlier processor had a bug which let the CPU read a 1 in the CCIF bit even before programming started.

Could this happen with the K70?

Do I have an indication when I can continue programming, apart from the CCIF-bit?

As a workaround, I tried to add an additional loop which reads back the flash and compares it to the desired values, so I allow some time for the flash to get programmed. No success. Again, it may work when debugging and setting a breakpoint in that loop, but not when running "unatteded".

Any help is greatly welcome!

Regards, Martin

Labels (1)
0 Kudos
1 Solution
637 Views
martinpi
Contributor III

Looks as if I found a smoking gun.

In the errata of some older processor (tried to paste the URL but copy&paste doesn't work here) I found that under some rare circumstances I could read back the CCIF bit as "1", meaning that it has completed but it has not yet started. As a workaround, I inserted a loop which waits for CCIF=0 so I know that it has started and then go into my loop that waits for CCIF=1.

Of course I will need a timeout, because I might miss the moment when CCIF=0 due to an interrupt, and then I would wait forever.

Funny thing: Immediately after doing this doble-waiting-algorithm, I cannot read back the data which I have written. It needs some more time, don't know how long.

View solution in original post

0 Kudos
4 Replies
637 Views
Lupo
Contributor III

Hello,

same problem here with a KL03 using KDS v3.00 + KDSK 1.20 + flsl_flash component:

stepping manually through the instructions of the function FlashCommandSequence() in FlashCommandSequence.c the flash memory is correctly written or erased but when the program is normally running it will never exit from the following loop:

while(0x0U == (REG_BIT_GET(temp, FTFx_SSD_FSTAT_CCIF)))     /* wait till CCIF bit is set */

Is there some reliable and recommended solution other than modyfing this component?

Thanks for any answer, Michael

0 Kudos
638 Views
martinpi
Contributor III

Looks as if I found a smoking gun.

In the errata of some older processor (tried to paste the URL but copy&paste doesn't work here) I found that under some rare circumstances I could read back the CCIF bit as "1", meaning that it has completed but it has not yet started. As a workaround, I inserted a loop which waits for CCIF=0 so I know that it has started and then go into my loop that waits for CCIF=1.

Of course I will need a timeout, because I might miss the moment when CCIF=0 due to an interrupt, and then I would wait forever.

Funny thing: Immediately after doing this doble-waiting-algorithm, I cannot read back the data which I have written. It needs some more time, don't know how long.

0 Kudos
637 Views
mjbcswitzerland
Specialist V

Hi Martin

I have used K60, K60F120, K61F150, K70F120 and K70F150 with the same flash driver at speeds between 100MHz and 150MHz. The only difference is the phrase programming on the parts with FPU, which you know about.

Check the bus clock speeds and that the Flash clock is not greater than 25MHz.

Regards

Mark

http://www.uTasker.com

0 Kudos
637 Views
martinpi
Contributor III

Thanks a lot, Mark.

I assumed that I am on 20.48MHz (which is the frequency used by UART5).

When I got your message, I double-checked the flash clock frequency. I found that I am using the FLL with slow internal reference which gives 20.48MHz, but forgot about SIM_CLKDIV1. OUTDIV4 is 2, so so in fact I am down to 10.24MHz (all out-of-the-box factory settings).

I tried to set the flash clock all the way down to 1.28MHz by setting OUTDIV4 to 0x0F, but no effect.

Furthermore, the flash seems to degrade rapidly. My first attempt to program a flash region was successful, then I noticed that a few phrases were not programmed, and now I am definietely down to only one phrase at a time.

I swear to god that I never try to program a previously programmed flash region as I always to a mass erase and verify before.

Greetings, Martin

0 Kudos