Edward wrote:
Is there anybody who could help me with the issue?
Folks who made patches to gcc/gdb?
Anybody knows what is the purpose of that section? Initialize SFRs?
But why start from 14E, not from 0?
GDB seems to be ignoring this section at all, at least it would not
show on the debugging output.
Hi everybody,
I'm trying to use noICE debugger for MSP430F1611.
However, when trying to flash the device, the debugger terminates the
process with an error, while gdb flashes the same file with no problems.
The reason is in ELF header. Below is the actual ELF header dumped by
objdump -p. In the first line, there is a segment starting at 0x104e and
size of 0x0b4, which overruns by 2 byte into RAM at 0x1100. This is the
cause of the error during flashing. If I take the same file and
compile it
for MSP430F149, the program headers (below) will have a segment
defined at
0x014e and the same length, which will cause no problems during
flashing.
My question is: is this an error and how to fix it?
Looks a lot like a typo somewhere (0x104E vs 0x14E), though I could not
identify the source.
My program is not using info memory or have any symbols located there.
BTW, I'm using 20050614 release for Windows.
Thank you,
Edward
MSP430F1611
Program Header:
LOAD off 0x00000000 vaddr 0x0000104e paddr 0x0000104e align 2**0
filesz 0x000000b4 memsz 0x0000081f flags rw-
LOAD off 0x000000b4 vaddr 0x00004000 paddr 0x00004000 align 2**0
filesz 0x000067b4 memsz 0x000067b4 flags r-x
LOAD off 0x00006868 vaddr 0x00001100 paddr 0x0000a7b4 align 2**0
filesz 0x00000002 memsz 0x00000002 flags rw-
LOAD off 0x0000686a vaddr 0x0000ffe0 paddr 0x0000ffe0 align 2**0
filesz 0x00000020 memsz 0x00000020 flags r-x
MSP430F149
Program Header:
LOAD off 0x00000000 vaddr 0x0000014e paddr 0x0000014e align 2**0
filesz 0x000000b4 memsz 0x0000081f flags rw-
LOAD off 0x000000b4 vaddr 0x00001100 paddr 0x00001100 align 2**0
filesz 0x000067b4 memsz 0x000067b4 flags r-x
LOAD off 0x00006868 vaddr 0x00000200 paddr 0x000078b4 align 2**0
filesz 0x00000002 memsz 0x00000002 flags rw-
LOAD off 0x0000686a vaddr 0x0000ffe0 paddr 0x0000ffe0 align 2**0
filesz 0x00000020 memsz 0x00000020 flags r-x
It looks like something is wrong which is harmless when using the GNU
tools, and not when something else tries to handle the ELF file.
The segment you are seeing is non-existant. It is actually the header of
the ELF file. I assume it should have an address like zero, but it
actually has an address offset back from the start of the data segment
by the length of the ELF file header. Since the data segment starts at
0x200 in most devices paddr is set back from that. The 1611 the data
segment starts at 0x1100, so the bogus data segment is 0xF00 higher.
Perhaps Dmitry can say what should really be happening.
Regards,
Steve
