Map file wrong size for shared struct

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
joshm
Level 4
Level 4
25 replies posted 50 sign-ins 10 questions asked

I am encountering an discrepancy between the .map file size and the size of the struct in my program. The struct is defined in a shared file, and I use a shared_ram section in the linker files to instantiate the struct variable in the same RAM space for both cores so they both have access to it. My project is based on DFU_Upgradable_Stack. 

 

1. I define the shared RAM region in dfu_common.ld

ram_app2_shared (rwx) : ORIGIN = 0x08010000, LENGTH = 0x00400

 

2. I define an alias for the shared ram region then assign .struct1 and .struct2 to it in dfu_cm0p.ld and dfu_cm4.ld for app2. 

REGION_ALIAS("ram_shared", ram_app2_shared);

.struct1(NOLOAD):
{
*(.struct1)
} > ram_shared

.struct2 (NOLOAD):
{
*(.struct2 )
} > ram_shared

 

3. In the shared .c file I use CY_SECTION to tie the struct definitions to the same area in ram.
CY_SECTION(".struct1") struct SameStruct struct1;
CY_SECTION(".struct2 ") struct SameStruct struct2;

 

4. I instantiated another version of the same struct on cm0p without sharing or specifying anything in the linker files.

struct SameStruct struct3;

 

5. The result is when I print out sizeof() for all three, they are the same size, but the start address for struct2 is several bytes less than the start address for struct1 + sizeof(struct1). Also, printing the the address for the last element of struct1 reveals that it is about 0x14 bytes after the start address for struct2. In the map file, the size allocated for struct1 and struct2 is smaller than struct3. In the map file, the start address for struct3 is the same as revealed by printing out in the program. 

 

This makes it pretty clear to me that the issue is somewhere in the linking process. This is just a guess, but it seems like the smaller size of struct1 and struct2 is almost what the struct would actually be without padding. SameStruct is large and includes other structs in files I do not want to edit. sizeof(struct1) = 0x260 but the size specified in the linker file is 0x1f0 and the distance between struct1 and struct2 is 0x1f0. The size specified in the linker file for stuct3 is 0x260.

 

I am thinking of abandoning the linker file method of sharing the same RAM space for a variable and just passing the reference over IPC, but that would require changing other code. Any ideas what I am doing wrong or why the sizes are different? Or is it just a bad idea to do it this way? Thanks!

0 Likes
1 Solution
joshm
Level 4
Level 4
25 replies posted 50 sign-ins 10 questions asked

I found a way to make the size allocated for the struct to be the same size that was used in the program. As a member of the large struct (StructA), there is an instance of another struct (StructB) which has 9 instances of the same enum. The steps I took took to figure the issue are below:

1. Systematically comment out different parts of the struct to discover which one was causing the discrepancy. It seemed the discrepancy existed if and only if StructB was present. 

2. Removing StructB caused a 0x90 byte drop in program but only 0x20 byte drop in .map file. There are 9 enumerators in StructB, so I presumed the compiler was using 0x10 bytes per enum, which doesn't seem right. 

3. Removing one enum from StructB caused 0x10 drop in size in program but 0x02 drop in map file. 

4. Replaced the numerated variables in StructB with uint16_t variables. This caused all instances in the map file and running program to have the same size (0x210) which is 0x40 bytes larger than without StructB instance. That would mean 7 bytes per element which does not seem reasonable at all either, but at least they are both using the same size.

In conclusion, it seems the struct full of only 9 enumerators was causing the issue, but I am pretty I should be able to do this. Also, the bandaid fix still doesn't make good sense although it did fix the crash I was experiencing. Any ideas what this means?

View solution in original post

0 Likes
4 Replies
Gautami_12
Moderator
Moderator
Moderator
50 likes received 100 solutions authored 250 replies posted

Hi @joshm ,

Can you please let us know which version of ModusToolBox are you using to run this application?

Warm Regards,
Gautami J

0 Likes

I'm using PSOC Creator 4.4 with PDL 3.1.5.

0 Likes
joshm
Level 4
Level 4
25 replies posted 50 sign-ins 10 questions asked

I found a way to make the size allocated for the struct to be the same size that was used in the program. As a member of the large struct (StructA), there is an instance of another struct (StructB) which has 9 instances of the same enum. The steps I took took to figure the issue are below:

1. Systematically comment out different parts of the struct to discover which one was causing the discrepancy. It seemed the discrepancy existed if and only if StructB was present. 

2. Removing StructB caused a 0x90 byte drop in program but only 0x20 byte drop in .map file. There are 9 enumerators in StructB, so I presumed the compiler was using 0x10 bytes per enum, which doesn't seem right. 

3. Removing one enum from StructB caused 0x10 drop in size in program but 0x02 drop in map file. 

4. Replaced the numerated variables in StructB with uint16_t variables. This caused all instances in the map file and running program to have the same size (0x210) which is 0x40 bytes larger than without StructB instance. That would mean 7 bytes per element which does not seem reasonable at all either, but at least they are both using the same size.

In conclusion, it seems the struct full of only 9 enumerators was causing the issue, but I am pretty I should be able to do this. Also, the bandaid fix still doesn't make good sense although it did fix the crash I was experiencing. Any ideas what this means?

0 Likes
Gautami_12
Moderator
Moderator
Moderator
50 likes received 100 solutions authored 250 replies posted

Hi @joshm ,

Thanks for the workaround suggested in your previous response.
We thought it might be some issue with Structure Padding.

Warm Regards,
Gautami J

0 Likes