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

[Bernard Fouché]

Le 17/01/2012 23:41, Ole Reinhardt a écrit :
> And once more...
>
>> Ole, please check.
> Checked... LPC memory layout has the flash at Offset 0x00.
>
> Bye,
>
> Ole
FYI, I'm currently porting an application on eCos on a LPC17XX. Things 
to consider for the linker script:

1) The CRC  at offset 0x1C to tell the chip that the code in flash is 
okay. OpenOCD overwrites this location with the correct CRC. If the 
linker script forgets about this location and stores code starting at 
0x0, then some code is trashed.

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.

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.

An eCos linker script patch is there: 
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001395

At last a tricky problem: if the MCU clocks slowly an issue hidden with 
higher clock frequencies may appear ( IMHO at high clock frequencies the 
issue still exists but the dust is more likely hidden under the carpet).

The issue is the following: FIFO based peripherals like UART, SPI, CAN, 
etc. report interrupt condition in some register. An interrupt is 
triggered. If the OS follows a scheme similar to eCos (short ISR that 
schedules a DSR for complex processing), another interrupt condition may 
arise between ISR processing and DSR processing. This will raise flag(s) 
in the interrupt pending register(s). When the DSR code is finished, 
according to the way the DSR is written, another interrupt is triggered 
immediatly, because of the interrupt pending registers. The DSR code is 
fired again but find no work to do (because it looped until the 
interrupt conditions are cleared, so a single previous DSR run processed 
everything). (may be this is not very clear ;-) )

The solution I found is, in the DSR code, to work that way:

- enter a loop
- always clear the pending register(s)
- process the register describing the interrupt sources to consider
- if there is nothing to do, exit loop
- otherwise loop again


Since I didn't go into such details for NutOS for years, I don't 
remember if the ISR infrastructure is similar to eCos (ISR+DSR). Anyway 
it's something to keep in mind when writing drivers, it is handy to have 
a counter of interrupt processing that is fired but perform no work. If 
the counter is not zero, then you may face this issue. Just my 2 cents 
to avoid someone loosing time for similar issues in another environment...

     Bernard