adding code-updater service to my LPC software

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

adding code-updater service to my LPC software

426 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by oryo on Thu Jan 09 06:25:28 MST 2014
Hello,

I'll find it a bit hard to phrase my needs, so forgive me if the headline is a bit unclear.

First thing first - my setup:
1. LPC Link 2
2. LPC1112LV/103 chipset , installed on some proprietary board
3. LPCXpresso 6.0.4
4. Linux OS

I've implemented a software for the LPC1112LV/103 device I have, that performs several procedures. Lets name it "CSW" (Controller Software).
I'd like to add a feature to my CSW: an Updater service.
Upon invocation, the Updater service will copy data to the SRAM (using SPI protocol, that I've already implemented), and then burn the Flash memory using data from SRAM, by utilizing the LPC IAP command set.
Since the code needs to be run from somewhere, some part of the flash memory must be dedicated for this Updater service. This part of the flash memory shall not be changed by the Updater.
Since the Flash memory is 4 time larger than the SRAM memory, this copy-burn transactions will have to occur several times. This doesn't seem to affect anything but I thought perhaps its worth mentioning.

So if I assume my Updater service code is smaller than 1KB - I'd like my flash memory to be mapped like this:
* Total flash size: 16KB
* 0x0000 - 0x3BFF : CSW code (15KB)
* 0x3C00 - 0x4000 : Updater code (1KB)

My question is: how can i do that, using the LPCXpresso environment?
I thought about having two separate projects (one for the CSW, one for the Updater), but I'm not sure how to burn the flash memory properly.
Also, since some code is shared between these 'projects' (the SPI driver for example), i'm not sure its the smartest way to go.
If you have any other SW 'design' for the need I've described - I'll be happy to hear it out.

thanks !
Labels (1)
0 Kudos
5 Replies

395 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by MarcVonWindscooting on Fri Jan 10 18:47:41 MST 2014
I personally would start with the Updater.
You have to decide, how to invoke that. My choice (like the primary bootloader does) checksum of the CSW FLASH area. If that is invalid at boot up, then  invoke the Updater.

That way, 'calling' the Updater is simply erasing the CSW FLASH and reboot by intenionally not feeding the watchdog for example.

The Updater should be independend from the CSW.
How do you plan to provide the new CSW image from outside? Most probably you will have to write a program running on a PC or other FLASH update device. This device 'speaks' a protocol the Updater 'understands'.

Your CSW should finally be linked in a way, that the image starts at 0x400. Vector table and program entry point shifted up by 1k. The Updater finally boots your CSW by finding the entry point, stack size and by re-mapping the vector table (VTOR register).
I haven't done this for FLASH yet. But I develop 99% all of my programs with an 'Updater' that puts the programs into RAM and executes from there. Same boot process as I described. I've done for LPC21/23 (ARM7TDMI), LPC17 (Cortex-M3), LPC11/LPC8 (Cortex-M0). It's the very first program I develop for every new architecture - in assembly language! To date I always managed to write this program without using even a single bit of the RAM and it's always been about 800 bytes FLASH or less. Your 1k size estimation seems reasonable unless you use a complicated communication peripheral or protocol.
0 Kudos

395 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by LabRat on Fri Jan 10 07:03:52 MST 2014

Quote: oryo
If you have any other SW 'design' for the need I've described - I'll be happy to hear it out.



Last not least LPC11C family offers C_CAN on-chip bootloader...
0 Kudos

395 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by lpcxpresso-support on Fri Jan 10 00:18:18 MST 2014
This is known as a secondary bootloader and there are several examples available. It is secondary, because there is also a primary bootloader in the ROM which runs immediately after RESET.

There is a good example (for LPC1768 - but the techniques are the same) in the RCB1768_cmsis examples.
0 Kudos

395 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by oryo on Thu Jan 09 07:06:05 MST 2014

Quote: MarcVonWindscooting

Quote: oryo

* Total flash size: 16KB
* 0x0000 - 0x3BFF : CSW code (15KB)
* 0x3C00 - 0x4000 : Updater code (1KB)



I'm quite sure, you want the Updater code at address 0x0000 because the LPC1100 boots from there. Otherwise you can easily end up with
wrong code in the first sector and your Updater never getting a chance to execute again to correct that. It depends on whether you need a fail-safe system or not. If you let a customer do the FLASH update, you definitely need a fail-safe system, believe me ;-)

I understand the wish to have it the way you describe. That would prevent you from changing the way the CSW has to be linked - compared to 'normal' programs. But update is dangerous and can render the system unusable.



I put the updater on the end, so if someone burns the Flash, it will not be removed (since the Flash burning procedure mostly start from offset 0x0000).
However, since if someone burns the flash he'll probably burn it until the very end - your way indeed seems to be better... :)

Either way - lets go with your suggestion:
* Total flash size: 16KB
* 0x0000 - 0x03FF : Updater code (1KB)
* 0x0400 - 0x3BFF : CSW code (15KB)


How can I assure that the Updater code resides within the first 1KB, and that the rest of the code begins only after the 0x0400 boundary?

The code's memory mapping is my biggest issue...
0 Kudos

395 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by MarcVonWindscooting on Thu Jan 09 07:00:02 MST 2014

Quote: oryo

* Total flash size: 16KB
* 0x0000 - 0x3BFF : CSW code (15KB)
* 0x3C00 - 0x4000 : Updater code (1KB)



I'm quite sure, you want the Updater code at address 0x0000 because the LPC1100 boots from there. Otherwise you can easily end up with
wrong code in the first sector and your Updater never getting a chance to execute again to correct that. It depends on whether you need a fail-safe system or not. If you let a customer do the FLASH update, you definitely need a fail-safe system, believe me ;-)

I understand the wish to have it the way you describe. That would prevent you from changing the way the CSW has to be linked - compared to 'normal' programs. But update is dangerous and can render the system unusable.
0 Kudos