Background: I'm a noob. I'm attempting to add the ability to update the application on a NXP LPC2468 by using the USB and adding a bootloader. It sort of works. The unit has an LCD and a keypad. A very minor change to the main application will work without any problem. But for instance, if I add a character to a menu, it will cause a problem: The text for the rest of the application will be shifted or entirely wrong.
The bootloader and the USB driver is located in sectors 0-8 in the Flash. The main application is located in Sectors 9-20. When a USB drive with a correctly named .HEX file is connected, the bootloader will erase sectors 9-20, then load the new main application .HEX from the USB.
When comparing Hex files I can see the problem, but I don't know what it is. If I change an existing character lets say a "1" to a "2", I can see the corresponding value in the .HEX change from "0x31" to "0x32" just as it should. If i then remove that character things in the bootloader section will change. I think this is because the "lookup table" for the text is located here? also the area containing the text seems to be randomly pieced together like the compiler optimizes the locations to save memory. When removing a character this area gets changed quite alot.
Also I can see the now incorrect text in the on chip RAM. The IAP commands if i understand them correctly are only for the flash. How do I update the RAM after a USB upload?
Also the part of the .HEX that changes is not part of my code, at least it is not represented in the MAP file. I don't know what it is.
I'm sure I have alot of ignorance about the inner functions of the processor and the compiler. If fact I don't know even what to search for!
Please help!
Thanks,
Todd
There is nothing forbidden about having a common include file. It's probably quite common to allocate a couple of bytes of RAM for a info structure where boot loader and application can share information.
Maybe the application wants to force a change of program so it sets a magic value in this structure before forcing a watchdog reset.
Maybe the boot loader wants to report some version or statistics to the application - or potentially information that "application region 'A' contains a broken binary".
The problem isn't on the source-code level, but a problem with the linker linking both application and boot loader at the same time. With both linked at the same time, the linker will give them shared helper variables (lots of them from the CRTL) and helper functions.
But the "normal" way to start the main application is to know that the start of the application area stores the applications vector table, which means the boot loader always knows a fixed location relative of the start of the memory region allocated for the application code, where it can pick up a suitable start address.
It's common that the boot loader contains one vector table. Then, before it starts the application, it turns off all interrupts, and then makes use of the reset vector in the applications vector table to activate the application.
So no need for any entry function name or location to be known - the position of the reset vector has a hard-coded offset in the interrupt vector table.