This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

What is the extra information in my .HEX file?

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

Parents Reply Children
  • 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?

  • 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