Double memory in STM32F101v8T6?

[bala_jss]

Posted on September 29, 2008 at 19:20

Double memory in STM32F101v8T6?

[bala_jss]

Posted on May 17, 2011 at 12:46

Hi,

I am using a STM32F101V8T6 on a Ride IDE. Although the datasheet states it has 10k internal RAM in it, the Data size reported in Ride is 0x5000 (20k ) Sure, this should be a problem with Ride, but I ran a simple memory test loading unique numbers starting 0x20000C80 to 0x20004E00 (thats about 16k RAM) and they seem to be fine when I read them! This suggests that there is more RAM than the datsheet states. Am I missing something here? If not, I am happy to set my stack to the end of 10k memory in future, but I am just curious to know if this is a known problem and whether some silicon revisions have this as we have some units getting out of the door. Thank you in advance Chip Details STM32F101 V8T6 Z 220FB 93 MLT 22 745 Program Memory Map 0x20000C80 - (thats wher my usrstack begins, which i don't use) 0x20004E00 - My stack seems to require about 0x200 bytes stack starts from _estack = 0x20005000

[jj]

Posted on May 17, 2011 at 12:46

interesting but doubtful:

1) Memory ''Folding'' beyond 10KB: Are you sure that your write to ''relative'' ram location 10,000 (2710H) is not over-riding your earlier write to ''relative'' ram location 0 - and so on? Have you taken special care to choose unique numbers - especially at the critical ''fold'' (1/2 way) point? 2) Ride folding per above 3) Useful to see if this observation continues using a different toolchain. (IAR provides 32KB KS version, free) 4) Lastly - ''if'' you bought your STM32 from Digi-Key (recently) perhaps you are the ''first'' to discover the ''poorly documented'' Value Added provided by this disty to justify their 2X price increase/outrage...

[lanchon]

Posted on May 17, 2011 at 12:46

maybe ST run out of 10K parts and is selling more capable parts with a downgraded label. or perhaps ST is waiting for demand of the small parts to ramp up before beginning production, and meanwhile they are just relabeling.

[jj]

Posted on May 17, 2011 at 12:46

I believe you - but not your results.

Plz humor me - clear your entire Ram range - from 0 to 20KB top. Then write several K bytes 0xff into beginning of upper half (fold point) of your ram. If you then examine the beginning of ram (lower half) I believe that you will find it contains the 0xff - not the 0x00 with which you seeded. The merit of this test is the clarity of memory examination - plz try & report. Any interested parties with parts are invited to try/comment as well... *** best for last - don't sell lanchon short - IF he's guessed right the excess ram you report ''strongly'' implies that you have extra flash too! Have you examined this - if this is so lanchon is genius... [ This message was edited by: jj.sprague on 26-09-2008 13:53 ]

[bala_jss]

Posted on May 17, 2011 at 12:46

@ jj.sprague

1)Yeah the numbers are unique, also confirmed by testing with a few more STM32F101v8T6 3)Keil seems to set the RAM space as 10K, but IAR sets it to 20K!!

[16-32micros]

Posted on May 17, 2011 at 12:46

Hi all,

This RAM area is not ensured by ST to be functional because simply it is neither tested nor fully qualified at our production lines. Hope makes it more clear now. Cheers, STOne-32.

[jj]

Posted on May 17, 2011 at 12:46

STOne-32:

Thank you. Please clarify - the specified amount of ram ''is'' fully tested and qualified - it is just the ''excess/unspecified'' area of ram that is untested/unqualified. Is this statement correct? Is this situation likely to extend to many/most STM32 devices? Lastly - might this result extend to ''Flash'' memory as well? Is it possible that we get ''some'' extra flash via the same mechanism?

[lanchon]

Posted on May 17, 2011 at 12:46

interesting comment by ST1... so here's an extension of the hypothesis:

ram and flash can cover an important fraction of the silicon area, so it makes sense that they be segmented into (partially) relocatable chunks. during testing the chunks are validated or marked as failures; this determines the ''higher'' part number each chip can possibly be. this info is combined with market demand to settle each chip into a specific part number by programming a few hidden flash bits controlling the relocation. relocation would probably be restricted and very simple. for example, a 128KB flash can be relocated in segments of 16KB simply by XORing the upper 3 address bits with a 3-bit constant. this is fast and will recover most chips to their higher possible bin provided faulted chunks are sparse. and it will leave the faulted chunks accessible. an even simpler relocation would just OR the 3-bit constant. this can be used to actually reduce the usable memory of totally good parts to ensure customers pay for the memory they use. it will also render bad chunks inaccessible if they are in the ''lower half of each address bit'', but it will leave them accessible otherwise. so... they can supply the whole memory range with one 128K silicon. when yield of the bigger memory parts and market demand for the little memory parts are both high, then it's time to introduce a new silicon and feed the demand with two silicon variants, say 128KB and 32KB. just realized why microcontroller makers are so eager to offer many memory configurations...

[jj]

Posted on May 17, 2011 at 12:46

This may reduce to an applications issue - assume the following:

a) Application needs/benefits from more ram (the unspec'ed, excess ram) b) User discovers - then reads/writes successfully to this ram (1K times) c) User confirms that ''some excess'' is available on 90%+ of current lot Is it possible/likely that ST's testing detects failure at the ''extremes'' - temperature, voltage etc? Does this imply that our use over better, narrower conditions may succeed? With the proviso that ''this excess'' may not occur again - would you forum users even attempt use of unspec'ed ram?