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
Address 0x40000000 is in RAM.
So your code can be anywhere in flash (except the first 64 bytes or something like this).
The interrupt vector table is first within the application binary you build. The startup code copies this interupt vector table into the start of RAM. Then performs a remap so the first bytes of RAM is visible on top of the first bytes of the flash.
So it doesn't matter where your application is - the remapping is always 0x40000000 -> 0x00000000. The processor core finds the copied application vectors at the start of the flash without knowing that it's remapped RAM there. It's just happy to find vectors. And the vectors points to the correct positions in your application, since the linker linked your application for the specific position you configured to use for your application area.
But it is important that your boot loader makes sure all interrupts are disabled before you jump to the application, or hw interrupts may accidentally return back into the boot loader while the application is preparing the remapping.
Hi Todd,
It is strange to me, that you use LPC2300.s for a LPC2468. And the mentioned "os_sys_init function" shows that you also use the RTX. Quite complex for me.
I would suggest you to start with a correct working example, test it and trace it, then you know how these stuff work. This way would be simpler. After you understand these stuff, you can then tailor it for your need.
Go to the below web page: ", then you will find several zip files to download. they are application notes with software.
Go to the below web page: " href= "http://ics.nxp.com/support/documents/microcontrollers/zip/an10764.zip"> ics.nxp.com/.../an10764.zip
A combination of a bad USB drive, failure on my part to properly set up the debugger and overlapping IRAM1 sections were my downfall. After reading your post yesterday about the way the Vector remap works, I decided to give up on trying to debug it and just try to upload the application straight off the USB using RAM_INTVEC, REMAP & RAM_MODE in the assembler options and it worked!
Thanks to all of you who tried to help me understand the inner workings of the compiler and the processor! Hopefully I will remember some of it next time I have to work on this system.
Thanks!