IAR 5.20 and pre silicon rev Y

[brj]

Posted on October 05, 2008 at 10:22

IAR 5.20 and pre silicon rev Y

[sjo]

Posted on May 17, 2011 at 12:44

I am guessing st mean codesourcery branch 4.2.3 as gcc mainline did not support v7 core until v4.3.0 and above.

Could st be a bit more specific about the issues? Cheers Spen

[lanchon]

Posted on May 17, 2011 at 12:44

ok, Sourcery G++ Lite 2008q1-126 is version 4.2.3, so basically everyone has been developing under an unsupported configuration for half a year. nice.

I'm using rev B's, so what now? should I downgrade to 2007q3-53? I'm not sure, take a look at the text: ''To date, compilers known to generate these sequences are: -IAR EWARM rev 5.20 and later -GNU rev 4.2.3 and later'' see? it doesn't say pre-4.2.3 versions aren't affected. (it does say ''For code update of revision Z and B devices already in the field, do not use these new compilers'', but then it doesn't say which compilers to use.) I think pre-Y silicon has a problem so serious it can't be worked around, and that's why ST is keeping it secret. in my mind I can't rule out the possibility that pre-4.2.3 GNU has exactly the same chance of triggering the issue as the more current compilers, and ST is just saying: ''leave what's working alone but don't develop on pre-Y or you might get unexpected behavior anytime''. so unless ST says that 2007q3-53 is not affected, or at least that it has less chance of triggering the issue, I won't bother to downgrade. I wish I knew what kind of failure I should be looking out for, but they just won't say a word. this ''the devices we sold you malfunction but we won't tell you how'' attitude is unprecedented for me. in a parallel universe I'd be telling ST how bad that is for business, but after seeing ST's policies in action I really don't care much about the future of the stm32 anymore; their secretive policies aren't compatible with mine and it's clear they aren't going to change. remember the controversy around flash security? did they answer any of our request to describe the flash protection system? did they at least agree to say ''we are not aware of any circumvention methods at this time''? not a chance, they just said measured things like ''when you enable flash protection the flash is protected''. ''compilers known to generate these sequences are...''. nice wording... when it's time to take one for the team, when ST has to choose between its well being and that of its customers, I think I know what to expect. so... -flash is protected -behavior is fully deterministic -compilers known to generate these sequences are... -oh, but zero proof; these things might be unverifiable and convenient to ST but that's just a coincidence I do enjoy the roller coaster in pitch black night felling, though I doubt I'll be up for another round... > gcc mainline did not support v7 core until v4.3.0 sjo, do you know what codesourcery was merged into mainline?

[lanchon]

Posted on May 17, 2011 at 12:44

I forgot to state the real reason for my post. I believe the IAR codebase is completely independent of GCC, is that right? if it is, I find it incredibly hard to believe that the two developer groups figured out some kind of clever code generation method that triggers the issue, and that they both found it just in time to include it in their current compiler releases, but not before. and on top of that, that there is no way to disable these features.

''Compilers with improved optimizations [...] have been recently released''. ''Revisions Z and B [...] do not support some of the sequences associated with the high-level optimizations''. optimizations can be disabled. and what the heck is a high-level optimization anyway? if IAR and GCC are indeed completely independent, I'll say every version of every compiler might be ''affected''. (though it may be that IAR 5.20 is more prone to trigger the issue.) one word in defense of ST: maybe it's a core issue and ARM has ST all NDA'ed. has the core version been updated for rev Y?

[16-32micros]

Posted on May 17, 2011 at 12:44

Hi jj.sprague, lanchon,

Could you be precise enough to provide the names of your Distributors and also contact names, So ST could contact them and see what are the missing piece in the delivery of our devices ? Thanks. STOne-32.

[16-32micros]

Posted on May 17, 2011 at 12:44

Hi,

For your information, all our Distributors are already aware about our PCN ( Product Change Notification) since April 2008 about our new sampling of revY and here you can see with EBV Distributor [ Just an example ] at this Link

http://www.ebv.com/en/websearch_results.html?search=STM32

, all STM32 History and the switch to revY. Regards, STOne-32. [ This message was edited by: STOne-32 on 04-10-2008 15:53 ]

[jj]

Posted on May 17, 2011 at 12:44

STOne-32-

Thanks for your update your efforts are appreciated. On two occasions (03-10-08, 01-10-08) I specified my US midwest disty as Avnet. We have a relatively new relationship - I ask your assurance that this forum participation will not damage it. I supplied the distributor's name because our STM32F purchase quest is well documented - and current - ''not'' to cause this disty nor our contacts any harm. I will tell you that the Rev ''Y'' issue is ''not'' as ''under control'' as you may wish. I have mentioned (as have others) the presence of Rev markings in ''illegal'' fields and the ''horror'' of trying to explain Rev marking location to personnel in distribution. (not fun - not quick/easy) We took advantage of your earlier, IAR board exchange ''hint'' - and got back a Rev ''Z'' (not the sought Rev Y) for our efforts. The Eval-B exchange was satisfactory - however this does support my sense that Rev ''Y'' is very much a ''work in progress.'' Believe the bigger issue is the availability of ''sample vs. production'' quantities of Rev ''Y'' in ST's distribution channels. It is not possible to properly resolve the meaning of, ''samples are available at full production!'' Does this mean that Rev ''Y'' is in full production - and that ST's mainline distys have production volumes available for sale? This meaning would offer your forum the most comfort. Would you be so good as to clarify? Thanks much your time/attention. [ This message was edited by: jj.sprague on 04-10-2008 21:47 ]

[picguy]

Posted on May 17, 2011 at 12:44

Enough already!

It’s clear that some early STM32 parts have a problem. From the absence of comment by IAR and others it’s almost as clear that software vendors reporting the problem have been sworn to secrecy. For the record, I still have a “recalled part� on my STM3210B-SK/IAR. But I worry that even though I am using the IAR C compiler with minimal optimization some of my assembly code may fall into whatever problem the CPU may have. I would be willing to give a credit card number to guarantee that when a replacement board arrives that I will ship the old board back ASAP. But the rule was “ship the entire package back� and I am actively using the IAR J-Link debug pod. Other tech companies have had problems and fixed them. The problem HP had with its first batch of HP-35 calculators met with the best response ever. The problem was as clear as sqrt(2)^2 = 2.002. Whatever the exact sequence it was that simple. HP did a stop ship and recall of products on store shelves. IIRC every retailer was authorized to do a 1 for 1 replacement no questions asked. Intel had to be beat up a bit in the press with their FDIV bug on the P90. But they made things right. If Luminary Micro had not made its code protect feature so secure that it ended up useless I would be tempted to use their parts. My message to ST is say what the problem was. This will instill confidence in your existing users and keep then from looking elsewhere. It will also tell developers that have “bad parts� in the field what their exposure is. It would be comforting to know that the problem only effects xxx during yyy with zzz. Many will find that ‘bad parts� are not going to make field problems. Others may have to ship new boards ASAP. Do not treat product defects like trade secrets. It only makes the problem worse.

[lanchon]

Posted on May 17, 2011 at 12:44

hi ST1,

I sincerely thank you for your efforts, but I continue to dislike the policies of your employer, and that is hardly your fault. regarding your question, I'm not trying to obtain rev-Ys at this time. my concerns are the pre-Ys on the field on the short term, and ST's policies on the long term. picguy, > My message to ST is say what the problem was. This will instill confidence in your existing users and keep then from looking elsewhere. It will also tell developers that have “bad parts� in the field what their exposure is. that's sane and very well put. but me I have no message for ST. I find it unacceptable that we need to invest our time and emotional well being in creating a fuss for the small chance of getting a decent response form ST every time there's trouble. and remember we don't always get it. this is not a one time occurrence, it's ST and its policies as we've come to know them; and get used to it because it'll happen every time. I've no message for ST, I've no stake in them and don't care how they fare. but I do have a message for my fellow designers and it's this: if we accept being treated like dirt, companies will do it and so we will be treated. my message is: this is our fault. want to fix it? review ST's policies as expressed by their actions and decide whether they are acceptable to you. case in point: you'll never know how ''secure'' your code is and, unless there's a big fuss, you'll probably never know what's wrong with pre-Ys either. that's a fact; now deal with it. I have. > It would be comforting to know that the problem only effects xxx during yyy with zzz. Many will find that ‘bad parts� are not going to make field problems. I doubt this is as predictable and rare an event as we'd like to think, and knowing what's wrong might not be comforting at all. many vendors patch compilers with optional workarounds for errata but this may not be an option here.

[jj]

Posted on May 17, 2011 at 12:44

lanchon-

You clearly program rings around me and your analysis and sensibilities of the business case for/against ST/forum participants is ''spot on!'' Bravo - I salute your keen-ness, the fact that you really care, and the effort you regularly put forth. Thank you. pic-guy- ''enough'' - ''that'' will surely get their attention and produce proper, to-spec parts. I have to agree (and be impressed) with the bulk of your post - but am compelled to observe/report that - ''with a head of steam up'' you fully disregard your own ''enough'' advice...

[16-32micros]

Posted on May 17, 2011 at 12:44

Dear lanchon, jj.sprague, picguy,

Thank you for your posts. But I believe that expressing opinions could be carefully written either in private or Public domain to not offense others people and others engineers reading the posts, Let's try to be Positive and oriented to solve and find solutions for your field applications. Could you Please contact your ST Online-support to get direct contact with you. Thanks for your comprehension. Regards, STOne-32.