I have answered my question. Here is the description of what I was looking for.

It was necessary to map interruption vectors of the Application program (which is at 0x80010000) to RAM memory.

The solution to my question is at AN10835 (LPC secondary bootloader for code update using IAP). In that document, among other subjects, it is detailed how to map interruption vectors to RAM memory.

Basically, it is necessary to store the interruption vectors in RAM,

IF :DEF:VECINT_RAM
ADR R8, Vectors
LDR R9, =RAM_BASE
LDMIA R8!, {R0-R7}
STMIA R9!, {R0-R7}
LDMIA R8!, {R0-R7}
STMIA R9!, {R0-R7}
ENDIF

And to set MEMMAP to 2 in the Startup.s

LDR R0, =MEMMAP
IF:DEF:VECINT_RAM
MOV R1, #2
ELSE
MOV R1, #1
ENDIF
STR R1, [R0]

Where RAM_BASE is defined as RAM_BASE EQU 0x40000000

And VECINT_RAM is defined (using keil) at Project > Options for Target xxx>ASM>Define

In the Project>Options for Target it is interesting to reserve space for interruption vectors in RAM. The IRAM start address should be 0x40000040 to keep the first 64 bytes for the interruption vectors.

Grosella

An Engineer's Guide to the LPC2100 Series

Hello,
I think my problem is very close to this thread, but reading it and extra docs I have already some doubts, I hope you could solve me.

I have MyBootloader which is at 0x80000000 and MyApplication which is at 0x80010000. When I reach the main() of MyApplication SOMETIMES it is restarted and goes back to MyBootloader, and OTHER TIMES, an exeption occurs.

I am newbie in this, so I have not very clear if my problem could be related to VIC remap. I am using a LPC2220 and Keil. I nees some clues to solve my problem.

* I have modified in the target of MyApplication the start address to 0x40000040 to let space to interruption vector.

* I am not sure where in the startup.s of MyApplication I have to make any modification to remap in RAM or if I have to change in the Options>ASM something different to EXTERNAL_MODE.

Do I have to deal with other issues related to user mode, supervisor mode...? I am completely newbie in this.

Thanks in advance,

grosella

Hi,

I put this issue to one side for a couple of weeks for various reasons hence the delay in replying.

I have remapped the interrupt vectors to RAM by setting MEMMAP = 2. However my code now crashes as I step throught the main() function in my code.

Does anyone have any ideas as to what is causing this please?

Thanks

Andrew

Hi ,

You have to place the piece of code in Startup file as below,

FIQServiceHandler EQU 0x20000
...
...
FIQ_Addr DCD FIQ_Handler
...
...
FIQ_Handler B FIQServiceHandler

In the application,

#define FIQ_HANDLER_ADDRESS ".ARM.__at_0x20000"

#ifdef APPLICATION_CODE
__attribute__ ((section (FIQ_HANDLER_ADDRESS)))
void FIQServiceHandler(void)__irq
#else
...
..
#endif
Remember one thing, "FIQServiceHandler" in startup file and
"FIQ_HANDLER_ADDRESS" in app code should have same fixed address.

Hope this helps.

Regards,
Ramdurai.B

Hi Ramdurai,

Thankyou for your reply. After spending a lot of time reading documentation I've not been able to work out how to place FIQ service handler at a fixed location. How did you do it?

Thanks

Andrew

On Wed, 4 Mar 2009, ajellisuk wrote:

> Is there a potential issue with absolute addressing?

Not that I've seen and I've done this for two seperate projects now.

-Kenny

--
Kenneth R. Crudup Sr. SW Engineer, Scott County Consulting, Los Angeles
O: 3630 S. Sepulveda Blvd. #138, L.A., CA 90034-6809 (888) 454-8181

Hi,

I also faced similar kind of problem but i didnt remap the vectorTable to RAM rather I tried the following way,

In my case, i had UART2 configured as FIQ interrupt.

After jumping from Bootloader to application and when a UART2 - FIQ Interrupt occurs in the application, it jumps to reset location(obviously bootloader code) and got stuck over there and unable to handle FIQ Interrupts for application. (I believe this is what happening to you).

Make sure the Boot Loader uses only IRQ interrupts which will take the ISR address from VICVector Table (so?? no issues!!). Hence, in my case, the UART2 is configured as FIQ in application but IRQ in boot block and works fine. FIQ service handler will never occur in boot mode.

Also, the FIQ Service Handler is placed at the fixed address(Say e.g 0x20000) in the application, will get called when a FIQ exception occurs. This solves the issue of handling the FIQ in the application and the program behaves normally.
Any Comments?

Regards,
Ramdurai.B

--- In l..., "ajellisuk" wrote:
>
> Hi,
>
> I have stepped through the assembly code of my bootloader. The code branches to the main executable and steps through to a certain point then branches back to the bootloader. The steps are as follows:
>
> My bootloader has the line in C:
>
> return ((int(*)(void))USER_CODE_ADDRESS)(); // 0x18000
>
> Which generates the following assembly:
>
> MOV R0,#+98304
> MOV LR,PC
> BX R0
> B ??main_1
>
> When I hit the line "BX R0" the CPU jumps to my main executable as I would expect. I then hit this line:
>
> BL 0x02A5F4
>
> Which branches to this line:
>
> LDR R12, [PC, #+0]
>
> The contents of R12 is 0x4878. This address takes the CPU back into the bootloader code where it gets stuck in the following loop:
>
> __exit:
> STMDB SP!, {R122,LR}
> BL __iar_sh_stdout_close ; 0x4618
> MOV R1, #0x26
> ORR R1, R1, #0x20000
> MOV R0, #0x18
> SWI 0x123456

Hmm.. have you set up your main app to copy/map interrupt vectors to RAM? If not, the first interrupt in your main code will just jump back to the boot code table!

I use a secondary boot loader to load main app updates from an SD card. My Rowley development environment has a #define to tell the compiler to generate the code to use RAM-mapped interrupt vectors. This works fine - the secondary boot loader jumps/calls to the main app, which then copies its own vectors to RAM and remaps the table there. The main app then runs up without problems, (mod. my bugs, of course).

When the reset button is pushed, the table gets remapped to flash and the bootloader runs again. It can look for update files on the SD card and either load them or just jump to the existing main app.

Rgds,
Martin

Hi,

I have stepped through the assembly code of my bootloader. The code branches to the main executable and steps through to a certain point then branches back to the bootloader. The steps are as follows:

My bootloader has the line in C:

return ((int(*)(void))USER_CODE_ADDRESS)(); // 0x18000

Which generates the following assembly:

MOV R0,#+98304
MOV LR,PC
BX R0
B ??main_1

When I hit the line "BX R0" the CPU jumps to my main executable as I would expect. I then hit this line:

BL 0x02A5F4

Which branches to this line:

LDR R12, [PC, #+0]

The contents of R12 is 0x4878. This address takes the CPU back into the bootloader code where it gets stuck in the following loop:

__exit:
STMDB SP!, {R122,LR}
BL __iar_sh_stdout_close ; 0x4618
MOV R1, #0x26
ORR R1, R1, #0x20000
MOV R0, #0x18
SWI 0x123456
B 0x004798

I have set up my linker to place the code at the location 0x18000. Is there a potential issue with absolute addressing? Is it possible to set up my compiler to use relative addressing? I'm Using IAR embedded workbench.

Can someone shed some light onto my problem please?

Thanks
Andrew

Hi Bastian,

I stepped through the C code. I didn't think to step through the
assembly. I'll try that tomorrow.

Andrew