Hello,

I had question related to program startup.
I am using LPC2106, when I press reset, Primary bootloader get called. Then my secondary bootloader comes in picture. It will download the hex file from UART and burn the flash. Now I need to call new application.
Whether I jump to main function of new downloaded code or to cstartup function.

Thanks Start a New Thread

C startup involves clearing all uninitialized RAM (.bss) and setting all initialized RAM (.data). To do this, crt.s (or whatever it is called, it's the startup code) gets symbols from the linker and uses them to figure out where these memory blocks are located.

So, the startup code knows very well where the .bss and .data segments are for your secondary bootloader but it knows nothing about the memory requirements for the downloaded program.

It looks to me like your downloaded program also needs to have some kind of startup code and this would be the entry point, not main().

You also need to deal with the interrupt vectors. Perhaps remap them into RAM from the startup code of the downloaded program.

I don't see the purpose of the secondary loader if all it does is what the built-in loader already does.

Richard Start a New Thread

Hi Richard,

Thanks for the reply.

Actually I need it to give customer capability to download the new firmware version. The new hex file is recevied on UART1 and sent by our custom application.

So after completing the download shall I directly call cStartup location ( from map file) or do I need to exit from my bootloader application.

Thanks, Start a New Thread

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 Start a New Thread

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. Start a New Thread

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. Start a New Thread

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 Start a New Thread

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. Start a New Thread

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. Start a New Thread

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? Start a New Thread