[En-Nut-Discussion] branches/devnut_m3n: _vtable needs 512 Byte alignment

[Uwe Bonnes]

Sorry to bring up an old discussion

>>>>> "Ulrich" == Ulrich Prinz <uprinz2 at netscape.net> writes:

    >> For the original linker script one doesn't notice, as _vtable is the
    >> first item in SRAM0. However if you want to run from SRAM, like with
    >> the linker script modified like below, _vtable may get placed
    >> inappropriate.
    >> 
    >> To not waste RAM space however, probably best is to place the _vtable
    >> definition first. The alignement directive should be changed however.

    Ulrich> Ok, in a RAM configuration...

    Ulrich> Add a compiler directive like DEBUG_RAM.  In the c Code add some
    Ulrich> #ifdef DEBUG_RAM to assign the interrupt table to .isr_vector
    Ulrich> instead of .vtable Exclude the original vtable assignment and
    Ulrich> the copy-over of stack pointer and reset vector.

    Ulrich> Now it could work already. As the linker script vtable is
    Ulrich> dynamically reserved by the site the c-Code defines for the arra
    Ulrich> at that position, it should work out of the box.

While this is done now in the devnut_m3n tree with the NUTDEBUG_RAM
variable, this approach has one serious drawback: It needs a special
compiled lib. This may be needed with low-on-ram devices, where every byte
of ram used counts. But when for development a fast compile/upload/run cycle
counts, use a device with more ram and you can waste some ram.

Keeping the isr_vector and vtable approach, with an appropriate alignment
directive for the vtable, would allow to decide late if to compiled for
flash or ram, with only one linker setting changed.

And even for correctness and documentation, the vtable alignment should be
added, even more as there is no RAM usage change when compiling for Flash.

B.t.w. git at github.com:UweBonnes/stlink.git and
git://github.com/texane/stlink.git can now upload and run to flash and
ram. When using the stlink gdb server and uploading to ram, the stack needs
to be set manually. I have to find out if this is caused by the stlink code
or by gdb...

Bye
-- 
Uwe Bonnes                bon at elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------