Tool/software: Code Composer Studio
Hi Sir,
I want to know how to find out what is using so much space in the SRAM>.data>.data:$01$(bmi160_support.obj)
Can you help me to clarify it?
Thanks.
This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
To understand what happened I need to reproduce it. I don't need the whole project, just the details related to one file. For the source file bmi160_support.c, please follow the directions in the article How to Submit a Compiler Test Case.
Thanks and regards,
-George
Hi George,
Thank you for your reply.
The compiler version utilised for the simple_peripheral project is TI v18.12.6. LTS.
There is no important compiling problem going on.
I just want to know if there is a way to manage the SRAM memory and more specifically from the .data:$01$$(bmi160_support.obj),
since it is the file that most SRAM memory uses and it seems a little bit unusual.
Thank you for the test case. I understand what is happening. But it is difficult to describe.
The compiler performs an optimization that, in the end, reduces how much memory is used. Many global data variables, structs, and arrays are collected together into a single object that is in the section .data. Among other things, this reduces the need for constant table entries. Describing the constant table, and why this optimization makes it smaller, is beyond the scope of what can be covered in a forum post.
The effect you noticed is that the .data section for this one object file is very large. Without this optimization, many of these global variables would be in the .bss section instead. Even though the size of the .data and .bss sections is affected by this optimization, the combined size of these two sections changes very little.
Thanks and regards,
-George
Hi George,
Thank you.
Isn't there any way to find out which variables are using the memory from this object file?
This would allow me to manage variables and optimize SRAM space.
Add the build option --src_interlist. This causes the compiler to not delete the auto-generated assembly language file. This file has the same name as the source file, with the extension changed to .asm. Search it for a comment similar to ...
; The following variables will be grouped together to share a common ; base address. References in the source interlisting will look like ; "1$$.accel_off_y", "K$1->accel_off_y", "C$1->accel_off_y", "&1$$+1", and "C$1+1". ; ; --offset-- --size-- --variable-- ; ; 0 1 extern char accel_off_x ; 1 1 extern char accel_off_y ; 2 1 extern char accel_off_z ; 4 2 extern short gyro_off_x ; 6 2 extern short gyro_off_y ; 8 2 extern short gyro_off_z ; 12 4 static struct I2C_Config_ *i2cHandle ; 16 4 extern struct gyro_sleep_setting gyr_setting ; 20 6 extern struct bmi160_gyro_t gyroxyz ; 26 6 extern struct bmi160_accel_t accelxyz ; 32 12 extern struct bmi160_mag_xyz_s32_t magxyz ; 44 20 extern struct bmi160_t s_bmi160 ; 64 28 extern union $$fake18 bmi160Sem ; 92 28 extern union $$fake18 displaySem ; 120 36 static struct ti_sysbios_knl_Clock_Struct myClock ; 156 80 extern struct ti_sysbios_knl_Task_Struct displayTask ; 236 80 extern struct ti_sysbios_knl_Task_Struct bmiTask ; 316 300 extern short buf_thomas[50][3] ; 616 512 extern unsigned char displayTaskStack[512] ; 1128 1012 extern unsigned char bmiTaskStack[1012] ; 2140 3660 extern struct bmi160_fifo_data_header_t header_data ;
Thanks and regards,
-George