STM32 silicon errata

lanchon · ‎2008-10-06

Posted on October 06, 2008 at 16:30

lanchon · ‎2011-05-17

Posted on May 17, 2011 at 12:17

> Is it not possible that ... IAR has ''leaped'' the pack and found weaknesses with older Rev B & Z?

yeah but it doesn't make sense that ST publishes a note saying that only IAR version xx is affected. the newest IAR probably uses some obscure debug feature for the first time and that brought the mistake to light. maybe the particular piece of debug code wasn't released to market till ST had a solution.

> wouldn't you prefer the newest release ... in the belief that ''many'' bugs and errata would have been corrected ... and that the newest represents the best?

apparently not, design6 says that Rev Z has bugs Rev B doesn't!

> my Olimex board has a revision B, I am so happy ...

mine too, and I'm happy with it. I bought it pre-Y so it might be for the best that it's not a Z after all...

design5 · ‎2011-05-17

Posted on May 17, 2011 at 12:17

Hello fellow truth-seekers:

It is a very sad day indeed for me today. I had the STM32 Rev Z device in my Keil Kit replaced with the latest Rev Y silicon, then eagerly tested USART3 to see if it worked correctly in Rev Y. Alas, however, I was most disappointed to discover that I could not get USART3 TX activity coming from pin PB10, as it should, with the new CPU. It appears to have the same problem as Rev Z has. At the moment, I have only been able to get USART3 TX data working in Rev B silicon.

Would somebody out there please see if they can get USART3 data coming out the alternate pin PB10 (without remapping) in a Rev Z or Rev y CPU. I sure would appreciate confirmation that I am not going crazy here.

By the way, I also scanned the legend markings in my Rev Z and Rev Y packages then added those scans to the ''revised'' STM32 Errata which I have started to maintain. You may find my latest Errata at my web-site:

http://members.shaw.ca/garryanderson

Also, I have attempted to attached my ''revised'' Errata to this posting.

I anxiously await some independent testing of USART3 on PB10.

Thanks to all of your support.

Garry Anderson.

lanchon · ‎2011-05-17

Posted on May 17, 2011 at 12:17

so... I'm looking at my pure uncut vintage revBs here; let the bidding war begin! 🙂

jj · ‎2011-05-17

Posted on May 17, 2011 at 12:17

design6-

I'm sorry for you - maddening. Is it possible that our tests/confirmation would be more valuable if we knew more about your various set-ups and function selections? I was thinking of setting up the most basic test possible - exercising only USART3 - do you think that simple test would help you? (now have only Rev Z & Y)

design5 · ‎2011-05-17

Posted on May 17, 2011 at 12:17

To JJ and other fellow programmers:

JJ, thank you for the offer to build a sample program. I would appreciate that very much.

If anybody is willing, I would like some other ''eyes'' to check the main() function I have prepared in the attached ZIP file. You can even build the project and test it on your kits. I have a Keil Kit, so I don't know how to create a project in I.A.R. but the readme.txt file will provide some assistance.

If anybody figures out what is wrong with my main() function, or how I can get USART3 characters coming from PB10, I would really like to know.

Thanks again for your comments and assistance.

Garry Anderson.

16-32micros · ‎2011-05-17

Posted on May 17, 2011 at 12:17

Hi Gary,

This is a follow-up of your new post

http://www.st.com/mcu/forums-cat-7424-23.html

I had my eyes blind when I looked that in your code and I haven't paid attention that you have simply enabled all Peripherals clocks. Sorry again for the confusion. I will assure you shortly ( by Tomorrow) the final status. Thanks for your comprehension.

Cheers,

STOne-32.

16-32micros · ‎2011-05-17

Posted on May 17, 2011 at 12:17

Hello Garry, all,

Thank you for your efforts and your valuable inputs, However I confirm that we have no issues with USART3 TX and RX pins on all silicon revisions (B,Z and Y). I suggest that you have something on your hardware or board forcing externally the TX pin to defined state.

Thank you for the LQFP64 Package errors, This will be corrected on our Errata-sheet (September version) next week latest and also we will have a new gift to our Forums users by a new products announcement 🙂 Keep in touch !

cheers,

STOne-32.