--- In l..., Miguel Angel wrote:
>
> I didn't realise that, It's an important point when you want to setup your
> stack correctly.
> An small fix should handle that situation, may be changing the startup.S of
> bootloader
> not to setup/change the mode of the system down to USER. Or recovering the
> SVC status
> back before leaving the bootloader (A swi handler should be enough for
> that?)

Hi,
I just found a trick, reading ARM's manual. I had to change the Startup.s in the bootloader, so instead of entering the USER mode, it enters the SYSTEM mode: it is equivalent to USER mode (same register set) but with privileges. For a vanilla Startup.s from Keil, the line to change is near the end of the file:
; Enter User Mode and set its Stack Pointer
; COMMENTED OUT MSR CPSR_c, #Mode_USR
; Enter SYSTEM Mode and set its Stack Pointer
MSR CPSR_c, #Mode_SYS

>
> I thought that in that situation the ARM7 TDMI would raise an
> exception/abort/"privileged instruction", etc.

The good old ARM core runs like a panzer-tank over these poor instructions: no effect!

>
> Greetings,
> Miguel gel.

An Engineer's Guide to the LPC2100 Series

I didn't realise that, It's an important point when you want to setup your
stack correctly.
An small fix should handle that situation, may be changing the startup.S of
bootloader
not to setup/change the mode of the system down to USER. Or recovering the
SVC status
back before leaving the bootloader (A swi handler should be enough for
that?)

I thought that in that situation the ARM7 TDMI would raise an
exception/abort/"privileged instruction", etc.
Greetings,
Miguel gel.

Hi,

change your low-level startup code for the boot-loader to leave the CPU
in svc mode.

Foltos

On Mon, 11 May 2009 09:17:38 -0000, you wrote:

>Hello,
>I have a doubt about secondary bootloaders.
>Here I will try to explain my case, but I think it could be a general issue.
>The bootloader and the application are separate projects, each one with their own stacks & so on.
>The bootloader is the one that starts first, and he decides if the application can be started.
>The problem I have is that, when the bootloader jumps to the start address of the application, it is in USER MODE;

Why? Who is putting it in User mode?

As the ARM7 parts have no hardware memory managementm, is there any point in using User mode?

Hello,
I have a doubt about secondary bootloaders.
Here I will try to explain my case, but I think it could be a general issue.
The bootloader and the application are separate projects, each one with their own stacks & so on.
The bootloader is the one that starts first, and he decides if the application can be started.
The problem I have is that, when the bootloader jumps to the start address of the application, it is in USER MODE;
thus, the application in entered in USER MODE, but, being built as a separate project, it wants to set its own stack pointers.
This cannot be done for privileged modes (IRQ, SUPERVISOR etc.), and assembly instructions that refer to these steps are simply ignored by ARM core running USER.
Result: a stack mess, the application runs with stacks inherited from bootloader.
How can I do to correctly enter the application in privileged mode (or, more precisely, SUPERVISOR MODE) ?

I downloaded NXP various "secondary bootloader" application notes, but I found no help, they enter application in USER MODE.

PS: I use KEIL compiler tools.

Yeah,

Just set the MEMMAP to remap the vectros to RAM and put the branchs for the IRQs handler in RAM. Never thought that.

Regards,

Fernando Almeida.

In your main app startup, can you not copy the main app interrupt vectors to RAM and then remap the vectors to RAM?

That's what I do - works fine.

Rgds,
Martin

Hi,

That's just a ideia of how I would do the firmware upgrade. I need to protect tha bootloader code from power failures during updates, so the flash sector where I put the bootloader (wich addrs starts at 0000h) cannot be erased, but this sector will also contains the interrupt vectors, and if I need to modify these vectors it will be not possible since I wont erase the sector wich they are. So what I mean by mirror the IRQs vector, was to put at each vector a jump to a address that is bounded inside the flash sector that is erased, so the program use these address as they were the IRQs vector.

Example:

addr 0x0000 (reset address)
B addr 0x1000 (located at a sector that is erased)
addr 0x0004 (IRQ address)
B addr 0x1004 (located at a sector that is erased)
addr 0x0008 (FIQ address)

B addr 0x1008 (located at a sector that is erased)

addr 0x1000 (reset address)

B Cstartup

addr 0x1004 (IRQ address)

B IRQ_Handler

addr 0x1008 (FIQ address)
B FIQ_Handler

Best Regards,

Fernando Almeida.

Hi

Thanks for reply....
I am using the IAR compiler to compile the code. And according to their manuals they are linking the cstartup file in hex. Also in map file I can see the cStartup location.
I had now question about the last sentence " For the IRQs I would mirror the vector in the pages where I put the program." Will you please explain this in detail.

Hi,

when you've finished downloading the firmware you shold jump to the Cstartup (I'm assuming that the first bootloader you're talking is the ROM bootloader). But remember that when you download the firmware it has to came with the "new" Cstartup for the new firmware (as alredy pointed the Cstartup initializes memory - clear and set variables set heap and stacks for the diferent modes, etc).
If I would do something like this, I would separte a flash page for the second bootloader, as this never page would never be erased my bootloader would be intact even on a power failure during a firmware upload. And put the program (inclunding the Cstartup) in the other flash pages. For the IRQs I would mirror the vector in the pages where I put the program.
Anyway, just be careful to also upload the Cstartup.
Sorry for my bad English.

Best Regards,

Fernando Almeida