LPC2368 Flash Memory IAP read / erase -> longer programming time and longer erase time

[danielgull]

Hi

I am working with the NXP microcontroller LPC2368.

In the User Manual UM102011 (https://www.nxp.com/documents/user_manual/UM10211.pdf

1. in chapter 29.8.2 "Copy RAM to flash" there  is an iap command description for the command "Copy RAM to flash" with the "Command code: 5110". The "Param3: System Clock Frequency (CCLK) in kHz" is of interest for the discussion in this email.
2. In chapter 29.8.3 "Erase Sector(s)" there  is an iap command description for the command " IAP Erase Sector(s) command" with the "Command code: 5210". The "Param2: System Clock Frequency (CCLK) in kHz" is of interest for the discussion in this email.

Can I use these two parameters (Param3 and Param2) to modify the programming time or the erase time of the internal flash memory transistors?

Normally I apply here the System Clock frequency (CCLK) in kHz that is used for the core. However evidence seems to indicate that the internal flash memory may not be erased reliably and not be programmed reliably for some devices.

I would like to increase reliability of the erased transistors on the silicon as well as increase reliability of the programmed transistors on the silicon by increasing the erase time and increasing the programming time. In order to prolong the programming time or the erase time can I decrease these two parameters (Param3 and Param2) in their value to achieve longer programming time and longer erase time?

The idea is that by telling the IAP control block that we have a slower frequency than physically available we force the IAP control block to increase the programming and the erase time.

Do you have any recommendation as to how these two parameters can or should be modified to increase reliability of the erased or programmed transistors in the internal flash or do you have a different approach how I can achieve a higher degree of reliability of the erase and programming quality of the internal flash transistors?

Many thanks for your support on this matter.

[magicoe_niu · Accepted solution]

Hi,

There are two threads in internal community.

My reponse to original thread:

Magicoe's answer as below

Customer can not use those two param to set the FLASH speed/clock. Those two parameters is help ROM code to operate flash correctly, so you must follow the document information and set correct system clock to ROM code.

Set Flash at low speed would not help flash operate safety.

My response to the 2nd thread:

is that possible running CQC first?

for Flash IAP, please take below attenstion:

1. Errata: 3.10 Flash.1: Operating speed out of on-chip flash is restricted

2. Errata: 3.12 MAM.1: Under certain conditions in MAM Mode 2 code execution out of internal flash can fail

3. Suggestion: please kindly allocate IAP function code to RAM area.

4. Suggestion: please make sure interrupt is disabled before IAP operation.

5. Suggestion: please kindly keep the top 32bytes of RAM for IAP ROM code use.

. Flash programming commands use the
top 32 bytes of on-chip RAM. The stack is located at RAM top - 32. The maximum stack
usage is 256 bytes and it grows downwards.

[frank_m]

Let me add my unqualified opinion here ...

In my experience, clock frequency has no impact on erase/program reliability. The issue is, I think, that core clock frequencies on most MCU devices can be set far beyond the speed capabilities of Flash, so defining a clock frequency will determine the waitstate settings.

Flash erasing/programming is a repetitive process, were charges are "fired" repeatedly onto an isolated gate (using an increased voltage) until a threshold for proper differentiation is reached. AFAIK it is electro migration that reduces the efficiency and eventually destroys the cell (i.e. making it unusable).

The number of achievable erase/program cycle is very much related to temperature. Numbers given in the specs usually refer to the worst case, i.e. maximal temprature (95 ... 125°C). One can expect an increase of one order in magnitude for each 10°C less. So, a device with 10.000 guaranteed cycles might reach tens of millions at room temperature.

[danielgull]

Hi Frank

Thank you for the quick response.

So there is an internal on chip analog comparator that compares the charge reached on the isolated gate and this threshold is defined internally on the device and the programming and or erase time increase will not be able to change that threshold. So there is no possibility to influence the reliability of the programming or the erase of the cells due to this analog comparator on chip implementation.

Many thanks for this clarification.

You mentioned that you are not 100% sure (your and I quote "unqualified opinion") about your understanding how this works internally. Can you get a confirmation internally within NXP to get a confirmation on your understanding.

Dani

[carstengroen]

@danielgull ,

I know this is not the same chip, but I would guess they are close...

we have currently more than 50.000 devices with LPC2458 running in the wild, they do once in a while get updated "over the air", and I have yet to see a single one of them fail (timespan more than 8 years) during this process. The only device I'm aware of that I use with a problem, is the LPC1788 where the errata says not to run above 100 MHz (if I remember correctly) if IAP is to remain without faults. The LPC1788 can  run at 120 MHz, but I keep it at 100 MHz just because of the errata.

I would also look somewhere else, is the IAP procedure followed 100%, power supply etc etc.

Good luck!

Carsten

[danielgull]

Hi Carsten,

Thank you for your input. I will review my code to take the ideas you put forward into account.

Dani

[converse]

Reliability of programming is 100% via IAP, provided you follow the rules. Frank has done a good job of explaining some of this. However, if you are experiencing some apparent unreliability, I would be prepared to wager that you have a power supply problem. Programming flash takes vastly more power than reading it. I would take a look at your circuit and look to see if the voltage drops while you are programming. 

p.s. I am also just a regular user, but with over 10 years of experience using LPC, starting with LPC2000.

[frank_m]

That's correct, erase/program involves an increased current consumption. Due to the underlying physical process, a voltage of 9..12V is required, which is usually created by a switched-capacitor converter implemented on the silicon. Which is usually the reason why the affected block cannot be accessed for normal read at that time.

I was involved in projects which required Flash erase/program after a mains-off was detected, with the board living from the remaining electrolytic capacitor storage. For the small 8-bit MCU involved, current consumption doubled in that case. And electrolytic capacitors age realtively fast, i.e. loosing capacity ...

[danielgull]

Hi Frank

Thank you once again for your valuable input. I think that we should verify our power supply integrity during flash programming and flash erase directly on the hardware. We may have some weakness on the hardware side. I will follow this path to be able to confidently rule this out or find solutions on the hardware side if the power supply deteriorates during flash programming and flash erase.

Dani

[frank_m]

Seems my latest response was swallowed by the system ...

Anyway, I am not affiliated with NXP, just a normal user like you.

Just having quite a bit of experience with other Flash-based devices, and projects relying on Flash as frequent storage.

Many manufacturers do not share specific implementatio details on public fora, so you might need to open a support ticket or approach an official distributor. But NXP engineers are quite active here, so give it some time.

[danielgull]

Hi Frank Thank you for taking the time to read my post and respond to it. Very much appreciated :-). I have opened a support ticket with NXP, but no response so far, so I thought I would post the contents of that ticket here in the NXP community to see if I get a better response time - and sure enough - Frank took some time to read and respond. Many thanks once again. Dani

[frank_m]

Perhaps you can push the ticket a bit in the direction of your specific requirements.

Critical point in regards to Flash are, as fas a I'm aware of, the following: 

• permanent repetition (many cycles, wear-out)
• high temperatures
• cosmic radiation (alpha particles at elevated hights)

[xiangjun_rong]

Hi, all,

As far as I know that the flash erasing/programming operation requires a "flash-driving constant low frequency clock", the "flash-driving constant low frequency clock" is a divided clock from system clock. The api function with erasing/programing  command requires the parameter "System clock frequency (CCLK) in kHz", which can tells the api function to figure out the corresponding divider so that "flash-driving constant low frequency clock" frequency is fixed and constant.

Hope it can help you

BR

XiangJun Rong

[danielgull]

Hi XiandJun

Yes that was my guess at first as well and my idea was to reduce this parameter to force longer flash programming time and longer flash erase time.

What I gather so far from the feedback I received is that I cannot influence the flash programming time nor the flash erase time with this parameter.

The chip internally handles the voltage thresholds of programmed cells or erased cells independent from this parameter.

The clockspeed parameter is only there as a reference clock to drive the state machine used inside the flash to program and erase. The determination however if a cell is erased or programmed sufficiently is determined by analog circuitry that is independent of the clock speed.

Dani