K22 FTFE Erase Sector command failure

[alubeiro]

Hi all,

Im working with MK22FN1M0AVLL12. It has 1MB of flash (2 flash blocks and no FlexNVM memory)

My code is into block 0 and the issue happens when i try to erase a sector which is into this block 0. (erasing into block 1 is ok).

I am not using any interrupt so I guess it is because it is not possible to execute code and erase a sector which is into the same block at the same time, am i right?, should i execute the erase and program code from RAM so it can works?

I did the same (execute code from flash) in a K60 which only had one flash block and then i could erase and program a sector successfully, why??

Maybe it is because it is only posible to erase a sector executing the code from flash in MCUs that only has one flash block???

Thanks and best regards.

[alubeiro]

Hi Mark,

The watchdog is not enable. It is disabled at startup.The register is settled at "0x01D2" value

As for the reset, the active flag in "RCM_SRS1" register is the "lockup" flag

There are not protected Flash regions as all "FPROT" registers are 0xFFFFFFFF

Sorry but I don't understand the code you have posted, i mean, inside fnFlashRoutine you clear the CCIF bit, which launches the command (this code should be in SRAM)

By the way i have tried to do the error checking back in flash but it doenst go any better.

Thanks and regards

[mjbcswitzerland]

Alberto

>>I don't understand the code

The code is run from SRAM; notice that fnRAM_code() is called rather than the reference routine.

In fact I actually use this:

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
};

because it avoids any risk of different compiler and optimisations from causing it to fail (for whatever reason) and assures that the amount of bytes located in RAM remain identical in each case.

There is another question recently with the same (random) LOCK UP behavior:

inconsistent 'LOCKUP' reset when programming Flash Memory 

My only explanation is that there are interrupts causing this to happen....

>> error checking back in flash but it doenst go any better.

It won't change this behavior but I was pointing out that the library code that you are basing your work on is not as optimal as it could be.

Regards

Mark

[alubeiro]

Hi Mark,

The solution is to disable the interrupts. But why? i don't use any interrupt in the project.

I have put the code "__asm ("cpsid   i");" at the beggining of the main and now the board is not resetting.

Thanks for your help and best regards.

[mjbcswitzerland]

Alberto

You must have been using interrupts somewhere (like timer) without being aware of it.

Regards

Mark

[alubeiro]

Mark,

You are right, there was a system interrupt "Sys Tick" selected.

It was in "fsl_os_abstraction" component

I have remove it and now this "__asm ("cpsid   i");" instruction is not needed.

By the way, this interrupt was enabled by default when i created the project.

Besides, why does this issue happen only when i try to write in block 0?

Thanks again and regards

[alubeiro]

Hi again,

I have just placed the function "FlashCommandSequence" in RAM but i am facing the same issue.

The MCU resets when i erase a sector which is in block 0

I forgot to say im using C90TFS drivers.

Any help will be apreciated.

Thanks and best regards

[mjbcswitzerland]

Hi

Are you running the K22 in HIGH-SPEED-RUN mode (> 80MHz) which doesn't allow Flash programming?

Regards

Mark
Kinetis for professionals: http://www.utasker.com/kinetis.html
For trouble-free K22:
- http://www.utasker.com/kinetis/FRDM-K22F.html
- http://www.utasker.com/kinetis/TWR-K22F120M.html
- http://www.utasker.com/kinetis/BLAZE_K22.html

[alubeiro]

Hi Mark,

The K22 is running at 120Mhz but as i say above i am able to erase and program data into flash block 1 (0x80000 - 0xFFFFF)

thats why i guess it is not possible to erase nor write in the same block where the code is running. In this case block 0. So i have relocated the the code in RAM but i am still facing the same issue. The K22 goes to reset state.

Where have you seen that running > 80Mhz doesn't allow Flash programming?

Thanks and best regards

[mjbcswitzerland]

Alberto

Your device doesn't have HIGH SPEED RUN mode and so I made a mistake suggesting that it may be related to that. The K22s with FlexNVM do have it in order to be able to operate faster than 80MHz, with some restrictions such as Flash:

The difference between K60 and K22FN1M0 Flash is that the K22 uses phrase programming rather than long word programming but I don't know any differences when erasing.

The K22FN1M0 is equivalent to the K21FN1M0 with respect to memory so you could try to run the following binary (it allows Flash to be erased, programmed, etc, in the I/O memory if you can get it on the UART or USB) on your board: http://www.utasker.com/kinetis/TWR-K21F120M.html to verify operation. The flash commands are described in http://www.utasker.com/kinetis/KE_EEPROM.html (valid for RAM, EEPROM or Flash).
I don't know the Flash driver you use but check that the K21 doesn't require a different one (that is, take the Flash driver from a K21FN1M0 example rather than a K22 one).
In case of further problems just use the uTasker Flash driver since it is suitable for any part (KE, KEA, KL, KV, KM, Ks).

Regards

Mark
Kinetis for professionals: http://www.utasker.com/kinetis.html
For trouble-free K22:
- http://www.utasker.com/kinetis/FRDM-K22F.html
- http://www.utasker.com/kinetis/TWR-K22F120M.html
- http://www.utasker.com/kinetis/BLAZE_K22.html   <------ this uses your part by the way!!!

[alubeiro]

Hi Mark,

The driver i am using C90TFS, has been tasted in a lot of devices. In my particular case (MK22FN1M0), it has been tasted in MK21FN1M0

In anyways it is working well as long as i erase sectors which are in block 1 so the code works well.

Now, i have the "pFlashCommandSequence" allocated in RAM but still cant erase sectors in block 0.

I wonder if there is anybody working with the same K22 as me and with C90TFS driver.

Im working with a customized board.

Thanks and best regards.

[alubeiro · Accepted solution]

Hi

I have resolved the issue.

It was due to some code macros which were called inside the "FlashCommandSequence" function.

they should me relocated in RAM also or just put the code without the macro into the function which is already alocated in RAM

Best regards

[mjbcswitzerland]

Alberto

As you see the library routines have been tested, but presumably not under "real-use" conditions....

Library code should normally be compiler-independent and "automatically" handle whatever situation the user uses them in.

As I noted before, RAM code should not need to be more that 6 instructions in size and of course not require modifications to the library code to be able to actually work!

Regards

Mark

[alubeiro]

Hi Mark,

As you see i have had to put the Macro's code instead the macro itself otherwise i couldn't write code in flash block 0.

This way the whole function is alocated in RAM "myramsection"

So i have had to modify library code.

In any ways it works fine in block 0 as long as i am debugging step by step. I mean going over the "FlashEraseSector" function by one step, then let it run still "FlashProgramSection"  function and then go over it by one step too.

If i let the code run, the MCU resets.

I have put a delay between the sector erase and the sector program but nothing has changed.

Any idea or test that i can do?

Thanks and regards

[mjbcswitzerland]

Alberto

If you are not using interrupts (or interrupts are disabled) there is no reason why the routine would fail as long as all is in SRAM.

However I see that there is a callback in the code that is called while waiting for the Flash operation to complete - this will not be called when stepping the code but would be called when running at full-speed.

Make sure that this routine is also in SRAM in case it is used. Or set it to 0 if you don't want it to be called - ensure that it is set and not left as a random value since it would otherwise also cause a crash.

Regards

Mark

[alubeiro]

Hi Mark,

Ya, im not using interrupts.

As for the callback function it is pointing to a NULL_CALLBACK value so it wont be called.

Besides "while(0x0U == ( (*(vuint8_t*)(temp) |= (FTFx_SSD_FSTAT_CCIF))))" never will be true ¿may be it is a bug?

you said >> this will not be called when stepping the code but would be called when running at full-speed. ¿why?

When i go by step, i do from erase to delay, i dont go by step inside erase function so it is the same as go running, isnt it?

Thanks and regards

[mjbcswitzerland]

Hi Alberto

"Stepping.." I thought you stepped the code in SRAM and all was OK - this would not have tested the call-back since the stepping would have been slower than the programming and so the flag never in the appropriate state. If you step over the routine there is no difference.

I cannot explain anymore what you are seeing. Maybe your HW has a problem (programming current causes supply to dip)?

I have attached the uTasker Flash driver again in case you want to compare anything.

Regards

Mark

[alubeiro]

Hi,

The last thing i have seen is that the furthest it goes without being reseted is the break point which is inside the disassembly window.

This breakpoint belongs to the "while".

Any help will be appreciated.

Thanks and regards

PD: Remember that this issue happens with addresses that belongs to block 0. up to 0x7FFFF

[mjbcswitzerland]

Alberto

It looks like the while loop is never being quit - do you have the watchdog active? Also, when there has been a reset do you know what the reset controller reports as cause for the last reset?

The code looks Ok but it has been written in a way to make it as difficult to understand as possible....the following is easier to understand but exactly the same (there is no need to do the error checking in the RAM code - you can do it after it has returned.

static void fnFlashRoutine(volatile unsigned char *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
}

and called with
fnRAM_code((volatile unsigned char *)ADD_FLASH_STATUS_REGISTER);  // execute the command from SRAM

Regards

Mark

[mjbcswitzerland]

Alberto

It is normal that it is not possible to erase sectors in the plane that the code is running in and so te code needs to be run in RAM instead. However, are you sure that you have correctly located the code in SRAM and are correctly calling it as a THUMB routine? If not the code will crash, even if the code is otherwise correct.

The simplest way to find out is to set your debugger to disassemble mode and step the code being run in SRAM (Flash programming only normally requires 6 THUMB instructions in SRAM so it is easy to check that they are operating correctly or whether the reset you have us due to invalid SRAM code).

Also check the status in the reset controller to see what type of reset it was.

Does the library code that you use not automatically handle code re-location etc.?

Regards

Mark