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

[jj2]

Posted on May 20, 2013 at 05:06

How much time do you wish to invest in ''saving'' a sub 0.50 USD - sot-23-5 footprint chip?  Has not the time you and your group have invested in this effort - thus far - come at the expense of far more important development activities?

I stand behind the opinion that ''adding complications'' - when far faster, easier, more flexible solutions are ''at hand'' - is unwise at this early stage in your development.  Far better to bring your product to market - gauge market acceptance - and only then attempt to drive down costs - as/if needed. I've just returned from major ''start-up'' feeding frenzy in silicon valley.  The points I listed earlier were an excellent gauge to investor willingness to ''feed'' multiple start-ups.  And - years back - they enabled our group to succeed beyond our wildest dreams. Some start-ups are ''coachable'' - some not so much - guess which ones win financing...  

[jpeacock2399]

Posted on May 21, 2013 at 01:10

While the advice for a startup may be valid, especially if it's some kind of social networking website, in the embedded world that advice may be the worst possible.  If you work in a manufacturing setup, especially with ISO-9000 certification, ''good enough'' doesn't make it.

Controlling a mechanical device with a 15 year lifespan buried deep in customer equipment means there's no in-place updates to fix the bugs later.  First to market with a controller that mostly work means you throw away your reputation.  Not competing against ''best and brightest'' means your product winds up with a 2% market share and going nowhere at breakneck speed. Embedded is not social, and it's not the web service flavor of the week.  It's hardware as much as software.  Ask yourself this question: are you prepared to buy a laptop knowing that one out of 1000 power cycles the battery manager embedded code fails and overcharges the li-ion battery, causing it to burst into flames?  Even if that laptop is first to market, and mostly works?   Jack Peacock

[jj2]

Posted on May 21, 2013 at 03:14

As stated - our group launched decade + past - there were few social network sites of consequence then - and ours was a blend of HW and SW - far removed.

You're arguing by extremes - with odds stacked against us - we competed with multiple ''giants'' far better financed and equipped - but w/out our work ethic, ability to deliver client requested features efficiently - and our ability to blend & harness our overseas production power-house with our ''unique insider knowledge.'' And - so often our fast entry caused key clients to contact us - and share absolutely crucial design info - which we'd most likely have either missed or under-valued - by designing to ''perfection.'' You're smart enough to produce a writing which is a cut above, ''burst into flames'' and, ''mostly works.''  Delaying a product's introduction to save a 0.50 USD, sot-23-5 sized component's size/cost borders upon the indefensible.  And you knew/know that!

[r_]

Posted on May 21, 2013 at 09:57

@jj.sprague: I don't know (nor care for that matter) what drugs you are on. I asked a simple how-to-question (thanks again to Clive for the down-to-the-point answer), and you start off some kind of ''big picture'' debate, trying to convince me to make a hardware design change instead of addressing the issue, insulting me and questioning the quality of STs MCU along the way (if I were the site administrator, I'd suspend your account on ground of badmouthing my products). The only way I can explain this rationally is that you work in sales for a company that manufactures Eeproms and try for a cheap sales pitch.

Just fyi (and this concludes the debate on my side): we're not start-ups. Our hardware designer has 25 years experience in his field and can be counted on to always find the best compromise between the desireable and the doable (after all, that's what engineering is all about). Myself has worked for 20 years in embedded software design. What you are proposing is essentially a new hardware design cycle (do you have any idea what's involved in that?) along with taking all the additional risks involved in designing additional circuitry (which has effects not only on development but also manufacturing, purchase and QA) for no arguable reason. For what we set out to do, OTP appears to be an ideal solution, and there is no reason under the sun why anyone in his right mind would instead add additional hardware.

@Clive: Thanks again for your timely and useful answer. I wish the forum had an ignore function so that one can filter out the noise generated by notorious side trackers.

[jj2]

Posted on May 21, 2013 at 15:51

Heat of your unkind response speaks volumes re: your comprehension & lack of logical support for your position.

Medically prescribed drugs only (my misfortune)  - and have no such EEProm connection. I provided a list which I believe sound - which worked extremely well for our group - and which was often, ''in play'' during a recent ''tech funding camp'' in silicon valley.  My only goal was to present that info here - for the consideration/benefit of interested others.  (and I so noted - via disclaimer - at the top of my post)  I made no attack upon vendor's product - instead noted that such ''addition'' is rather new introduction to this class/type MCU - and as such may not have been time-proven.  Your lack of comprehension or deliberate attempt to state otherwise is improper - perhaps should subject you to the fate you suggested... All of the experience you cite did not exactly ''bubble up'' during your early request for guidance here.  Indeed - Clive had to ''rescue'' your critical data discovery efforts - perhaps that experience would benefit from less hostility and more focused effort... And - that ''experience'' surely failed you when an sot-23-5 EEProm was not initially emplaced - providing you a ''safe/sure'' and far faster/easier/more flexible means to achieve your design objective.  Once the other method is perfected - the sot may be DNF - but its presence offers great comfort...  (and conveys ''real'' experience...)