Hello everyone, I'm having a little issue with flashing (and booting) program from another program itself running on the flash (IAP). Let me start by expliciting the context :
- IDE : µvision4 - JTAG controller : ULINK2 - Application board : MCB1700 (with LPC1768 - 512kB on chip flash)
I'm writting an small application for some project, and that works fine. I wan't to be able to update the software directly from the application. Since I will only have an ethernet connexion with the board in the end, I cannot use the on-chip bootloader via the RS-232.
I'm using (or at least trying to) use the following scheme to update the software. I divide the flash in 3 parts: the bootloader , the software 1 and space for the update (software 2). So the Flash memory map looks something like this :
+----------------+ 0x0007 FFFF | | | Software2 | | | +----------------+ START2 | | | Software1 | | | +----------------+ START1 | Bootloader | +----------------+ 0x0000 0000
The bootloader just decides which software should be booted (by reading relevant information in an EEPROM). The actual flash writing is done from the application, uploading the file is done by using the web serveur in the application.
Now the file transmission via http works fine, my code for writing the flash using IAP routines is sloppy but functional, and the bootloader (which is really a boot chooser) is rolling too.
The problem is that for a software to run it must know at compilation where it will be runned in the memory (I do this by tampering with the scatter file). But this is no good because in the future I don't want to bother about which part of the flash I'm currently using before making an update. So what can I do (beside writing a real ehternet bootloader) to solve this ?
I hope I have expressed the problem clearly enough. Good day to you all :)
Lots of compilers produces relative jump instructions (if the processor does support them) just because they get away with fewer relocation entries in the object files - so less work for the linker.
But function calls are normally always absolute, since calls often spans different source files while jumps normally are within a function. And a function pointer can't be relative without somewhere getting a base address. This means that a relative function pointer needs to be based, i.e. have a predefined base such as relative to a specific processor register.
All the more peculiar for the stuff to run than. Unless... I think I have an explanation. For my test, I have flashed the same software on the two parts. Which means that even if I boot on the second part, it will call functions in the first part, and since they are the same, there is no issues. But if I had made a real update, it would have failed (miserably I might add).
So back to square one I guess...