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

[Ole Reinhardt]

Hi Bernard.

> 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
entry here.

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

> 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: 
> http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001395

Great! Thanks!

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

Which CPU do you use?

Bye,

Ole

-- 

Thermotemp GmbH, Embedded-IT

Embedded Hard-/ Software and Open Source Development, 
Integration and Consulting

http://www.embedded-it.de

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