STM32F2xx OTP issue

[Barbie]

Posted on April 02, 2013 at 16:47

I need to put some data permanent in the OTP. But I phase a few problem durring debbug.

1. When try to program it on power up like in the FLASH I get the error can't program address 0x1FFF7800 as it is not a part of teh FLASH. Can't I put data in the OTP in advance and if not do I have to put it first to the FLASH and then copy it to the OTP? 2. What is the reset value of the OTP Lock block and do I have to open it at the start up (0XFF)? 3. If I put 0x00 one time in the OTP Lock block can I open it later for change the OTP value or it is permanent? Bar. #rant #otp

[Tesla DeLorean]

Posted on April 02, 2013 at 18:36

It's ONE TIME PROGRAMMABLE, you don't get to twiddle with it, once a bit gets a zero state that's it, all done. Once you lock it you can't unlock it.

The Lock area is all 0xFF (0x1FFF7A00 .. 0x1FFF7A0F) on a new/blank device. The OTP field (0x1FFF7800 .. 0x1FFF78FF) is also all 0xFF. Writing to OTP requires the flash being unlocked, and usual routine support FLASH and OTP.

// Writing OTP, Once and Done, Program bits from 1 to 0
printf(''%08X OTP BLOCK0 WORD0 Before
'',*((uint32_t *)0x1FFF7800));
FLASH_Unlock();
/* Clear pending flags (if any), observed post flashing */
FLASH_ClearFlag(FLASH_FLAG_EOP | FLASH_FLAG_OPERR | FLASH_FLAG_WRPERR |
FLASH_FLAG_PGAERR | FLASH_FLAG_PGPERR| FLASH_FLAG_PGSERR);
/* Wait for last operation to be completed */
Status = FLASH_WaitForLastOperation();
printf(''Status %d
'', Status); // 8 = FLASH_COMPLETE
Status = FLASH_ProgramWord(0x1FFF7800, 0xAABBCCDD); // Write OTP
printf(''Status %d
'', Status); // 8 = FLASH_COMPLETE
FLASH_Lock();
printf(''%08X OTP BLOCK0 WORD0 After
'',*((uint32_t *)0x1FFF7800));

[Barbie]

Posted on April 03, 2013 at 08:16 Thanks for the answer. Still my big issue. 1.Can I put there values in advance (like device ID) without using all the unlock mechanisem, during download my program or I have to put all permanent data first on the SRAM and then program it to the OTP during the run time? 2. When you said ''once a bit gets a zero state that's it, all done. Once you lock it you can't unlock it.'' bit mean any of the bits in the erea 0x1FFF7800 to 0x1FFFA0F or just the Lock bits at 0x1FFFA0 to 0x1FFFA0F and the reast can be change till its lock? Bar.

[Tesla DeLorean]

Posted on April 03, 2013 at 09:26

If the behaviour of the device is not clear to you, then experiment with it until you have clarity. I don't think the manual is unduly cryptic.

Most programming methods use code loaded into RAM to burn data to FLASH, using suitable programming techniques or applets, OTP shouldn't be a problem either. Given you want variable data, you're going to have to generate that data somehow, and provision the device with it. Assume there isn't a magic button in the IDE, consider how you might achieve this.

[r_]

Posted on May 17, 2013 at 15:23

Hi there,

the programming code works fine, but it's only half the Story. The OTP is first of all a Flash with no erase Option, meaning that you can program it multiple times, but it will only reprogram zeroes, not ones. We need to use it as a true OTP, meaning that (example given) if you first program a Location with a 0x1 and subsequently a 0x2, it will keep the value 1 instead of dropping to 0. I believe that that is what the lock Bytes are for, but I haven't found a documentation yet as to how the lock bits map to the OTP Region (the OTP has 512 Bytes and there are 16 lock Bytes; which bit in the lock section would I have to clear to lock down that particular Byte (intuitively, since the lock Byte Region is in OTP as well, it would make sense to use a cleared bit in the lock section as a naildowner for some Region of OTP Bytes). I could of course Experiment, but by Definition I don't have that many shots, and it should be documented somewhere? Are there app notes that describe the process? The MCU we are using is the STM32F207VG. Thanks!

[Tesla DeLorean]

Posted on May 17, 2013 at 17:30

You should perhaps review the PM0059 Programming Manual.

The lock granularity is 32 bytes. If you want to ensure that changes can't be made without observation, a) write a byte and it's inverse, or b) checksum/hash the written data. Writing till zero is a common behaviour of OTP PROM device over several decades. Experimentation is a fundamental part of understanding what you're doing, and validating that knowledge. You might destroy a couple of parts in the process, you have 16 blocks of 32 bytes to play with.

[jj2]

Posted on May 17, 2013 at 18:01

''Experimentation is a fundamental part of understanding what you're doing, and validating that knowledge.''

  So - so true - and too little practiced/displayed - these days... Clive notes that 16 blocks are available to build/confirm your understanding.  Loss of one/several is an excellent means to ''drive home'' your comprehension.  And - doubtful that you'll need every one... Should the potential loss of chip/board be that dreadful - 8 pin, soic, EEProm seems worthwhile alternative.  Most (all) here should be little concerned with size/cost ''adder'' this ''safer'' and simpler option imposes. And - has the ''long-term'' robustness/reliability of OTP - ''massaged'' into the MCU - been painstakingly tested/determined?  EEProm provides far greater flexibility and capacity - and usually enables your ''change of mind/heart'' - not possible under OTP...

[r_]

Posted on May 19, 2013 at 10:35

Clive,

thanks for the pointer to the app note, that was exactly what I was looking for. @sprague: As a business enterprise, we ARE concerned with costs and space, down to the last cent, so we certainly won't design an additional eeprom onto our circuit if OTP presents a valid alternative (which it apparently does. And no, we won't change our minds about the contents of the memory - the location must hold an IEEE Mac address, and that will not change, period. Needless to say, a well written software will by itself prevent the address from being overwritten, but you never know. In the past we have stored the MAC addresses for our devices both in Flash and external Eeprom. The problem with keeping it in ''normal'' flash is that it must reside in a data block which also consists of other configuration data, and as soon as those are changed, the entire block will be erased - and when Murphy catches in at the wrong moment and resets the unit in between erase and rewrite, the MAC address is lost. External Eeprom (even rewritable) will work as each byte can be reprogrammed individually, but again this is at the cost of designing additional components on board. So the OTP seems to be the best choice here. Thanks again.

[jj2]

Posted on May 19, 2013 at 16:41

''As a business enterprise, we ARE concerned with costs and space, down to the last cent!''

Strongly disagree - and has not such, ''misplaced concern'' caused your group to ''miss'' a critical Ap Note???  (kindly supplied by Clive)  And - one expects - other vital details may also be awaiting such discovery. (due to bad - ''up front'' decision(s)...i.e. ''save the eeprom cost!'')  I have sound basis for such concern - offer this as our group ''sees'' such ''over-focus'' with great regularity - and it is too often destructive!  Read on - if supporting detail is of interest... Decade + past - few (4) of us founded tech firm - quit our ''paying jobs'' (after our not overly skillful ads yielded great results) pooled our cash - consulted business experts - and launched.  W/in 4 years our highly profitable sales topped 17 million USD - we were 15 strong (> 1 mil/person) - and one year later we, ''went public!''   The ''market maker'' (one of the business experts who initially advised us - then took us public) was an uber smart woman - and several of her key points may help many here: a) don't compete against, ''best/brightest'' - find an area w/in group's ''reasonable'' capabilities/interests b) hours/effort will be long - time for ''outside relationships'' much reduced c) must accept - and someway/somehow learn to ''enjoy'' the process - not the ''imagined'' end/goal d) must focus on key design items - who else uses/does similar (what can you ''borrow'' - ''NIH'' often good/great!) e) multiply your ''search'' resourcefulness f) prevent ''time-wasters'' (i.e. one subject per 8.5 x 11 sheet - so that it can be properly filed)  Inadequate ''up-front'' organization (finding things) - most always fatal g) wherever possible - simplify h) devise ways/means to ''speed'' test/verification (you must find/correct ''glitch'' before the client/investors!) and i) if your profit margin is inadequate - you are doomed Thus - while your ''business enterprise'' status ''certainly won't allow'' the simplification of an eeprom (due to your ''last cent'' concern) - that ''certainty'' may not prove, ''so certain'' - nor wise.  If you truly ''need'' that ''last cent'' - any hiccup, delay, change is likely to kill you!  (and I'd bet that all 3 will visit your endeavor - as those 3 did (frequently) to ours!) Suspect that most competent business/financial advisors will ''confirm'' this report - your ''certainty'' - not so much...  And - it this headstrong ''certainty'' - which we're observed to so often - wreak havoc! You're silent as regards, ''And - has the ''long-term'' robustness/reliability of OTP - ''massaged'' into this MCU - been painstakingly verified & life tested - over your precise conditions?''  Is it wise (or certain) to be a first/early ''adopter'' of such a migrated technology?  (I know the answer from the investor's perspective...) At the very least - EEProm is available in 5 pin sot-23-5 pack - and your assembler may ''DNF'' if truly not required.  But - as Clive so often advises - you have at least ''exposed'' the potential ''saving use'' of this easy-use, flexible, robust device. Experience taught our group that being early to market - with adequate (not perfect) product  features - and then incorporating those insightful, key suggestions (put forward by ''real'' client-users) - was vastly superior to, ''micro-managing - down to the last cent!''  

[r_]

Posted on May 19, 2013 at 23:49

I don't understand what you are getting at. Are you implying that OTP flash technology is unstable or faulty? What do you base that suspicion on?

As far as I see it, OTP is nothing but ordinary flash, except that a) it can't be erased and b) with the locking extension, it can't even be overwritten after locked. Given that flash technology itself has been around for a long time now (we have used flash chips - ST, Macronix and other manufacturers - for well over 15 years now and have reason to believe that it is a well established and reliable technology), why would those extensions make it worse than the etablished flash technology? Given that you highly recommend a hardware redesign involving additional chips over using the technology (which even in the worst imaginable case - that neither the no erase option nor the lock option worked - would still be the best alternative we have because with 32 byte block size we could always use a single block for the MAC and never touch it after initial programming), what would be the incentive? Or the reasoning?

As a side note, no technology by definition has ever been ''been painstakingly verified & life tested.'' Certain technologies that have been around for a sufficient amount of time (such as TCP/IP which dates back to the early 80s) can be counted on to have overcome their childhood deseases (even though any given implementation may and probably will still have its bugs to deal with), but other than that, you always take a risk adopting something you haven't worked on before. If you imply I can't trust something as basic as OTP - which I don't expect to do anything but to accept the value for one storage location once and then return the same value whenever it is accessed - why should I even bother with crypto coprocessors, USB submodules or the like?