This indeed looks like an explanation!
Just to prove the point here is a sections of the map file with nothing
at 0x104E:
000001f0 a DMA2CTL
000001f2 a DMA2SA
000001f4 a DMA2DA
000001f6 a DMA2SZ
00001100 D __data_start
00001100 D oldPhyTransmitPower
00001102 B __bss_start
00001102 D _edata
00001102 B debug_int16
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
-------------------------------------------------------
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
