BDM elf file vs normal elf file

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 te开发者_运维百科rms 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.

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/

The ability of the BDM ELF is to view changes to memory locations, and memory-mapped registers while the code is running, and without having to stop it.

By using the BDM ELF we can have hardware watch points or breakpoints. This is useful as you can break on a value being changed without affecting the speed of execution. Once the debugger breaks we can use the Debugging Kernel and Applications together method for finding exactly which line it happened.

You cannot set breakpoints in user programs from the BDM debugger. This is because it inserts "halt" instructions and these can only be executed by kernel code. It is possible to modify the BDM driver to allow the debugging of user applications via the BDM interface.

Your question lacks any question marks. As such, I'm not sure I'm fully answering what you are asking.

This information is largely derived from use of ELF files over BDM, not from actual documentation:

ELF is a file specification, so all ELF files should be the same. The ELF file is generated by the linker, and contains symbol information as well as executable code organized into sections. When the user programs an ECM, the debugger/programmer reads through the ELF file, picks out addresses of sections and their associated code, then writes these as desired.

Whether the executable is written to RAM or ROM depends on either the addresses of the sections in the ELF (usually configurable via a config file read by the linker) or the settings of the programmer when the program is "programmed". Most debuggers have an option to load an image to either ROM or RAM. The only difference in the program images is the locations of code and variables.

In the situation that you describe, your programmer seems to not be able to pull the executable data from the elf file. I assume that your fls file is some sort of raw image file that can be written word for word to the target hardware.