On 09.10.14 16:39, Alistair Gadd wrote:
> Erik, I am going to have to take some time to absorb your response while I
> play with the linker scripts. On your comment on the addresses used, I used
> 0x7000 for the bootloader start (CFLAGS -Ttext 0x7000) because it seems that
> the compiler wants a byte address and not a word address and the IDE wants a
> word address for defining the .sdlib section (.sdlib==0x2000)
Yes, playing with linker scripts is a great strategy, then using
"avr-objdump -h", and looking in the map file if needed, is a good way
to get a feel for the results.
Please disregard my earlier comment. Now that I'm clear that the .text
at 0x7000 is your bootloader, all is good. If going with the explicit
MEMORY regions I depicted, you'd just put the bootloader code in the
.boot section, instead of .text. That leaves .text for application code,
part of which is .sdl, hiding up the back, AIUI. Explicit regions is just
another way to do it, avoiding long commandlines, and better documenting
the memory map in the linker script. (Dunno about you, but I find it
easier when all that stuff is in one place when I come back to an old
project.)
One benefit of the MEMORY tweaks I showed is that the linker can then
deliver error messages if your code overflows a segment. If you look at
the generic OUTPUT_ARCH(avr:5) which avr-gcc uses for the ATmega328p, it
specifies:
text (rx) : ORIGIN = 0, LENGTH = 128K
but the device only has 32K. As a consequence, the linker cannot tell
you when code size has overflowed. (And when you link in .sdl, future
application code can hit the rafters earlier than you expect, if the
space taken by .sdl slips your mind.) Once empowered by a custom linker
script, you can fix that, as the example did.
> - here's an
> extract from the generated command line:
>
> */avr8-gnu-toolchain\bin\avr-g++.exe" -o .......................
> -Wl,--start-group -Wl,-lm -Wl,--end-group -Wl,--gc-sections
> -Wl,-section-start=.sdlib=0x4000 -mmcu=atmega328p -Ttext 0x7000 -T
> ../avr5_sdlib.xn
>
> /*The generated intel hex file placed the code at 0x4000 (.sdlib) and 0x7000
> (.text) as byte addresses which would relate to word address of 0x2000 and
> 0x3800 when loaded into the processor and the vectors placed at 0x7000 and
> upwards in the hex file were all jumps to 0x38XX addresses. My plan is to
> move .sdlib right up once I've got things working. Please correct me if I've
> got this all wrong.
Nope, it's looking good. It can be done manually. I.e. adding this
output section would fix .sdlib at 0x4000:
.sdlib 0x4000 :
{
*(.some_section) /* If suitable __attribute__ used. */
foo.o(.text*) /* Selection by filename. */
} > text
Or it can be automated. If the 0x4000 is omitted, .sdlib will just drop
in after any code already linked into the text region. I.e. it will be
immediately after the application code if the above output section is
added to the linker script after the .text output section.
Unless the SD card library is being accessed by fixed addresses, like an
old-fashioned BIOS, then it is arguably easier to just let it ride above
.text, like a boat on the ocean, and just link its services with the
application code. It then serves like a DLL on linux, but just
statically linked. No fiddling with addresses needed - it just slots
into available upper flash, until there's none left. And if you tweak
the LENGTH in MEMORY in the linker script, the linker will tell you when
that happens.
Erik
--
I have yet to see any problem, however complicated, which, when you
looked at it in the right way, did not become still more complicated.
- Poul Anderson
_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
