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

[Bernard Fouché]

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 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.
Hi Ole,

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
> arise?
>
> 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.

   Bernard