STM32 silicon errata

[lanchon]

Posted on October 06, 2008 at 16:30

STM32 silicon errata

[jj]

Posted on May 17, 2011 at 12:17

bruno-

Thank you - unfortunately reading the Rev. Code ''electronically'' requires firms such as mine to order parts, design/produce pcbs, then install the STM32 & other necessary components. This is not good business practice - how do we buyers or ''anyone'' throughout the Distribution chain KNOW what Rev is stocked - and what Rev we are buying? Rev identification via electronic means is NOT a proper solution...

[mark4]

Posted on May 17, 2011 at 12:17

I don't understand this either. I have LQFP64, so rev is in the lower right. One of mine is 'C07'. The errata sheet from July 08 does not mention any 'C' revision. It also has a 'Z' in the upper right but that's not supposed to be the location for rev, so it may mean something else.

Mark S.

[brunoalltest]

Posted on May 17, 2011 at 12:17

The revision code on the package is confusing.

But you can check what´s your revision code on the DBGMCU_IDCODE register. The info about it is on the Reference Manual(RM008) on page 651 Also, the Firmwary Library has a function to read the revision code, it´s described on the page 514 of the Firmware Library Manual(UM0427)

[brunoalltest]

Posted on May 17, 2011 at 12:17

Of course ST should explain it. You´re absolutely right.

Until they don´t do if you want to know. I´ve just tested one STM32F103RB(64 pins, 128kb of flash). On the package it has ''C03'' written on the bottom right corner and ''Z'' on the up right corner. When I check it electronically, the code 0x2001 which is ''Z''. So I assume the Errasheet is wrong, and the revision code for the 64 pin devices is on the up corner.

[design5]

Posted on May 17, 2011 at 12:17

Bruno and others:

Thank you to everyone for your comments, ideas, and suggestions. I am also concluding that the upper top Z letter is the actual revision, and the lower Cxx stamping is not the revision number, but may be some manufacturing lot within the revision. This would not be the first time that ST documentation (i.e. the Errata) has been wrong. One posting from IAR indicates the time-sequence for revisions was B then Z then Y, and that Y is supposed to be the latest. Don't you love these non-sequential, and non-logical, systems. See Q&A #1 as follows: http://supp.iar.com/Support/?note=50011&from=search+result Observe that the ST Moderator has been silent for a while on this topic. Perhaps he is researching the topic for the correct answer. Garry.

[design5]

Posted on May 17, 2011 at 12:17

To all STM32 Users:

With the help of all of your comments, I believe I have solved the STM32 Revision Code confusion. The Errata from ST is INCORRECT for the 64-pin package Rev Code location on the stamping. The other package codes are shown correctly. See the corrected Errata attached hereto. If the attachment is not visible, you may obtain it from the following location: http://members.shaw.ca/garryanderson/ The time sequence of STM32 Revision Code releases was B, then Z, then Y. Perhaps next revision ST will get back into sync with Rev E, then F, etc. It appears that most Keil kits have Rev Z devices (bad USART3-GPIO connection) and most IAR devices have Rev B (first silicon). ST has an offer to exchange the IAR board for Rev Y Silicon if the Board Rev is 5.2 or greater and you are experiencing problems. See ST's technical note TN0067:

http://www.st.com/stonline/products/literature/tn/14898.pdf

I have discovered, on my Keil Kit, that the Rev Z parts have a problem with the USART3-GPIO connection (see my Errata), but the earlier Rev B parts did not have this problem. The Rev Y parts should have fixed the problem but I will not know until tomorrow when I get my Keil ''Z'' device replaced with a Rev ''Y'' device. Digi-Key has stock on the latest Y devices (which they think, and we thought, was rev C). When you order free samples from ST, those samples are shipped no charge from Digi-Key (ST covers the costs). Perhaps the ST moderator would like to post a comment soon as to why the Errata has been incorrect since May 2008. Are we the first to have found and reported this problem, and if not, then why has ST not corrected their Errata as I have done? Good questions, eh? Garry Anderson [ This message was edited by: design6 on 19-09-2008 08:51 ]

[jj]

Posted on May 17, 2011 at 12:17

Garry-

Nicely reported/detailed - your efforts are appreciated & valued by many. Another case of we ''unwashed'' helping each other. (yea - forum users!) Two important issues remain: a) As you referenced DigiKey - have you checked/confirmed their recent extreme price increase? No explanation has been forthcoming - my firm is fearful that - without strong protest - this behavior may expand. Non STM ARM devices have received no such increases. b) How - or even ''do'' the Rev. markings present within the higher-capacity, FSMC devices? Does any of your report apply? Thanks again to all who contributed - silence is not our ally...

[lanchon]

Posted on May 17, 2011 at 12:17

> Whatever happened to revision A in the Errata? Perhaps it has too many bugs to mention.

> Does this mean that revision C is in the same class as A, with too many bugs to mention? haha, that was funny! rev A was an early engineering sample. I think it was only given to dev board manufacturers (and some key customers probably) to test their boards for the stm32 launch. it was never meant to devel apps on, so it make sense there's no errata for it. > few posts down you can read about ST & IAR warning STM32 users NOT to use Rev B or Z! that's not really it, it says not to use rev B or Z with a particular version of IAR. probably just a TAP/debugger issue only tool vendors would care about. but enough defending ST. it's really amazing how they can be so very scarce with the info; for example people were asking if the binaries produced by the new IAR would work on old revs if programmed by bootloader for instance, because the note isn't clear (actually you're forced to ask cause the note doesn't begin to explain a thing), but no answer, nada, zip, nil. and the debate on flash security has been going on for ages. it really amazes me sometimes how inaccessible the devel team is; it's like we're on different solar systems, I don't see how that can be good for ST.

[jj]

Posted on May 17, 2011 at 12:17

lanchon-

Always fun to read your posts (don't be afraid to ''loosen up'' a bit). Now it is not in our best interests to believe that ONLY IAR Rev benefits from the newest, Rev Y. We are never told what degree of testing, verification is done by ST and by toolmakers. Is it not possible that - in this case - at this time - IAR has ''leaped'' the pack and found weaknesses with older Rev B & Z? Further - wouldn't you prefer the newest release - (we must have some trust) in the belief that ''many'' bugs and errata would have been corrected - and that the newest represents the best? Forgive me ST - one wonders if the ''rush'' to FSMC has caused/contributed to the less than excellent revision ''management?''

[disirio]

Posted on May 17, 2011 at 12:17

According to the DBGMCU_ICODE register my Olimex board has a revision B, I am so happy ... 😉

Open On-Chip Debugger > mdw 0xe0042000 1 0xe0042000: 20006410 > Giovanni --- ChibiOS/RT

http://chibios.sourceforge.net