STM32F205VC - embedded SRAM Mapping

[Stefan Strobel]

Posted on January 29, 2018 at 10:23

Hi,

we are using the STM32F205VCT7 controller which should have 256k embedded flash and 96k embedded sram.

I am wondering now where the available SRAM is mapped.

It seems to be splitted into SRAM1 and SRAM2 where SRAM2 starts at 0x2001C000 and goes up to 0x20020000

But all memory mappings i found are showing the full 128k SRAM.

I have not found any memory mapping for the smaller devices like the STM32F205VC.

Is there 96k memory from 0x2000000 up to 0x20017FFF and then 32k ''nothing''.

Or is there a gap between SRAM1 and SRAM2?

==> SRAM1 from 0x20000000 to 0x20013FFF (80k)

==> SRAM2 from 0x2001C000 to 0x2001FFFF (16k)

==> nothing from 0x20014000 to 0x2001BFFF

And what will happen, if a non existing memory is accessed?

Does anyone know where to find this information?

Thank you.

Regards

Stefan

[Uwe Bonnes]

Posted on January 29, 2018 at 10:50

At least all STM32F2 are the same die. See the <Die> entry in the cubemx STM32F2XX..xml files. So at least all STM32F2 are produces with the same amount of memory. However the smaller chip announcing less ram than the big chip have:

- perhaps the surplus memory disable by some fuse

- maybe are labeled as a small chip as memory was tested bad or not tested at all

- or mybe the surplus memory functioning perfect.

SRAM2 however is always mapped at 0x2001C000, see the stm32f2XXxx.h headers.

[Stefan Strobel]

Posted on January 29, 2018 at 13:24

Thanks for the reply,

as far as I tested the surplus memory works fine.

I can write into the whole 128k and read it back afterwards...

Writing outside of the 128k there is a Hard Fault exception fired...

==> yeah finally enough memory  (at least more than I payed for)

But I am a bit worried using memory of which the manufacturer says it is not there...

It seems to be better just using the memory which STM promotes...

But as I described it is not that easy to find out where the 'smaller' SRAM is said to be mapped to.

I looked at the linker script implementation of cubeMX and Keil µVision just to find out where they think the SRAM is mapped to.

==> Most of the implementations assume there is SRAM from 0x20000000 to 0x20018000 ==> 96k

The EWARM implementation generates a linkerscript that mapps SRAM from 0x20000000 to 0x20020000 ==> 128k

So this does not seem to match whats written in the datasheet or what you found in the 

stm32f2XXxx.h headers (SRAM2 at 0x2001C000).

So is this just a marketing trick to make us buy the same chip with a different label for more money?

Or is there a risk that my software(and all big EWARM projects) stops working in years, when the chips have been relayouted and the additional memory is fused, removed or broken...

And if so which part of the memory would you use?

Regards,

Stefan

[waclawek.jan]

Posted on January 29, 2018 at 16:10

I'd suggest to try to contact ST directly, possibly through the web support form.

JW

[Uwe Bonnes]

Posted on January 29, 2018 at 16:44

The memory starting at 0x20000000 up to the announced size in the datasheet  must have been tested good by STM. If you only use that part, you are on th safe side.

[Tesla DeLorean]

Posted on January 29, 2018 at 20:38

This is a topic that has come up before. ST has described the memory regions in two different inconsistent ways in linker scripts, and projects. SRAM2 has different connectivity via the bus matrix, but on the other hand no description of the parts says the 96KB is not continuous. Having a hole in the main SRAM would be highly undesirable.

The conclusion of the prior discussions, as I recall, is that it is safe to assume the die has 128KB of SRAM, and that it is tested/functional. The die also has 1MB of FLASH, but no tester time has be applied to the sectors beyond 256KB on the 256KB marked part. A location in the ROM (OTP/FLASH) has the FLASH size programmed along with the device unique number containing die location and batch details.

[Stefan Strobel]

Posted on January 30, 2018 at 10:21

Thanks a lot for your reply.

I still think it´s a bit scary that the documentation of STM is missleading and inconsistent.

But this might be an argument for STM to never change their memory mapping on these controllers, stop testing or fusing the surplus memory...

...if they do anyway it will break most of the projects created with their own tools...

So thanks a lot.

I can sleep a bit better now.

regards

Stefan

[waclawek.jan]

Posted on January 30, 2018 at 10:32

Which tools? You mean Cube? I wouldn't use that up as an argument.

Repeat, contact ST.

JW