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

[jj]

Posted on May 17, 2011 at 12:44

brj-

It took 3 weeks but we got our ''non-Rev Y'' ST TFT Eval Bd. and IAR Starter Kit replaced. Can't speak for all modes/conditions - however we experienced both debug and flash issues with the errata-laden parts. Debugs/flashes normally now - however we have not had sufficient time to perform in-depth tests yet. Suggest you replace with Rev Y. Also suggest that you try SWD - frees pins and the possibility of trace is compelling.

[brj]

Posted on May 17, 2011 at 12:44

Hello all,

The issue reported in TN0067 (regarding IAR 5.20), is it only related to working within the IAR debugger, or are the binaries produced with 5.20 not compatible with pre Y revision silicon ? TN0067 is not very informative, regarding the actual problem ! regards Brian

[brj]

Posted on May 17, 2011 at 12:44

jj- Thanks for your input

I contacted IAR and they have made their own technical note on this issue Technical Note 50011 STM32F10xxx Medium-density devices & v 5.20 http://supp.iar.com/Support/?note=50011 As I feared one can not generate binaries with 5.20 that are compatible with pre rev Y silicon. This is a serious problem when you allready have delivered systems containing rev Z silicon, that needs to be field upgradeable ! :( Though nobody can seem to explain what the real problem is ?

[jj]

Posted on May 17, 2011 at 12:44

brj-

We are in the same boat as you - ''pre Rev Y'' units built/shipped and now likely doomed. To some degree this IS the price of progress - and ST is not alone. Here's what we've come up with - contact affected clients and explain that we can not provide future ''upgrades'' to their existing boards/products. We then offer a free/reduced cost upgrade during our next ''normal'' upgrade event. I don't think we'll ever learn the full extent of the Rev Y ''fix'' - perhaps its best that we NOT know! Swap the chip, read errata regularly and ''fuhged'' about it...

[lanchon]

Posted on May 17, 2011 at 12:44

> As I feared one can not generate binaries with 5.20 that are compatible with pre rev Y silicon.

so this is not an JTAG or debug issue then, and it affects all toolchains and all customers. > I don't think we'll ever learn the full extent of the Rev Y ''fix'' well I'm tired of ST's secrecy. we still have the pending issue of the undisclosed security model that's in all probability horribly defective, and now this? some of us were sold parts now known to misbehave (at least to the extent that they were fixed), and we are not told in which way? I'm putting off commercial uses of the stm32 until I can establish a base level of code protection based on published facts (there's no such established base level of security, I consider it simply not protected). I expected the situation to get better with time, not worse; we'll see... EDIT: > As I feared one can not generate binaries with 5.20 that are compatible with pre rev Y silicon. I followed your link and I couldn't see anything there backing your affirmation. what makes you say this? of course ST is not saying that binaries would work but they are not saying otherwise either. has anybody actually seen misbehavior? is it during programming and/or debugging, or is it something else? why don't you ask support the binary compatibility question? [ This message was edited by: lanchon on 16-09-2008 03:41 ]

[ryan2399]

Posted on May 17, 2011 at 12:44

I have a tech support request in to IAR to try and get to the bottom of this.

I can't see how the binaries would be incompatible... It's most likely trying to program the FLASH via EWARM with a JTAG/SWI device that is the issue. I had this kind of problem during flashing/debugging when I first tried v5.20 (before I saw the tech note from ST). I would think that doing a ''field upgrade'' via USB or serial port should work. But I'll have to wait and see what IAR has to say about that. Ryan

[janis]

Posted on May 17, 2011 at 12:44

As what I can think, the problem could be with two things.

1)Pre Y chips doesn't have RAM and/or FLASH size registers written in factory. I suppose that they are used to check chip type. Also the identification register is missing. 2)I have noticed a misbehavior in TMS TAP. When going trough CAPTURE-IR state lower 2 bits are not always ''01'', but last instruction is shifted out instead. This could cause some problems to determine number of TAPs in JTAG chain. However, I haven't seen any problems working with 5.20 IAR and older chips.

[ryan2399]

Posted on May 17, 2011 at 12:44

Well, I asked IAR if it was programming/debugging via EWARM that was the issue or if the binaries generated by v5.20 are not compatible.

The answer I got back was that the binaries generated by v5.20 may not be compatible with rev. B & Z. Ryan

[jj]

Posted on May 17, 2011 at 12:44

> Also the identification register is missing.

IAR 5.20 & ''Pre Rev Y'' are immediately detected - IAR ''squawks'' and steers you toward Rev Y. The justification/explanation is cryptic and sheds no light. > one can not generate binaries with 5.20 that are compatible with pre rev Y Same observation as lanchon - that conclusion is not supported by IAR's very brief caution. Did someone tell you this? We have successfully programmed pre Rev Y with 5.20 - although code is relatively small and exercises less than 1/2 of library functions. We are fearful that our shipments may be ''ticking time bombs'' - ST and IAR's advisories - while lawyerly - provide insufficient guidance to ST32 users with parts in the field. The brief advisories from both fail to address valid user fears that earlier versions of IAR (and perhaps other IDEs) may also contain defects - maybe some awaiting discovery! Restricted disclosures provides little comfort... If it is true that pre Rev Y parts are ''safe'' when debugged/flashed with pre Ver 5.20 IAR - then IAR likely knows which change/addition/modification has brought about the pre Rev Y sensitivity. Failing to share this with the user base may compromise our ability to take proper/evasive action...