[En-Nut-Discussion] devnut_m3n: lpc1768_flash.ld and lpc1778_flash.ld Linker scripts
bernard.fouche at kuantic.com
Wed Jan 18 12:20:12 CET 2012
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.
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
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:
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...
More information about the En-Nut-Discussion