Bootloader vector table problem Topic is solved

ChibiOS public support forum for topics related to the STMicroelectronics STM32 family of micro-controllers.

Moderator: RoccoMarco

doddi
Posts: 10
Joined: Sun Dec 04, 2016 11:44 am

Bootloader vector table problem

Post by doddi »

Hi All,

I am fairly new to ChibiOS and I am having trouble implementing the use of a bootloader, my specifically how the vector table is working.

My Bootloader sits at 0x08000000 and my app sits at 0x0800C000. If I flash the bootloader and the application it seems to work fine, i.e. it will jump from the bootloader to the application and run as normal.

My problem is that if I erase the flash entirely and flash just the application then I get unhandled exception. This tells me that the vector table isnt initialised correctly to 0x0800C000.

I have defined in my Makefile:

Code: Select all

UDEFS = -DCORTEX_VTOR_INIT=0x0800C000U
UADEFS = -DCORTEX_VTOR_INIT=0x0800C000U


I can see when debugging that the initialisation of ChibiOS is calling:

Code: Select all

SCB->VTOR = CORTEX_VTOR_INIT

I have even copied this line throughout my main function to see if it was getting re-initialised somewhere.

The only way I can get my app to run without the bootloader is to put the CORTEX_VTOR_INIT back to 0 and my app to start at 0x08000000.

Is there something that I am missing in order to get this to work?
I have searched the forum and cant find anyone having this same issue, but I also havnt seen anyone confirm that their app is truly running the vector table from the offset location.

Thanks

Doddi
User avatar
Giovanni
Site Admin
Posts: 14893
Joined: Wed May 27, 2009 8:48 am
Has thanked: 1202 times
Been thanked: 997 times

Re: Bootloader vector table problem

Post by Giovanni »

Hi,

What ChibiOS version are you using? what device?

Giovanni
doddi
Posts: 10
Joined: Sun Dec 04, 2016 11:44 am

Re: Bootloader vector table problem

Post by doddi »

Hi,

It is ChibiOs 3 (I believe but it has been handed over from another developer). I have also tried it on a fresh download of 16.1.5 with the same symptom.

The device is stm32f103g

Thanks
User avatar
Giovanni
Site Admin
Posts: 14893
Joined: Wed May 27, 2009 8:48 am
Has thanked: 1202 times
Been thanked: 997 times

Re: Bootloader vector table problem

Post by Giovanni »

Is VTOR initialized by the bootloader or the application? Make sure of the VTOR content while the application is running.

Other possible sources of problems are ld files.

Giovanni
doddi
Posts: 10
Joined: Sun Dec 04, 2016 11:44 am

Re: Bootloader vector table problem

Post by doddi »

If VTOR initialisation you mean

Code: Select all

SCB->VTOR = CORTEX_VTOR_INIT

then this is being done by both the bootloader and application when they start ( I havnt actually checked the bootloader) but they are both initialising the ChibiOS. Bootloader CORTEX_VTOR_INIT is set to 0x00000000 and app is set to 0x0800C000.

I hadn't mentioned but my bootloader is also a ChibiOS image which I found a link to on the forums around here somewhere (bootloader for upgrading via SD card).
User avatar
Giovanni
Site Admin
Posts: 14893
Joined: Wed May 27, 2009 8:48 am
Has thanked: 1202 times
Been thanked: 997 times

Re: Bootloader vector table problem

Post by Giovanni »

Hi,

If you get into "unhandled exception" then the vectors table must be setup correctly, that symbol is only reached through the vectors table, the problem must be something else.

Please also verify the position of the vectors table in the .map file.

Note that in newer ChibiOS versions the VTOR register is no more initialized by the OS, it is now done by startup files.

Giovanni
doddi
Posts: 10
Joined: Sun Dec 04, 2016 11:44 am

Re: Bootloader vector table problem

Post by doddi »

Hi,

Sorry for the delay I have not been working on this for a few days.

I have debugged this a little further and I have made it as simple as possible. My main function is as folllows:

Code: Select all

int main(void) {
   halInit();
   chSysInit();

   chRegSetThreadName("Tick Timer");
   while(true) {
      chThdSleepMilliseconds(1000);
   }
}


The main loop gets to the chThdSleepMilliseconds(1000) which eventually sets the timer callback 'wakeup' (within ChibiOS) from then on the thread is switched to the idle_thread and it appears to be at this point when the first SysTick_Handler is called with the following calls:

CH_IRQ_PROOGUE() -> _dbg_check_enter_isr() -> port_lock_from_isr() -> port_lock() -> _set_BASEPRI(CORTEX_BASEPRI_KERNEL)

It is returning from these were it jumps to unhandled_exception

Again, if I put the CORTEX_VTOR_INIT back to 0x00000000 with flash base at 0x0800C000 then the same code works fine. If I then move the code to flash to be 0x0800C000 with CORTEX_VTOR_INIT at 0x0800C000 without erasing the flash (i.e. keep the 0x0000-0xC000 with the code remaining) then it will also work. It is only when I perform a mass erase then it stops working (unhandled exception). Surely this tells me it is still referencing something from 0x0000-0xC000 by mistake!?

Any further pointers would be really appreciated
What switches can I put in to clarify where my vector table is from the map file?

I also read back SCB->VTOR from main and it has indeed been initialised to 0x0800C000

I do have a little confusion about offset, should the CORTEX_VTOR_INIT be set to 0x0000C000 or 0x0800C000, I have assume the latter but the confusion is because by default ChibiOS sets it to 0x00000000.

Thanks.
doddi
Posts: 10
Joined: Sun Dec 04, 2016 11:44 am

Re: Bootloader vector table problem

Post by doddi »

Hi,

Further to the information above I have noticed that there is some kind of stack issue. See screenshots attached, first SysTick_Handler.jpg then as part of OSAL_IRQ_PROLOGUE there is _stats_increase_irq (attached) which the stack looks fine but then when _dbg_check_enter_isr (attached) is called you can see that the stack is now corrupted, i.e. no call back to SysTick_Handler in the stack

Thanks
Attachments
SysTick_Handler.jpg
stats_increase_irq.jpg
dbg_check_enter_isr.jpg
Tabulous
Posts: 518
Joined: Fri May 03, 2013 12:02 pm
Has thanked: 7 times
Been thanked: 18 times

Re: Bootloader vector table problem

Post by Tabulous »

Here is what i did

application
#define CORTEX_VTOR_INIT 0x8400
.ld file is set flash : org = 0x08008400, len = 128k

bootloader
all default

and to jump to the application where APP_START_ADDR = 0x8008400

Code: Select all

        /* reset interrupts default */
        chSysDisable();

        /* Clear pending interrupts */
        SCB->ICSR = (0x1U << 27);//ICSR_PENDSVCLR;

        /* Disable all interrupts */
        for( i=0; i<8; i++ )
        {
            NVIC->ICER[i] = NVIC->IABR[i];
        }

        appAddress = (uint32_t *)APP_START_ADDR;

        /* get jump address from application vector table */
        jumpAddress = (uint32_t *) appAddress[1];

        /* load this address into function pointer */
        Jump_To_Application = (pFunction)jumpAddress;

        /* set stack pointer vector table */
        __set_MSP((uint32_t) (appAddress[0]));

        /* run forest, run */
        Jump_To_Application();

doddi
Posts: 10
Joined: Sun Dec 04, 2016 11:44 am

Re: Bootloader vector table problem

Post by doddi »

Tabulous wrote:Here is what i did

application
#define CORTEX_VTOR_INIT 0x8400
.ld file is set flash : org = 0x08008400, len = 128k

bootloader
all default

and to jump to the application where APP_START_ADDR = 0x8008400

Code: Select all

        /* reset interrupts default */
        chSysDisable();

        /* Clear pending interrupts */
        SCB->ICSR = (0x1U << 27);//ICSR_PENDSVCLR;

        /* Disable all interrupts */
        for( i=0; i<8; i++ )
        {
            NVIC->ICER[i] = NVIC->IABR[i];
        }

        appAddress = (uint32_t *)APP_START_ADDR;

        /* get jump address from application vector table */
        jumpAddress = (uint32_t *) appAddress[1];

        /* load this address into function pointer */
        Jump_To_Application = (pFunction)jumpAddress;

        /* set stack pointer vector table */
        __set_MSP((uint32_t) (appAddress[0]));

        /* run forest, run */
        Jump_To_Application();




Hi Tabulous,

This is indeed what i have been doing too but without any luck.
I think I have been miss understanding what the application should be capable of. I thought I would also be able to run the application relocated but without the bootloader, i.e. mass erase flash and program only the application (relocated to 0xC000) this doesnt appear to be the case. So if I am to debug my application I will have to rebuild it running from 0x0000?

Perhaps originally I had an issue with my bootloader reflashing. I think maybe I need to go back to basics.

Thanks
Post Reply