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
So if your company is making one compile/link pass that ends up generating both a boot loader and an application - how have you managed to get the compiler/linker to not call any helper function that gets stored in one memory area from the other memory area?
Or is the boot loader written 100% in assembler?
The nice thing with building both in the same step is that it looks like it works, until you make the wrong type of changes in the code. Suddenly a change in the boot loader generates changes in the application area. Or a change in the application generates changes in the boot loader area. And when that happens, you are in a deep pile of ***. The equipment already shipped can't be updated until the problem is solved. But if the shipped boot loader has a reference into the application area, you just have to figure out how to get the compiler to produce a new application that still has the exact same contents at that location.
By the way - all boot loaders are expected to have code to verify that they correctly program the application area. But that is something completely different from having a boot loader that doesn't contain unexpected, "hidden" references into the application area, that makes the boot loader fail after an update of the application.