Dale,
you're right, those are not SFRs but called peripheral modules.
The areas at either 0x14E or 0x104E are indeed written as RAM.
The problem is that the .lst file has no symbols at all in those regions.
I have no idea why the ELF has those sections.
Here is an objdump -h of the same file. It has nothing at x104E or 0x14E.
Objdump -p will have those sections! Should they be just discarded?
Idx Name Size VMA LMA File off Algn
0 .text 0000673a 00004000 00004000 000000b4 2**1
CONTENTS, ALLOC, LOAD, READONLY, CODE
1 .data 00000002 00001100 0000a73a 000067ee 2**0
CONTENTS, ALLOC, LOAD, DATA
2 .bootloader 00000000 00000c00 00000c00 00006810 2**0
CONTENTS
3 .infomem 00000000 00001000 00001000 00006810 2**0
CONTENTS
4 .infomemnobits 00000000 00001000 00001000 00006810 2**0
CONTENTS
5 .bss 0000072f 00001102 00001102 000000b4 2**1
ALLOC
6 .noinit 00000000 00001831 00001831 00006810 2**0
CONTENTS
7 .vectors 00000020 0000ffe0 0000ffe0 000067f0 2**0
CONTENTS, ALLOC, LOAD, READONLY, CODE
8 .stab 000193bc 00000000 00000000 00006810 2**2
CONTENTS, READONLY, DEBUGGING
9 .stabstr 00008c26 00000000 00000000 0001fbcc 2**0
CONTENTS, READONLY, DEBUGGING
I don't know the specific memory maps of either of those devices, but
on the x449 it doesn't make sense to be flashing either of those areas
- unless you specifically wanted part of your code to reside in the
info mem. Based on the ELF header flags it looks like it thinks those
areas are RAM and not FLASH (rw- vs. r-x). Probably the best thing to
do is look at your .lst file and figure out what the code or constants
are that the linker is putting at those addresses. If you still can't
figure it out, post the relevant part(s) of the .lst file here and
maybe someone else can figure it out from there.
BTW, SFRs are Special Function Registers and I think are all located
from 0x0000 to 0x000F for the entire msp430 family.
Dale
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
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September
19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing
& QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Mspgcc-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
