[En-Nut-Discussion] devnut_m3n: lpc1768_flash.ld and lpc1778_flash.ld Linker scripts

Ulrich Prinz ulrich.prinz at googlemail.com
Mon Jan 23 17:45:13 CET 2012

Hi Ole,

regarding the 0x1C location we can merge that with another idea I had:

In CMSIS the negative 'interrupts' (-15..0) are fixed and should be
handled through static interrupt handlers by the OS itself.
In the actual situation only the two words for initial stack pointer
and reset vector are stored in flash and copied over to ram at the
beginning of the RAM interrupt vector table.
But as systick, NMI and the others < 0 are to be considered static, we
could add them in the linker and push them with the right values.
This even saves some flash as the interrupt init calls for these
functions are obsolete.

This makes a pseudo interrupt entry at 0x1C available where your
check-value can be located without problem.

Am 18. Januar 2012 18:13 schrieb Bernard Fouché <bernard.fouche at kuantic.com>:
> Le 18/01/2012 13:48, Ole Reinhardt a écrit :
>>> 2) The Code Protection Read value at 0x2FC: same problem but even
>>> nastier since there is a 'chance' that total control of the MCU is lost.
>>> OpenOCD does not know about this location. A 'hole' must be defined in
>>> the linker script for the 4 bytes at that location and an optional tool
>>> must consider this location is one wants to lock the MCU for security
>>> purposes.

This looks like interrupt 191 (or 179 by CMSIS counting)...

I guess that the NXP people added this security feature at top of the
interrupt vector table of their biggest possible device. They propsed
(truely wrong) that anyone would store a fixed interrupt table in the
So I see no other option than to create a preset vector table of this
size, with every interrupt pointing to a default irq function. If you
then generate a startup.s defining all interrupt entries as 'weak',
the linker will not complain if any of the interrupts is not
referenced in your code. It instead will use the default vector you

If needed, I can pass you some demo code doing this.

I skipped it as I tried to omit any assembler code for startup.

Best regards

More information about the En-Nut-Discussion mailing list