Bug Report for STM32F10x_StdPeriph_Lib_V3.3.0

[tobias23]

Posted on June 22, 2010 at 13:21

Bug Report for STM32F10x_StdPeriph_Lib_V3.3.0

[lowpowermcu]

Posted on May 17, 2011 at 13:55

Hi hoto,

Could you tell me where you find the SystemInit_ExtMemCtl_Dummy() ?

Is it created by default by TrueStudio.

Mit besten grüssen,

MCU Lüfter

[tobias23]

Posted on May 17, 2011 at 13:55

Hey lowpowermcu,

you will find this symol in:

STM32F10x_StdPeriph_Lib_V3.3.0\Libraries\CMSIS\CM3\DeviceSupport\ST\STM32F10x\startup\TrueSTUDIO\startup_stm32f10x_hd.s

And you are right this code seems to be written by the TrueStudio developers. So maybe this bug should be reported to them. Whatever those files are part of the StdPeriph_Lib_V3.3.0 so ST Microelectronics should care about it.

I ain't using TrueStudio to develop, I use Eclipse Galileo and the latest version of CodeSourcery Toolchain.

Maybe

TrueStudio is generating compiler commands to link this stuff properply, but it is fact that this code can't work under normal circumstances, because the function ''SystemInit_ExtMemCtl'' is declared as static in the driver lib and therefore can't (normaly) be called from this startup script.

Correct me if I'm wrong.

Regards,

Hoto

[marouanbm]

Posted on May 17, 2011 at 13:55

Hello hoto,

In system_stm32f10x.c, there's a define that should be uncommented to be able to use the external memory:

#define DATA_IN_ExtSRAM

if DATA_IN_ExtSRAM is not defined, the dummy function declared as weak in the startup file will be used. 

.ExternalClass9B8B1F6F907647F0BCB8C6602B2346D0 p.MsoNormal, .ExternalClass9B8B1F6F907647F0BCB8C6602B2346D0 li.MsoNormal, .ExternalClass9B8B1F6F907647F0BCB8C6602B2346D0 div.MsoNormal {margin:0cm;margin-bottom:.0001pt;font-size:12.0pt;font-family:'Times New Roman';} @page Section1 {size:612.0pt 792.0pt;margin:72.0pt 90.0pt 72.0pt 90.0pt;} .ExternalClass9B8B1F6F907647F0BCB8C6602B2346D0 div.Section1 {page:Section1;}

Hello I'm not sure where I can submit a Bugreport, so I do it on this forums.

Related Files: system_stm32f10x.c, startup_stm32f10x_hd.s (True Studio)

Bug Report:

There is a problem when you want to use the external RAM as HEAP/STACK Memory, explained in example ''SRAM_DataMemory''.

In the startup_stm32f10x_hd.s on line 72 we perform a branche to ''SystemInit_ExtMemCtl'' this function can't be called from this code because it is declared as static in system_stm32f10x.c on line 153. This will result in a branche to ''SystemInit_ExtMemCtl_Dummy'' which is doing nothing but jumping back to the call function.

Now the code starts to copy stuff into RAM which is not initialized! When we branche (in assembler file) in line 107 to __libc_init_array we will have a crash due to push and pop of registers on the stack which is in not initialized memory!

What I've seen the function ''SystemInit'' calls the Function SystemInit_ExtMemCtl. But since we never reach this code, it's useless.

Your readme file says that you have tested this with several boards. I can't believe that you really have tested it; since this code can't work... it's impossible.

Solution: Don't make the SystemInit_ExtMemCtl static! Or call the SysInit at the very beginning of the startup code.

All right, is there an official way to report this bug?

[lowpowermcu]

Posted on May 17, 2011 at 13:55

Hi hoto,

I have just looked at the code but I didn't run it.

If I have well understood, the start-up file will call the system_init() but not

SystemInit_ExtMemCtl(). So even if SystemInit_ExtMemCtl() is static, the start-up will not call it but system_init(). Isn't it ?

With regards,

MCU Lüfter

[tobias23]

Posted on May 17, 2011 at 13:55

This is correct, but exatly here is the problem. This define adds the following to the code:

#ifdef DATA_IN_ExtSRAM

static void SystemInit_ExtMemCtl(void);

#endif /* DATA_IN_ExtSRAM */

This function is static. So the startup file cannot call this function. I've seen that the dummy is added as weak, so if this function wouldn't be static it would overwritte the dummy. Since it is ''static'' it can not overwrite it.

Found like 5 more Bugs which are not in code of TrueStudios files but in the Driver Lib itself. But I'm really to lazzy to report those since noone seems to care about.

And I found also some examples in the Lib that configures the hardware out of spec.! (p.e. the SRAM example) Well it works pretty good but my opinion is to never-ever set any control registers to ''reserved'' values! Because with a new revision of the MCU you may get in troubble.