We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hi all,
hope I did not miss a similar topic here. I searched, but did not find anything appropriate.
I want to have my device (LPC2368) to be updatetable via USB. To accomplish that, I think about two separate applications, a simple + small USB program (as H I D device, located at adress 0) that, upon reset checks for an USB link and, if none exists, starts the second "main" application, starting at address, say 0x8000.
Upon an USB connection at startup, the bootloader would erase/program the flash using IAP.
How do I have to set up uVision/the linker to build this application a) at adr 0 for debugging / test purposes and b) at the higher address for release versions
any tips highly appreciated kind regards + thanx in advance
Ulrich, I don't know your processor in detail but an STR912 is better to boot from flash bank 1 when a bootloader is involved as a sector size of bank 1 is only 8 KB (or 16 KB, depending on the processor flavor) rather than 64 KB on bank 0. You would have to switch banks once you are ready with your IAP. I think ST's USB library offers the possibility to see if a device is coupled - I don't remember which register exactly is involved, sorry. I also thing that ST's site (http://www.st.com) also offers downloads for STR7 (ARM7) processors that demonstrate IAP using Ethernet and a serial port. At least, it exists for the STR9.
sorry for not providing proper details. CPU is LPC2366 (fix) , ST is no option currently using MCB2300 to test
Ulrich,
I've done the same in my project (my bootloader also encrypts data sent by the PC to avoid copying). The trick is, that all of your code (except of the startup code) must run in RAM and the interrupt vectors have to be there as well (don't miss to set MEMAP=2).
You have to write a scatter file telling the linker to copy the code from flash to RAM and execute it there. Check the MAP file after building your bootloader and correct the scatter file to have library routines still sitting in the flash are execute from RAM as well.
By doing so, you can even make the bootloader updating itself (as I do). When you want to update your app only, you can make your live easier, as the routines calling IAP (and interrupt routines) have to be in RAM only.
You can contact me off-group if you need more details.
Regards Herbert
No need to run any code in RAM. Only the vector table for the downloaded application needs to be in RAM.
Figure out a couple of sectors to allocate for the boot loader (obviously including the first sector), and create a scatter file for that.
Figure out a second set of sectors to use for your application, and create a scatter file for that.
Figure out a way for the boot loader to know if there is a valid binary programmed.
Figure out a way for the boot loader to know if you - even if a valid binary exists - wants to upgrade to a newer version.
Life is easiest if the boot loader doesn't need to play with user/system mode while deciding if it should start an existing application. If it performs an update, then it can use whatever hardware that is available just as long as it either restore all state before starting the application, or performs a sw or wd reset and then jumps into the application.
The only time when it is needed to run some code from RAM is when performing the actual reprogramming of the boot loader, in which case the old boot loader could have copied the new boot loader to RAM, then jumped to a tiny function that calls the IAP functions to erase the original boot loader and then copy them to flash. However, this method may kill the board if power is lost at the wrong time.
A better way is to split the boot loader into two halves. A tiny one that is never erased and that detects if some flash sectors contains the main part of a new boot loader and in such case replaces the main part of the boot loader. Obviously, the replaceable part of the boot loader would have the USB support, while the fixed part (a single 4kB sector) would just check for valid boot loader/application and perform copying.
thanx all, esp. Per. That double bootloader stuff sounds quite smart to me.
Meanwhile I managed to get the main app to load at a higher address and had a first in depth look at all the scattering.
The question remains if/ how I can manage to switch between the two different application types (app for debug at 0, app for distribution eg at 0x8000)
the scatter file requires a define, my 'C' application should have a define and the bootloader code needs a define too. Is it possible to reduce that to one single position to switch ?
HI
I have to push this topic up as I still see no solution. Other IDEs provide means for different "build types" eg "Debug" or "Release". This would be the solution here as I (afaik) have many different options to switch in order to compile for low or high load. (eg ASM switch for bootloader, entry point, a 'C' define ..)
Can't I have those two different project types in one uV session and switch by one single flag ?
tia Uli
Hi Uli
think about 2 applikations.
The first one is a normal and can store data in the flash (the bootware)
Booting, checking if the data contains valid stuff and either starts the code at 0x8000 or switch to a selfwritten download routine.. waiting for data over CAN, comX, USB Ethernet or what ever.. your have to write it.
The firmware is a second and independence application createt with UV3. Just change the address-range in option - target from 0x000 to 0x8000. Use vectortable in RAM and copy at firmwarestart the table from 0x8000 to 0x40000000.
Starts from bootware in ARM-mode the address 0x8000.. To download a one the firmware is able to erase one flash sector and cause than a reset, the bootware detects this and runs the doownload-part.
works great :)
You can have two targets in the project file. You can use different scatter files for the two targets.
Guenter: thanx
Per: double thanx. That was the option I was looking for. I must say it is hidden well under "manage components" .. :) but that is what I was looking for.
ULI
Which advantage do the programer has from the way with 2 scatter files?
And what is with source code files? 'Bootware' and 'firmware' use diffenrent sets of files..
When i try to add files in target A they appear also in target B. But there are only few files which must be in both projects.
Guenter
You can specify which files that should be built for the different targets. You may have common code - such as CRC32 or similar - that should be built by both targets.
Two scatter files means that the boot loader and the application hsa completely different sets of memory available for the linker to use. If you don't need to advanced layouts, then you don't need manually created scatter files, but could just define two sets of memory mappings directly in the property dialogs.
Hi,
I am trying to write a bootloader for the STR912 with IAP. I should put the bootloader in the code in the small flash and while this is executing, the primary big flash is being updated in case of USB or Can update for IAP. Do you know where can I find an example of a similar bootloader? I donÂ't have much experience and I donÂ't know where to start from.
Thanks in advance.
By the way if you can send me some kind of example it will be great.
miltongodinho@hotmail.com
Thanks