Developing Large Applications on Concerto

Bernard,

Yes, you can selectively erase the Flash sectors using the Flash Plugin GUI options.

To avoid reloading the existing Flash code, you can try NOLOAD (or DSECT) in the linker command file for the sections that you don't want to load again.  Check this wiki page: http://processors.wiki.ti.com/index.php/Linker_Special_Section_Types.

Thanks and regards,
Vamsi

Hi Vamsi,

Thanks a lot for that. I now see a way ahead. But:

1. I get: "fatal error #10017: combining options --absolute (-a) and --relocatable (-r) is not supported when producing ELF output files"    Should I use COFF?, or is that problematic?

2. Still can't get my head around the linking:

a. I link my stable code objects (.text & .const) with -ar, and load in high-memory flash (i.e. ROM), which includes the stuff dragged in from TI-RTOS e.g. EMAC, GPIO, SPI code. 

b. I can then link the developmental code and (with NO_LOAD) stable code objects,  and load the developmental code into low flash.

After Step a. I see a lot of stuff in the .bss .stack .sysmem sections in RAM.    Is this approach really going to maintain the correct links from the stable code in high flash and from the development code in low flash to the .bss .stack .sysmem sections in RAM as the developmental code evolves, and is recompiled and linked as per Step b., above?

Best Regards,

Bernard

Bernard,

1.  I use only coff.  I checked with our compiler team and they mentioned that we cannot create both an absolute and relocatable file in ELF.  

2.  I guess you should be fine using NO_LOAD for static code and it should maintain the correct links.  I never tried though.  Why don't you use XDS200?  XDS200 is much faster and is not that expensive.

Thanks and regards,

Vamsi  

Vamsi,

Thanks for checking.  I also found a few document re ROMing (e.g. Roming a software component  spraan5.pdf) and with the complexities in managing .bss etc, I don't think I want to go there.

I had not considered XDS200 because of the inbuilt XDS100. I just checked the DIMM and it brings out the JTAG pins (TCK, TMS, TDO, etc).  Do you reckon I could connect an XDS200 and disable the XDS100? 

Best Regards,

Bernard

Hi Bernard,

What Concerto are you using: F28M35x or F28M36x?
The F28M36x cCARD will easily allow you to use an external emulator.  On the other hand, the F28M35x cCARD would need to be hacked up in order to enable the usage of an external emulator.

One other potential thing to experiment with is the TCLK setting in your xds100v2's Target Configuration.  In CCS, you can edit a target configuration's JTAG TCLK frequency in the "Advanced" tab.  I have been using 4MHz for several months with no issues, however other values may also be valid.  Note that I'd stick with ~10MHz max (due to isolators and other logic in the lines).  I haven't personally seen much change between TCLK=1MHz and 4MHz, but my files have typically not been very large.


Thank you,
Brett

Bernard,

since you mentioned that you can link all the stable code into single section of code, are you able to use what Vamsi suggested with the NOLOAD or DSECT?

or you can create two CCS projects, one with the stable code which you program into the flash and other with the development code. If the development code needs to link to any functions from the stable code project then you can create a symbols library of the needed symbols from the stable project and use the symbols library in the development project. This is usually the working model - how to create a symbols library is explained in section 5.1 of the spraan5 app note.

If you don't want to create a symbols library from the stable project then you can create a simple map.h file (like below), by looking at the MAP file generated for the functions address.

#define FUNCTION_1     0x123456

#define FUNCTION_2     0x234567

..

..

hope this helps...

Best Regards

Santosh Athuru

Hi Brett,

It's a F28M35x.

Thanks for the clock suggestion. It's now running OK at 4MHz, and I will try higher frequencies..

Best Regards,

Bernard

Hi Santosh,

Unfortunately I don't have enough knowledge to try and use NO_LOAD and static code, rather than the ELF process that CCS defaults to in my configuration, and ELF does not support NO_LOAD.

I was scared off going down this path by the complexity and scripts presented in spraann5 addressing, for instance,  the C6000 non-splitable.bss section, and the .cinit 'bring forward' and .switch section issues. I don't think the .bss section is an issue for ARM, but don't know if ARM has other issues to manage. 

I would like to try your (Section 5.1) approach  (#define FUNCTION_1 0x123456).  I am able to load the .txt and .const into high flash OK. But I am not sure with ARM if:

1. Do I need to exclude all functions from ROM with .bss?  (spraann5 Section 2 says "No .bss references (at least for ‘C6000 and TMS470)"  What about ARM?

2. Do I need to remove the Host I/O functions? (spraann5 Section 3.3)

3. Is .cinit to be managed as per spraan5 Section 4.3?

4. Is .switch to be managed as per spraan5 Section 4.4?

Best Regards,

Bernard