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
Because the Hex file is what is being uploaded through the USB to update the application. My problem is that some information in the hex file is changing in the bootloader section when I make a change to the main application section. That change obviously needs to be with the app and not the boot loader. The Bootloader is removed from the hex file prior to copying it to the USB drive. My problem (well one of them) is that I don't know what this section of the Hex file is so I don't know how to fix it. it is not referenced at all by the Memory.MAP file that I can see.
Bootloader is removed from the hex file prior to copying it to the USB drive.
Sounds like you are developing the bootloader and the main application as a single program. That is the wrong way to do it. They should be developed as two separate programs.
Yes that is correct all in one program. We currently program our units with the ULINK2. Is it possible to load 2 separate programs (bootloader and app) at the same time?
Is it completely impossible to do it as one program or just much harder?
OK, let us see a compiler will have small routines like "mult16", "switch", .... they are unavoidable, a typical piece of C will call 10 or more. This is just a common compiler developement technique, nothing strange.
Now visualize you have your "monoprogram" working and ship units and a small bug is found. You create another "monoprogram" with a small change and delete the bootloader part and load the app part. CRASH!! OOPS the bootloader 'remembers' where whatever small routines that happen to be in the app section used to be and the app will call whatever small routines that happen to be in the the boot section where the new link happened to locate them.
Can you do it as a "monoprogram"? sure, if you do not mind nightmares and bleeding ulcers from overuse of aspirin.
GET THE TWO MADE SEPAR$ATE PROGRAMS NOW
Erik
The Bootloader is removed from the hex file prior to copying it to the USB drive.
Actually no, it isn't. The stuff you remove from the modified whole program's hex file is not "The Bootloader". It's something similar to it, but not the same thing as the actual bootloader portion sitting on the machine. And that's what's breaking your program.
The core of your problem is that your bootloader part contains lots of references to addresses of things in the application part of your program --- the strings you already noticed, but there will be lots more. All those references will generally break apart every time you change anything in the application program. Stuff will move around effectively randomly.
The solution for that problem is to not allow the bootloader to refer to any auto-assigned addresses outside itself. It should only refer to a very small number of absolute addresses, ultimately only one: the main program's base address. The easiest way to guarantee that is to build the boot loader as separate, stand-alone application project. It should have nothing to do with the main program.