2810 Link Order under CC4

George,

Although in general the linker tries to allocate sections based on size, it is free to order sections however it wants. So if you want better control over how the sections are allocated in memory rather than leaving it to the linker to decide, you can modify your linker command file to be more specific.

Please see this FAQ which explains it further.

Can you post your linker command file and map file?

Aarti:

Thanks for the quick response.

I guess that by link order, I meant the order in time, not the order in memory space.  In CC3.1, it looks like the linker allocated my aligned chunks first and then filled in between them with the other compiler generated chunks, as the FAQ describes it tries hard to do.

In CC4.2 is seems to have allocated all the other compiler generated chunks first and then has no aligned chunks left to allocate for my buffers. I'm not particular about the address order it puts them into the output, just to get them all to fit.

George

I tried to insert the file but it tells me the types of files are not allowed.  I can cut and paste, but it is very ugly (the map file is large).

Here is my cmd file. There is also one generated by the bios confiig. It is the 3 "fir" sections that aren't being allocated in CC42 but are in CC3.1

Do you want the map? Is there another way I can post it?

/**************************************************************/

/* Link all user defined sections */

/**************************************************************/

SECTIONS

/* Section ramfuncs used by InitFlash() in SysCtrl.c */

ramfuncs :

LOAD = FLASH, PAGE = 0 /* can be ROM */

RUN = LSARAM, PAGE = 1

/* must be CSM secured RAM */

LOAD_START(_ramfuncs_loadstart), LOAD_END(_ramfuncs_loadend), RUN_START(_ramfuncs_runstart)

align 0x100 {} > LSARAM PAGE 1

firldv :

align 0x100 {} > LSARAM PAGE 1

firldi :

align 0x100 {} > LSARAM PAGE 1

scope > H0SARAM PAGE 0

}

MEMORY

= 8

FLASH_TABLES :

BOOT_BLOCK :

}

SECTIONS

Flash28_API:

{

It was a pain in the butt, but what I did for a work around was create 3 little patches of memory to hold the 3 filter buffers that had to be aligned. That made 2 holes that I also created memory blocks for and filled with Bios objects/stacks by manually moving them around.  It would be nice if the linker could have done all that automatically, like it seemed to do in CC3.1.

You should be able to work around this problem by placing the aligned sections at an explicit address, like so:

SECTIONS
{
  firldb : align 0x100 {} > 0xaaaa000 PAGE 1
  firldv : align 0x100 {} > 0xaaaa100 PAGE 1
  firldi : align 0x100 {} > 0xaaaa200 PAGE 1
}

As to why the linker doesn't successfully allocate it, I can't say without a test case, or at least the map file.  If you have trouble attaching a file type, change the file's name (particularly the file extension) to something else.

George Walker said:

I tried to insert the file but it tells me the types of files are not allowed.  I can cut and paste, but it is very ugly (the map file is large).

The last part of the forum welcome message describes another method for exchanging files in the forum.  Use the Files tab in your user profile.

Thanks and regards,

-George

Thanks George.  I put two maps there. One is the original CC3.1 that links fine. The other is my current CC4 map with my manual placements.  I no longer have a map from the link failure, but I can put it together again if it will help. I had to rename the .map to get them to upload there as well.

George

The change from CCS 3.1 to CCS 4.2 also involves a change in BIOS.  Thus the BIOS auto-generated link command file is probably different.  Are you sure that is not the cause of the problem?

Thanks and regards,

-George

George:

Yeah. Several changes of Bios's. And many other changes as well.  I thought long and hard before I took the time to port my code to CSS 4.  My new product is using the Picollo family which isn't supported by 3.1 and going forward, I figured I needed to have a platform where improvements in the new product could be integrated/offered on the old product as well. 

The visible change is in the performance of the linker. Possibly, it is because of new constraints created by the auto-generated CMD file. I can send you that if you want.  The other variable is the flags set by the front end to control the linker.

I think I'm ok going forard with my work around. It took a while to implement, but this is mature code so I don't expect to have to do that again.

Thanks

George

George,

I'd appreciate if you would create two zip files, and upload them to the Files tab in your forum profile.  They each would contain all of the link command files (auto-generated from BIOS or wherever) and map file from a particular build.  One build will be a successful one from CCS 3.1.  The other build will be from a CCS 4 build which failed, i.e. prior to the workaround you are using now.  I realize I'm asking for a big favor, especially since you have a workaround that you seem comfortable with.  But I don't see how we can ever figure this out without that information.

Thanks and regards,

-George

Hey. Kudos. I'm glad you want to figure this out. This wouldn't be an hassle for me if I wasn't tight on ram. 

I've added the two zip files. It wasn't a problem since I keep each of these development tracts in virtual machines. I copied my cc4 VM and tried to undo my changes. Originally, I had all 3 filters failing because of alignment. On this go round, only one failed. Same issue, all the 0x100 blocks had been allocated by the time it got to resolve my filter buffers. 

I included the the BIOS config files as well. If you want more, just ask. I could even send the VMs so you could reproduce, but they ar 10 G each.

Thanks

George