Running application in "Release mode causes errors"

[HNall.1]

Hi all,

I'm trying to profile my application which running on STM32F469IH6 micro-controller.

I'm able to run the application in debug mode and able to see the timings of the applications.

But In generally running application in release mode will have more optimizations included compared with the debug mode. But If I run the application in Release mode then i'm encountered with below error.

Below is log at the time of running application in release mode:

STMicroelectronics ST-LINK GDB server. Version 5.6.0
Copyright (c) 2020, STMicroelectronics. All rights reserved.
 
Starting server with the following options:
        Persistent Mode            : Disabled
        Logging Level              : 1
        Listen Port Number         : 61234
        Status Refresh Delay       : 15s
        Verbose Mode               : Disabled
        SWD Debug                  : Enabled
        InitWhile                  : Enabled
 
Waiting for debugger connection...
Debugger connected
      -------------------------------------------------------------------
                       STM32CubeProgrammer v2.5.0-RC1                  
      -------------------------------------------------------------------
 
ST-LINK SN  : 066DFF535254887767171939
ST-LINK FW  : V2J37M26
Board       : 32F469IDISCOVERY
Voltage     : 3.27V
SWD freq    : 4000 KHz
Connect mode: Under Reset
Reset mode  : Hardware reset
Device ID   : 0x434
Revision ID : Rev A
Device name : STM32F469xx/F467xx
Flash size  : 2 MBytes
Device type : MCU
Device CPU  : Cortex-M4
 
 
 
Memory Programming ...
Opening and parsing file: ST-LINK_GDB_server_a09660.srec
  File          : ST-LINK_GDB_server_a09660.srec
  Size          : 676208 Bytes
  Address       : 0x08000000 
 
 
Erasing memory corresponding to segment 0:
Erasing internal memory sectors [0 9]
Download in Progress:
 
 
File download complete
Time elapsed during download operation: 00:00:12.201
 
 
 
Verifying ...
 
 
 
 
Download verified successfully 
 
 
Debugger connection lost.
Shutting down...
 

Thanks in advance.

[HNall.1]

Hi @TDK ,

Correct me if i'm wrong. Here 672.9KB of my code sections resides in FLASH memory .

My assumption is that at the runtime, entire code section will be loaded into RAM. This is usual behaviour when I work with micro-processors(DISK to RAM). I feel the same with Micro-controllers (FLASH to RAM).

In my case,STM32F496IH6 has only 320KB RAM.​ And I feel it's impossible to fit 672.9KB data from FLASH to RAM.

[TDK]

On most (all?) STM32 families, the CPU can run instructions directly from FLASH and this is typically what it does unless you go out of your way to tell it to run from RAM.
The only thing that gets moved from FLASH to RAM on startup are initialized, non-const variables. Uninitialized variables aren't stored in FLASH at all, but space is made for them in RAM during startup.

[HNall.1]

Hi @TDK​ ,

If CPU directly run instructions from FLASH then ideally there will no issue with code size. I will try to figure out why my application was not running in RELEASE mode and let you know if I find a solution.

In second paragraph, you mentioned uninitialized variables are not stored in FLASH. But it seems not true. Uninitialized variables are resides under .bss section. And this will be created in both FLASH and RAM. I posted one question similar to this. Please take a look at map file from this post.

https://community.st.com/s/feed/0D53W00000FzIanSAF

​In the MAP file you can see .bss section was created in both FLASH and RAM.

[TDK]

Obviously if you tell it to be stored in the read-only section, that is where it will be stored.

You're telling it to store an uninitialized, non-const array in a read-only section, which is nonsensical.

Remove the attribute, use a default linker script, and it will indeed not store uninitialized arrays in FLASH.

[HNall.1]

​Hi @TDK​ ,

I have not used any attribute and I have default linker script only. Not changed explicitly anything.

Also, Did you get a chance ​to look at map and linker filers in above mentioned link?

If you see the map file, it has .bss sections created in both FLASH and RAM.​

[TDK]

> I have not used any attribute and I have default linker script only. Not changed explicitly anything.

One of us is definitely missing something.

We're just running in circles now. I think my first couple of replies to this post is about all I can help.

You're trying to use FLASH as RAM. You can't do that.

Good luck.

[hs2]

Your assumption is not right. Usually MCUs run code from internal or external flash/EEPROM and only with dedicated measures code is relocated to RAM to run from there.

[hs2]

Your assumption isn’t right. Usually MCUs run code from internal/external flash or EEPROM. With dedicated measures (usually only parts of) code can be relocated to RAM and executed there. As you see internal RAM is a limited resource..

[HNall.1]

Hi @TDK​ , @Community member​ , @Rados?aw​ 

Particularly for this problem i have created a STM32 Project by including below simpler code in main.c file.[@TDK​  I found no issues in actual source project thats way i have created simpler project to showcase this issue]

#include <stdio.h>
 
int main(){
 
	int a=10, b=20;
	printf("Sum=%d \n", a+b);
	return 0;
}

Here also i'm facing the samw prolem. It was running perfectly fine in Debug mode. But in release mode i'm seeing below error.

STMicroelectronics ST-LINK GDB server. Version 5.6.0
Copyright (c) 2020, STMicroelectronics. All rights reserved.
 
Starting server with the following options:
        Persistent Mode            : Disabled
        Logging Level              : 1
        Listen Port Number         : 61234
        Status Refresh Delay       : 15s
        Verbose Mode               : Disabled
        SWD Debug                  : Enabled
        InitWhile                  : Enabled
 
Waiting for debugger connection...
Debugger connected
      -------------------------------------------------------------------
                       STM32CubeProgrammer v2.5.0-RC1                  
      -------------------------------------------------------------------
 
ST-LINK SN  : 066DFF535254887767171939
ST-LINK FW  : V2J37M26
Board       : 32F469IDISCOVERY
Voltage     : 3.27V
SWD freq    : 4000 KHz
Connect mode: Under Reset
Reset mode  : Hardware reset
Device ID   : 0x434
Revision ID : Rev A
Device name : STM32F469xx/F467xx
Flash size  : 2 MBytes
Device type : MCU
Device CPU  : Cortex-M4
 
 
 
Memory Programming ...
Opening and parsing file: ST-LINK_GDB_server_a10292.srec
  File          : ST-LINK_GDB_server_a10292.srec
  Size          : 4920 Bytes
  Address       : 0x08000000 
 
 
Erasing memory corresponding to segment 0:
Erasing internal memory sector 0
Download in Progress:
 
 
File download complete
Time elapsed during download operation: 00:00:00.359
 
 
 
Verifying ...
 
 
 
 
Download verified successfully 
 
 
Debugger connection lost.
Shutting down...
 

Thank you,

Hari

[waclawek.jan]

In mcu, you never return from main().

JW