Hi,
I'm a newbie with ARM processors, I'm trying to develop an application that will use ethernet port and IAP (in application programing) to reflash a LPC1768. The application is failing at very early stage.
My understanding is that the program in flash is copied to RAM at boot thime and from there it runs. Our plan is to use the code running in RAM to receive new file via TCP and copy this one into flash.
The manual says that in order to use IAP the interrupt table needs to be moved away from address 0x0000000 (flash) and into RAM.
What my test is doing so far is:
- relocating and copying the interrupts vector table as manual says :
01: #define VTOR_OFFSET 0x20080000 02: . 03: . 04: . 05: long int* source = (volatile long int*) 0x00000000 ; 06: long int* dest = (volatile long int*) VTOR_OFFSET ; 07: SCB->VTOR = VTOR_OFFSET; 08: memcpy(dest, source, 256*4); 09:
This parts works fine, we know this because the interrput handler is invoked correctlty after copying interrupt vector table.
The problem comes later when we prepare and delete the sectors in flash memory (sector 0 to 29) using IAP, at this point the applications dies instantly. We are probably missing something very obvious.
I suspect that this could be explained by the following posibilies:
1.- Program doesn't run fully from RAM, some of the code could been executed from flash, if this is the case how we make sure that all code runs in RAM?
2.- Reset of sector 0 may cause automatic reseting of system (no very likely but is a possibility).
Do any of you have a clue what could be causing this issue and how to solved??
Kind Regards
"...the interrput handler is invoked correctlty after copying interrupt vector table"
I think your reasoning is flawed there!
After copying, you have 2 instances of the vector table; one in Flash, and one in RAM - how do you know which of those vector table copies is actually being used...?
Don't NXP provide any examples of doing this?
there is no flaw there, because the instruction:
SCB->VTOR = VTOR_OFFSET
tells the processor where to find new table, additional to this if we omit copying the table (memcpy instruction) the interupt handler is not invoked.
If there is an example that you know please point me to it.
Kind regards
Why do you think the program runs from RAM in the first place? The 1768 has less RAM than flash, so it isn't even possible to copy the full flash to RAM. Just because a processor can run programs from RAM, that doesn't make it a forced requirement. It's possible for the linker to create a binary that contains code to copy the application into RAM, but that isn't a standard build.
Are you sure that it is good to reconfigure the processor to move the interrupt vector table location before you have done the actual copying? Such a change requires that you have interrupts disabled. It's more elegant to setup the table first and then set the new offset.
Points noted, thanks for the comments,
I will invert order of instructions. And I will assume that my program may be running in flash.
I think the best option is to have a secondary bootloader in sector 0 that will write incoming program in higher sectors of flash and transfer control when download is finish using VTOR realocation.
Thanks again.
You should _always_ have a _good_ boot loader in the chip, to make sure that a power loss at any random state of an update will be safe, i.e. that it can either finish, or is ready to accept a new firmware transfer.
Copying some of the code to RAM and then reprogram the flash means that the flash will for a short while be without one or more critical sectors.
=> If there is an example that you know please point me to it.
From this page: " href= "http://ics.nxp.com/support/documents/microcontrollers/zip/an11071.zip"> ics.nxp.com/.../an11071.zip
Thanks all for your help, I will use the information that you gave me, have a nice weekend.