IAR 5.20 and pre silicon rev Y - revisited

[edware]

Posted on March 30, 2009 at 11:09

IAR 5.20 and pre silicon rev Y - revisited

[jj_it]

Posted on May 17, 2011 at 13:04

Had the same issue/question with the 103 series. This ''re-classification'' of devices is tricky to explain (hard also for ST to understand) & we ''solved'' it by only ordering/accepting new Rev ''A'' STM32F103 devices. (these also require lower power)

Ideas:

a) if you have a device on a pcb - download simple code & see if IAR5.2 ''squawks.'' (we're not told if this squawking is based upon a simple ''read'' of Rev - or a more advanced method) I do NOT know if the absence of ''squawk'' means that you are ok...

b) read latest device spec & errata - see if new Rev exists. If a newer Rev exists I'd order it only.

c) IAR5.3 is out - don't know how/if this STM32 issue is handled by newest IAR.

The attention/focus is on the larger/newer devices - issue is complex - you may have to place small order of multiple Revs - insert each - and then run code which ST/IAR describe as ''problematic'' under IAR5.2...

[edware]

Posted on May 17, 2011 at 13:04

We have a product using Rev Z STM32F101C6 devices.

From the IAR website the issue with rev B, and rev Z mask revisions of medium density devices is explained:

http://supp.iar.com/Support/?note=50011

The problem arises from the reclassification of Access Line Devices by ST around September 2008.

Version 9 of 13586.PDF (medium density access line devices) includes the STM32F101C6

Version 10 of 13586.PDF (medium density access line devices) does not include the STM32F101C6. From this date the STM32F101C6 has become a low density device.

My question is:

Is the STM32F101C6 Rev Z device we have in our product affected by the IAR 5.20 Compiler issue?

Thanks

Ed

Note : ST Technote 14898.pdf does not address this ambiguity.

[ This message was edited by: edware on 02-03-2009 00:26 ]

[jj_it]

Posted on May 17, 2011 at 13:04

Hi STOne-32-

Thank you - sorry but the issue is ''tricky'' and made more so by ST's repeated use of ''6'' in part numbers. (i.e. C6T6, R6T6 - not best idea)

So - for those seeking to purchase C4xx, C6xx, R4xx, R6xx - in STM32: 101, 102, 103 families - AND using IAR5.2/5.3 - are we best advised to order Rev ''A'' STM32 devices? Forgive me - disty's are ''not'' up to speed on this issue - we ''need'' STOne-32 to clarify. With the ''changing'' location (part to part) of the Rev markings it is indeed a challenge to explain/request that disty ''verify'' JUST which Rev STM32 are ''in stock!''

(Further - what becomes of Rev ''B'' & ''Z'' in disty stock? As only the newer compilers are effected - seems that B & Z will persist in stock)

Appreciate your interest and considered response. (please don't hate me...)

[16-32micros]

Posted on May 17, 2011 at 13:04

Quote:

My question is:

Is the STM32F101C6 Rev Z device we have in our product affected by the IAR 5.20 Compiler issue?

Thanks

Ed

Note : ST Technote 14898.pdf does not address this ambiguity.[ This message was edited by: edware on 02-03-2009 00:26 ]

Dear Ed, all,

Only revB and revZ of Medium Density is affected by these compilers issues, It was true that ''6'' (32KFlash) devices are now classified into the Low-density Family because Now at our production we have a new silicon (revA) for these Low-density devices. Therefore all revB and revZ having suffixes ''6'' for the Flash size are affected too.

Hope this is clear now.

Cheers,

STOne-32.

[16-32micros]

Posted on May 17, 2011 at 13:04

Hi edware,

There is no plans to fix this limitation. However, if your external board is using JTAG or SWD to upgrade/load the device, you can read this register.

Cheers,

STOne-32.

[edware]

Posted on May 17, 2011 at 13:04

Thanks for your input jj.sprague & STOne-32,

We had planned to read the device ID with our application code to determine if our (external) board loader had loaded the correct revision silicon, however there is a current errata for the low and medium density devices which prevents user software from reading the device ID.

Q/ Does ST plan to correct this shortcoming, and if so, when?

Thank you.

[edware]

Posted on May 17, 2011 at 13:04

Thanks for your response STOne-32

It helps with our planning to know this.

Best regards

Ed

[jj_it]

Posted on May 17, 2011 at 13:04

@Ed

Yikes - you're in about the same (leaky) boat as my firm.

Re: read of device ID (via the application). Recall that IAR 5.20 ''squawks'' just prior to downloading via JTAG to a ''suspect'' device. So in JTAG mode - at least - the device

[edware]

Posted on May 17, 2011 at 13:04

@jj

Thanks jj - I agree. Our intent was to manage already released products.

We were trying to manage two separate issues:

1/ Product in the field using old STM32 die revisions. We wanted to ensure we don't load new code into the devices (via

[jj_it]

Posted on May 17, 2011 at 13:04

@Ed-

Wouldn't it be better to order newest/improved (lower power) Rev ''A?''

Silent is ''how long'' the older Revs will persist - why even expose yourself to this worry?