• State Not Answered
  • Locked Locked
  • Replies 7 replies
  • Subscribers 22 subscribers
  • Views 3740 views
  • Users 0 members are here
Options
Related
How was your experience today?
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

How to reflash LPC1768 using IAP

christian crosa

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

Parents
  • 0 in reply to christian crosa

    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.

Reply
  • 0 in reply to christian crosa

    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.

Children