Load Memory from File - Doesn't Behave As Expected

Hi Timothy,

Timothy Frank said:

Until ... the CCS "Load Memory from File" operation is used

Just to confirm, this is the "Load Memory" feature from the Memory Browser view? And you are selecting "Binary" for the file type?

Timothy Frank said:

After the Load Memory from File operation completes, the CCS debugger "forgets" all the symbols in the application program! The application program is unaltered in memory ... but, in addition to the debugger forgetting the symbols in the application program

How did you confirm that the symbols are "forgotten"? When you open the Modules view, does it have any symbol files listed or is it completely blank?

Timothy Frank said:

it also forgets the debug status that was in effect when the program was stopped and prior to the Load Memory from File command.

There is no recovery from this effect, either. Reloading the program symbols --- no; the debugger is "lost" and can't figure out where the program is stopped ... and it just runs off into the "weeds". Restarting the program --- no; that unexpectedly doesn't work either, despite the fact that the application program is clearly visible in the expected RAM area AND the "test data base" is also correctly loaded in its (separate) RAM area.

It's like the binary load put the target in a poor state... overwrote something it shouldn't... but you have confirmed that it is correctly loaded in a separate memory region that is safe to overwrite, so I'm not sure what else could have happened.

Timothy Frank said:

It just seems wrong to me that loading a binary file into an unrelated RAM area would cause the debugger to forget the application program symbol table and lose the current debug session status.

Agreed. This shouldn't normally happen.

ki

I have run into very much the same problem using the development board for the TCI6630K2L. The Load Memory tool seems to successfully complete the task (the correct data is written to the correct location, as far as what I'm seeing in the Memory Browser), but the debugger seems stuck and/or lost. This seems to be particularly associated with the action of loading a *.bin file. I can load the same file using the TI Raw Data option, and that doesn't cause the debugger to become confused, but of course that also doesn't load in the data entirely correctly since that's not the actual format for my data file.

I checked the Modules view after the memory load operation finished, and it is indeed completely blank. Also, once the memory load operation has begun, there is a point early on at which CCS tries to open source for memory location 0x803fec automatically, but then it says "No source available for '0x803fec'" and gives me the option for viewing the disassembly (which doesn't look like much of anything to me when I open it). I can only assume CCS doing this has something to do with this issue I'm encountering, but I don't know. A screenshot of that is attached.

Has there been any headway made on this issue? This is quite a serious problem for the development I'm currently working on.

Doug Hogan

• Just to confirm, this is the "Load Memory" feature from the Memory Browser view? And you are selecting "Binary" for the file type?
  
  Yes. Yes.
  
  
  
• How did you confirm that the symbols are "forgotten"? When you open the Modules view, does it have any symbol files listed or is it completely blank?
  
  
  Symbols of the program are not found in the expressions view, Code Composer cannot display disassembled code, Code Composer cannot display source code associated with disassembled code. No symbol files are listed.
  

By the way, the binary file itself is not even the program image. The program image was previously loaded by the host processor on the target, and it's known to be intact. I "break in" with Code Composer and can halt the program, single step, do anything normally done with the debugger/emulator. I can view variables, source code, etc.

The binary file being spoken of here is simply a "block of data" ... a data base, if you want to think of it that way. That's why I was surprised that loading this binary file into the memory of the DSP would suddenly cause the debugger to "get lost" ... (defined by me as forgetting where the program is halted, forgetting all symbols and source code).

As before, the actual target memory of the "data base" is valid, just fine, and the target memory of the application program is also unmodified. Memory seems intact.

Yes. Load memory, binary file, ... and I've got the binary file set into the "octet" (8 bit unsigned) mode. The size of the binary file is approximately 128K bytes.

Sorry, I should have responded sooner. I found the solution to my problem, and I believe it's the solution to Timothy's problem too. Timothy, check out this forum thread and then this one (which references the first forum thread). It seems that a hidden(?) feature of the binary Load Memory operation is that it sets the PC. But the TI Raw option worked for me if I chose 32-bit word size. Perhaps 16-bit also works (according to the second forum thread it should, but I didn't check), but 8-bits didn't work for me (it seems there was or still is a bug). Hope this helps!

Doug Hogan

I suppose, logically, that loading a binary file would or should cause the symbol table to disappear. After all, a binary file does not contain any debug records, whereas an ELF file or a COFF file certainly can and does.

I've been defining a "binary file" as being a pure image file ... that is, it contains ONLY the image of the object code AS IF that object code were the bits in the memory device. Just to clarify, ... after all, an ELF file, or a COFF file, thought of a certain way, is also a binary file. I.e. it is only "machine readable" and not "human readable". But, I am speaking of a pure image file here.

Perhaps the behavior of Code Composer was a bit surprising to me, but, again, logically correct. My purpose was to validate the machine-loadable (e.g. FLASH EPROM loadable) image. For certain application purposes I have to load a binary image ... in sequence of other binary images ... to validate the proper operation and debug.

I suppose another method of performing this duty is to accept the binary image load as causing the symbol table to be deleted, but ... after the binary image load then load only the symbol table from the ELF or COFF file? I haven't tried that yet ... but will do so at some point and report back to you.

I'm guessing here that your method is, actually, simply a work-around to this issue, and probably just a coincidence that it works at all.

For the TI development team, perhaps a more useful suggestion for you is to more clearly annunciate the behavior of Code Composer with respect to binary (image) files? There really isn't much information provided in the help system on the behavior of the program when loading files. A lot of wiki stuff, but ...

Good luck, all, and thank you for the information provided.

I'm not sure if this will help.

In my development, I have to load two different COFF files (boot and application). As you described, loading one removes the symbols from the other. So this is what I'm doing:

PRE: ensure that the Flash configuration for memory is set to "Erase and program only needed sectors" (the default option is to delete the whole flash)

1) Load the application image (I have configured the project to automatically load this)
2) Load the boot. (Run -> Load -> Load Program)
3) Add the application symbols again (Run -> Load -> Add Symbols)

The order is important, since CCS keeps the entry point for the last program loaded (that's why I loaded the boot last).

Alternative, since boot is almost never changed, sometimes I don't program the boot, but only load the symbols:

1) Load the application image (I have configured the project to automatically load this)
2) Load Symbols for the boot. (Run -> Load -> Load Symbols)
3) Add  the application symbols again (Run -> Load -> Add Symbols)
4) Reset (so CCS branches to the boot start)



But, if what you want is to load a file to memory after you started debugging, you might want to look at

Tools -> Load Memory


(just watch out for endianess)


Regards.