100 Flash Cycle Errata - C5 vs. LM4F-based devices?

Normal 0 false false false EN-US X-NONE X-NONE MicrosoftInternetExplorer4

Yes, the errata will apply to C5 and we are currently finalizing the schedule for Stellaris ARM Cortex-M4F-based devices(LM4F).  Your local Field Sales Representative, Field Application Engineer or local Business Development Manager will be able to work with you to best meet your specific requirements until we are ready to launch.

Hello!

My project is based on LM3S9B90. User data is being saved into internal flash like described in "Using Stellaris® Microcontrollers Internal Flash Memory to Emulate EEPROM". And now this disappointing errata arrives. Basically, it is fatal - now we have to add external flash, redesign the board, update and re-test the firmware, and what is most unwanted - target price will be increased!

My question is - when can I expect the release of next hardware revision with this bug fixed?

Thank you in advance - I really need the answer.

Does the 100 cycle errata not apply to 9000 series Rev C1?   C1 does not have the errata listed as of today.  Perhaps it is excluded because it had the flash patch installed.  Maybe we'll see a Rev C7 with a flash patch once again.

If I understand correctly, it also applies to flash erase/program via JTAG, isn't it?  Which also means that these devices are nearly useless in firmware development since 100 cycles can easily reach in a few weeks.

I do a few month of intensive every-day development. All using the same prototype. No problems were met.

Usually average wear out occurs very far from guaranteed value, so risk of development problems is not high. This especially actual as developers keep binary in flash for maximum few days (customer data must be preserved for years - that's the difference).

Patch for my project is unacceptable - I do intensive sound procession, so long interrupts definitely will be heard by the customers (as far as I remember patch did some kind of interrupt processing).

The problem is that we shall not be sure if it is the firmware error during development or just the flash decides to "retire" after 100 erase/program cycle.

Normal 0 false false false EN-US X-NONE X-NONE MicrosoftInternetExplorer4

Hey guys,

I see three questions:

(1) Will this be fixed in future revisions?

The factor driving this errata update is the third-party flash IP that we used in Tempest class devices.  It is a semiconductor physics issue, and is not fixable in this IP.  The flash IP is the same in all revisions, B1 - C5.  Thus, the endurance cycle limit for the all revisions will be 100 cycles.  

With 100 endurance cycles over the life time of the device, we meet normal qualification standards for operating life.

(2) How is development impacted? Can I trust my parts after 100 cycles?

I agree with Alexander. Consider that the specification of 100 cycles was calculated to achieve a 10 year lifetime of a device. Development cycles are usually much shorter. In fact, the TI quality team specifically evaluated the development model and assuming an erase/reprogram every 30 minutes Monday-Friday for 10-hours a day, we feel comfortable you could program a device 10,000 times in 1 year and not expect the failure of your device due to this erratum.

One thing customers should account for during development is final prototype testing. You want to make sure that final prototype and application testing  is executed on silicon that has not been overstressed. In this manner the devices being tested will reflect the behavior of the devices you receive from TI.

(3) When are the ARM Cortex-M4F devices going to become available? 

Texas Instruments is actively involved in developing Stellaris ARM Cortex-M4F devices. It is still a little early to pull back the curtains on specifics, but we can say that 2011 is going to be an exciting year for those customers looking for differentiated ARM Cortex-M4F products from TI. If you have a driving interest in evaluating Stellaris ARM Cortex-M4F devices, please contact your local TI representative and we will work with you directly.

Note I did remove one post from this thread due to the fact it exposed some schedule information that is protected under our non-disclosure agreements.

Let me know if you guys have any further questions.

Thanks, ~Miguel

Dear Miguel,

Thank you for the information but it still not clear.  Do you mean that the errata 100 PE cycles only for 10 years data gurantee (in other words, my data in flash shall be OK for 10 years if PE cycles are under 100?).  If I use more than 100 cycles, the data retaintion shall be lower than 10 years?

Thanks,

Huy

Huy,

Yes, as long as the PE cycles used by the application stay under 100 the data retention is not affected. Stellaris microcontrollers are qualified for a minimum lifetime of 10 years. 

~Miguel

Hi,

I am not quite understand what's the meaning of 100 cycles.

Consider I am not doing development and need to re-program the MCU 50 times a day, do you mean the MCU will be damaged after 2 days developement?

If yes, it doesn't make sense, please clarify.

Thanks

Best Regards,
Jeff

Hi!

It means, that if number of cycles is <100 PE, TI guarantees 10 years of data retention. You can do >100 cycles and it doesn't mean that device should be immediately damaged, just in some cases data retention will be reduced. I suppose TI doesn't have data about how data retention is affected for overstressed devices, as devices being sent to customer should have 10 years data retention (industry standart).

Jeff Chung said:

Consider I am not doing development and need to re-program the MCU 50 times a day, do you mean the MCU will be damaged after 2 days developement?

No it does not mean that.  The 100 cycle limit is to ensure lifetime of the part, over temperature range and all that.  I have various development boards I use all the time and have hundreds and maybe more than 1000 cycles and it is still working okay.  So it should not affect your development.  But then don't go take the part you used for development and put it in a production unit.

Hi,

Are the LM4F devices pin compatible with LM3S?

Jan