ポジティブワン株式会社

6.オブジェクトモジュールやアプリケーションのバイナリーファイルのサイズはどうやってみれますか？

6.オブジェクトモジュールやアプリケーションのバイナリーファイルのサイズはどうやってみれますか？

After building a project, object files and an application binary file (typically in ELF format) exist under the Debug or Release folder in the Project Explorer view file tree.

To study the properties (such as code or data size) of an object file, open the Properties view and select the object file in the Project Explorer view. The Property view will display a large number of properties, including code and data sizes of the object module.

To study the properties (such as code or data size) of a linked application binary file, open the Properties view and select the ELF file in the Project Explorer view. The Property view will display a large number of properties, including code and data sizes of the complete application.

Data is normally stored in the "data" segment and code is normally stored in the "text" segment.

To open the Properties view, select the menu command "Window, Show View, Other...", expand the General folder, and double click on "Properties".

5.浮動小数をsprintfでフォーマットしようとしたときにHardFault_Handler() がコールされる

 

5.浮動小数をsprintfでフォーマットしようとしたときにHardFault_Handler() がコールされる

HardFault_Handler() は以下のように浮動少数をフォーマットしようとすると起こります

 

sprintf(my_string,"%2.2f",(float)12.33);

sprintf と %f の実行はヒープの使用が必要です。

hard faultする理由はそのヒープ領域にあり、ヒープ領域がIDファイルを書くときに割り当てられないことが原因です。 

 

>> 

The most likely cause of the error handler-call if due to lack of memory when using floats. Try reducing the page-size.

The page-size-setting can be found if you right-click on your project, then select 'Properties'.
Expand the 'C/C++ Build' - entry in the left column and select 'Settings'. 
Select the 'Tool Setting'-tab and then look under 'C Linker' for 'Optimization'. 
If you select that, you will see a drop down list for different page-sizes.

Select 'Small' and then Apply.

 

The other solutions are related to where how heap and stack are located in the memories.

In your linker script, 'end' gets set to _ebss which is located in the external ram.

Now, the problem comes down to the logic that implements the _sbrk() which is the memory pool allocator. It follows the very simple logic of:

Is the new heap pointer located below the stack pointer ? Then return memory : otherwise return out of memory.

Since the stack in your script is in the internal ram and the heap wants to be located in the external ram on a higher address, the _sbrk won't ever give out memory.

So you have at least three choices here,

1. Make sure the heap is located in the internal ram below the stack

2. Place the stack in the external ram as well

3. Re-implement the _sbrk() memory allocation logic. (you can look at the current _sbrk() implementation by right-clicking on your project, select new -> Other, then expand "System Calls" and generate the Minimal system calls file somewhere into your project)

 

The simplest way is to go for number 1.

Remove the PROVIDE(end = _ebss) from your linker scripts bss section.

And then you can place a new statement directly after the _estack = 0x2001000;, specifying for example:

end = 0x20000000; /* Place the heap at start of internal RAM */

 

Since the heap grows upwards, you don't want to place valuable data directly after the 'end' symbol as it might get overwritten.

4.“Do not use standard Start-files”とは？

4.“Do not use standard Start-files”とは？

What is the meaning of the check-box "Do not use standard start files", found in Build settings and selects Tool Settings > C Linker > General?

This check-box gives user two options to execute user-defined code before entering main, instead of modifying the Reset-handler. Both are triggered by the libc_init_array call in the startup code.

Option1: Constructors for objects or constructor functions are placed in a list called .init_array. These functions are then executed one by one by the libc_init_array.

Option2: Add code to a .init section. libc_init_array will run the _init function which will execute all instructions added to the .init section. The crti and crtn contains the start and end of the _init function.

3.エンプティーループがRELEASE-buildで走らない

3.エンプティーループがRELEASE-buildで走らない

One common support question is related to application behaviour using the two different default generated build configuration; DEBUG and RELEASE. The application typically behaves as expected in debug build configuration, but the behaviour may seem different when building with RELEASE build configuration. Experience tell us that this often is because the developer has written code constructions that are not 100% correct. Using the RELEASE build configuration with higher optimization level the toolchain will remove more code that is perceived as unnecessary. Let us take a look at the example below, two LEDs flashing with a for-loop delay dummy:

 int j;

 EVAL_LEDOn(LEDx);

 for(j = 0; j < 0x100000; j++); ;

 EVAL_LEDOff(LEDx);

 for(j = 0; j < 0x100000; j++);

For the DEBUG build configuration the behaviour will be in accordance with the C-code above. Using the RELEASE build configuration with a higher optimization level, these empty for-loops will be interpreted as unnecessary. In order for the toolchain not to remove them from the RELEASE output binary, the developer must be more accurate in his/her code writing. In this specific case the volatile modifier must proceed the integer declaration:

volatile int j;

 EVAL_LEDOn(LEDx);

 for(j = 0; j < 0x100000; j++); ;

 EVAL_LEDOff(LEDx);

 for(j = 0; j < 0x100000; j++);

This type of mistake is the root cause of most support cases stating that there are differences between DEBUG and RELEASE build configuration.