Question

Whats the advantage that the BDM ELF file has over the normal ELF file in terms of memory used?

I know the following things about both:

1. BDM ELF file could be used for debugging through any debugger tools
   like Trace32 by plugging in JTAG. The normal ELF file also can be
   used for debugging purpose, provided we have the corresponding FLS
   file (Flash file) that has to be flashed into the ROM area of the
   ECM.
2. BDM ELF files are loaded into the RAM area of the ECM (Electronic
   Control Module) whereas the normal ELF files and their corresponding
   FLS are loaded into the ROM are of the ECM.
3. The ELF files (either BDM or the normal one) are not loaded entire
   into the memory of ECM (I understood this from the size of the ECM
   memory that we use for loading the ELF which is in terms of KB’s
   compared to the huge size of the ELF which is in terms of MB’s),
   some part of the ELF file (symbols like types, variabled and
   functions etc) are kept with the Trace32 memory.

The above were my major understandings of using the ELF’s, I know that you people will help me in correcting myself in case I have interpreted anything wrongly.

My expectation is to understand how is BDM ELF file content distributed among the Trace32 debugger and the ECM memory, how is either of the ELF formats advantageous than one another as both are used for debugging purpose only. Please note that when it come to releasing the application/software to the customer, we release in terms of the FLS format which the customer flash into their ECM.

Please let me know if you need anymore information to proceed with answering my question.

Answer 1

OK, I’ll try again:

How is BDM ELF file content distributed among the Trace32 debugger and the ECM memory?

The ELF file can hold debugging symbol information (relating memory locations and registers to functions and variables), which the trace32 uses to help you debug. This symbol information is held in trace32 and it is used to decode the BDM output from the chip (register values, mostly) and provide useful information beyond bare assembly.

How is either of the ELF formats
advantageous than one another as both
are used for debugging purpose only?

This depends on your debugging tool and your development tool chain. As I said in my other answer, ELF is just a standard format. Weather it is used for line programming depends on what your development tool does at link time. Since you don’t tell me what your tool chain is, I can really only speculate.

If your device has a flat memory model and integrated ROM (most 32-bit devices with smaller amounts of storage), then only a single file is necessary to program the device. Since RAM and internal flash are addressed the same, the address just needs to match the desired destination.

If, on the other hand, you have two places where ROM is stored (which I suspect is the case in your product) and they aren’t addressed the same, then two files might be necessary. This would be the case if there were an ECU which interfaced with and external flash ROM chip (or SD card or the like). In this case, a separate image would be required to write to the off-chip storage since the addresses would likely overlap (an ELF assumes a unique address for a piece of data). So in your case, two ELF files are needed: one specifies the debugging setup to be loaded into RAM to start the device in debug, the other specifies the symbol information for the OS and other data programmed into the external flash chip. The FLS files probably specify information that the programmer uses to address the external flash not present in the ELF, but this depends on architecture (I’m not familiar with how Nokia designs their hardware).

This may help for general ELF info: http://blog.ksplice.com/tag/elf/