[En-Nut-Discussion] devnut_m3n: lpc1768_flash.ld and lpc1778_flash.ld Linker scripts
ole.reinhardt at embedded-it.de
Wed Jan 18 13:48:41 CET 2012
> 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.
Yes I know about this issue. You have to place some code at 0x00 (vector
table). The CM3 vector table in the Nut/OS startup code has a reserved
So no problem here...
> 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.
> 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?
> 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
Many thanks for this hint too!
> 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...
Many thanks! Maybe I may came back with some further questions if they
Which CPU do you use?
Thermotemp GmbH, Embedded-IT
Embedded Hard-/ Software and Open Source Development,
Integration and Consulting
Geschäftsstelle Siegen - Steinstraße 67 - D-57072 Siegen -
tel +49 (0)271 5513597, +49 (0)271-73681 - fax +49 (0)271 736 97
Hauptsitz - Hademarscher Weg 7 - 13503 Berlin
Tel +49 (0)30 4315205 - Fax +49 (0)30 43665002
Geschäftsführer: Jörg Friedrichs, Ole Reinhardt
Handelsregister Berlin Charlottenburg HRB 45978 UstID DE 156329280
More information about the En-Nut-Discussion