• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 84 subscribers
  • Views 376 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CCS/TMS320F28022: Force routines to always load in the same place for debugging

Cool Javelin
Expert 1680 points
Part Number: TMS320F28022


Tool/software: Code Composer Studio

Win7 SP1 (32bit). CCS 6.1.3. F28022.

I am debugging 1 or 2 routines, and I find recompiling, erasing and reloading the FLASH to be both slow and a waste of FLASH write cycles.

While the FLASH is rated for some thousands of cycles, I assume if I compile and reload enough times, I will eventually reach that limit.

I have my CMD file setup so I can put most routines in FLASH, and a few I am debugging in RAM. OK.

I also set a switch to make the CMD enact the FLASH sections as "NOLOAD" This does prevent the erase/program cycle.

However, that by itself does not work as some of the routines in FLASH will call the routines in RAM and these may be in different locations each debug cycle.

Is there a way, without creating a section for each and every function, I can easily force the compiler (loader actually) to place all the functions in the SAME location until I am finished debugging the RAM functions?

I understand I may have to allocate some "flexible" blank space between the RAN functions so their entry points remain consistent.

I am thinking a separate program that uses the map file from run to make CMD include files or something along those lines.

I am considering writing a couple of external programs, one that uses a map file to make CMD parts, another that compares an old map file to one the compiler will create after each compile to warn me if any functions change locations.

Thanks, Mark.

  • 0
    TI__Guru 60865 points
    Hi Mark,

    The typical Flash endurance is 50000 cycles (and that is across the device rated temperature range) so if you are just debugging at ambient temperature I think you'll be OK. Agree that it is definitely slower than just reloading to the RAM.

    I don't think there is any way to request the linker to place the variable at the same place as last time.

    If it is only a couple functions, it is probably faster to just make the static allocations than to write the script to detect the differences in the symbol table compile-to-compile (but I think that would work).

    If you are worried about space constraints with a static function allocation, see:
    e2e.ti.com/.../739227

    Or allocate interface functions to a fixed location in a small chunk of RAM and then just have those interface functions call the main functions. You'd then just let the linker place the main functions wherever in RAM.
  • 0 in reply to Devin Cottier
    Expert 1680 points

    Thanks Devin:

    I guess it will take some time to reach 50K cycles even at 50 a day.

    I did do a work around somewhat. I wanted to debug two functions, so I made 2 areas on PAGE 0 in RAM in the CMD file. Then I made 2 sections, then I used pragmas on those 2 functions and place each one in it's own RAM area. That way all functions should stay in place from compile to compile.

    I did not think about actual variables being located in different places, but unless I change the size of them I think I will be OK.

    I am going to mark this a solved, and if I run across some kind of miracle (or write my own,) I will come back here and update.

    Thanks for your time.

    Mark.