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
