[En-Nut-Discussion] devnut_m3n: lpc1768_flash.ld and lpc1778_flash.ld Linker scripts
bernard.fouche at kuantic.com
Wed Jan 18 18:13:49 CET 2012
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
> This one is indeed really a problem. Perhaps I just bricked my eval
> board this way. On the other hand the chance to place the needed value
> there randomly is not very likely.
randomly not, but one may need to be able to lock the app when it is
deployed on the field.
>> 3) If ones wants to use IAP (for instance a bootloader), then the upper
>> 32 bytes of RAM are trashed by the built-in IAP code.
> Right. But only during boot process, right?
No, everytime IAP is used. If you write a piece of code that needs IAP
features (reading the chip id, erasing/programming flash), then this
code must have been linked with a link script that makes the upper 32
bytes unavailable. Again the risk seems weak but you never know what
users will do, especially if they are not aware of the IAP side effects.
> Many thanks! Maybe I may came back with some further questions if they
> Which CPU do you use?
Sure! However I'm no Cortex-M3 expert, I rely on the eCos HAL layer and
sometimes I run into some issues I report. eCos has a lpc17xx port
(which has/had some issues as mentionned) and a new kinetis port has
been recently commited to the CVS tree:it's always handy to have working
source code at hand. I'm using the LPC1765 since I need CAN bus, I will
make the CAN driver available in the next weeks (it's based on the
LPC2XXX CAN driver but the new version has many fixes/improvements so
I'll drop compatibility with older LPC2XXX chips that have some errata).
Will you provide support for bit-banding? This is incredibly handy to
manipulate registers/ram that can be shared between threads/isr (like
the power control register for instance). It avoids read-modify-write of
a 32 bits value, any participant can tweak a bit without bothering what
other code could do in the other bits of the same register. It also
makes GPIO handling must simpler since you don't have to decide between
FIOCLR/FIOSET, you write a 0 or a 1 at the same place to change a bit
state. Unlike for instance the AVR mega, there is no more problem to
manipulate a GPIO pin on a port that is used with other pins that can be
set/unset both from ISR and appplication .
Something I would like to implement if I have time, is stack checking
using the MPU: add 32 bytes at the end of a stack (on a 32 bytes
boundary) and have the MPU controls that the thread does not overflow
its stack without any speed penalty (canary stack checking also doesn't
see read stack overflow the MPU can trap). The Cortex-M chips really
seems incredible when coming from a 8/16 bit environment, however it
takes time to get all the small details right, like the pending interrupts.
More information about the En-Nut-Discussion