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

Bootloader for LPC1766 - starting the program

I'm working on a bootloader that uses a hex file and I would like to know, how to start loaded program.

In Keil v. 4.24 startup.s file contained this:


Reset_Handler   PROC
                EXPORT  Reset_Handler             [WEAK]
                IMPORT  __main
                LDR     R0, =__main
                BX      R0
                ENDP

And __main function was an entry point for any program. Keil generated hex-file and __main-function address was here as "Linear start address". All was well.

But Keil's 4.5 (or higher) startup.s containes this:


Reset_Handler   PROC
                EXPORT  Reset_Handler             [WEAK]
                IMPORT  SystemInit
                IMPORT  __main
                LDR     R0, =SystemInit
                BLX     R0
                LDR     R0, =__main
                BX      R0
                ENDP

So what is an entry point now? And where does "linear start address" point to?
Is there some reliable way to start loaded program based on information in the hex file?

Moving SystemInit call from reset handler to the actual main is obvious, but a little bit inconvinient.

Parents
  • The cortex chip have magic to set up the stack in hardware before starting the program tat the reset handler.

    That is a magic special to allow the reset handler to be written in C, i.e. to allow every single line of code to be in C. Of course with the special that the initial C function called will have uninitialized RAM, CRTL etc so it will not see the environment the C language standard requires before normal hand-over to the user application.

    If your boot loader and your loaded application will use the same stack memory region then you could ignore the stack information the compiler puts into the binary for your application. But that would then mean that you are locked into a separation of how much stack and how much global variables by a design decision made already when you wrote the boot loader.

    If your boot loader instead looks for the stack information in the vector table just as the real processor would do, then you can decide when you build a new version of the application if you need to grow or shrink the stack compared to previous versions of the application.

Reply
  • The cortex chip have magic to set up the stack in hardware before starting the program tat the reset handler.

    That is a magic special to allow the reset handler to be written in C, i.e. to allow every single line of code to be in C. Of course with the special that the initial C function called will have uninitialized RAM, CRTL etc so it will not see the environment the C language standard requires before normal hand-over to the user application.

    If your boot loader and your loaded application will use the same stack memory region then you could ignore the stack information the compiler puts into the binary for your application. But that would then mean that you are locked into a separation of how much stack and how much global variables by a design decision made already when you wrote the boot loader.

    If your boot loader instead looks for the stack information in the vector table just as the real processor would do, then you can decide when you build a new version of the application if you need to grow or shrink the stack compared to previous versions of the application.

Children
  • >The cortex chip have magic to set up the stack in hardware before starting the program tat the reset handler.
    Riiiiight, so maybe there is something for me to read about this? Or maybe you can tell me what exactly I should do to start loaded application properly?

    (I thought that calling __main will be sufficient to properly initialize stack and so on :C )