On Wed, May 26, 2010 at 9:56 PM, <[email protected]> wrote: > John Porubek writes: >> On Tue, May 25, 2010 at 9:01 PM, <[email protected]> wrote: >> > Hi John, >> > >> > I'm guessing that perhaps they use a different machine-type code for >> > their binaries. >> > >> > I don't suppose you could email me one of these ELF32 files to have a >> > look at? It might be nice to be able to work with the files produced >> > by IAR as well. >> > >> > - Daniel >> >> Daniel, >> >> Sure, no problem. I'll send it to you separately so as not to burden the >> list. >> >> --John > > Hi John, > > These files do use a different machine-type code. Binaries produced by > mspgcc have a code of 0x69, whereas this uses 0x430. If I ignore this, > then symbols can be loaded. > > However, programming is a problem, because this file has no sections > apart from the symbol and string tables. There's not enough > information in the program header alone to reliably determine which > parts should be flashed and which shouldn't (unless someone can tell > me otherwise): > > Program Header: > LOAD off 0x00000034 vaddr 0x00000200 paddr 0x00000200 align 2**1 > filesz 0x00000000 memsz 0x00000300 flags rw- > LOAD off 0x00000034 vaddr 0x0000e000 paddr 0x0000e000 align 2**1 > filesz 0x00001ac8 memsz 0x00001ac8 flags r-x > LOAD off 0x00001afc vaddr 0x0000ffe0 paddr 0x0000ffe0 align 2**1 > filesz 0x00000020 memsz 0x00000020 flags r-x > > The only way I can see is to ignore the first segment based on the > fact that it lies outside of the MSP430F2274's code memory. However, > this won't necessarily be reliable, because MSPDebug can't yet > reliably identify chips with a 100% success rate. > > What I'm doing at the moment is looking for sections of type > SHT_PROGBITS that have the SHF_ALLOC flag set, and then translating the > addresses using the information in the program header. > > If anyone can suggest a reliable method of identifying segments which > should be flashed, then I'll be happy to implement it. > > As an aside, I notice that running msp430-objcopy -O ihex results in an > empty .hex file. > > - Daniel >
Hi Daniel, It sounds like dealing with IAR's version of an ELF-format file is turning into more work than is justified. I strongly suspect that the overwhelming majority of your target audience is using mspgcc. This *is* the "Mspgcc-users" mailing list, after all! I'll probably be converting over to mspgcc myself, one of these days. As I mentioned previously, I have successfully created a symbol file that works using "nm". As for programming, I currently do that from IAR but, if I use MSPDebug, I can use Intel HEX (and lose the autoloading of symbols that the ELF format provides - not a huge deal). So, barring anyone else stepping up with the information you need, I can still limp along (just kidding!) using a few extra steps. BTW, while looking for more info. on IAR's ELF format, I found the following "Known Problem" in the "Release notes for the MSP430 IAR Embedded Workbench product package version 5.10.1": "EW20738: If you select ELF/DWARF as output format from the linker, only the ELF part with symbol information etc will be generated. The DWARF part is not provided which means that it is not possible to use the output file for debugging. The linker does not generate any warning message about this." I don't know if this sheds any useful light on the subject, but there it is. Thanks for your efforts, --John
