Page 1 of 1

STM32F405 bootloader issues

Posted: Fri Jan 17, 2020 9:33 pm
by nameofuser1
I have implemented custom bootloader using ChibiOS which jumps to another ChibiOS application. The problem is chibios becomes unstable after a jump.

Here is my main function in application:

Code: Select all

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

    while (true) {
        chThdSleepMilliseconds(500);                         
        //for (volatile size_t i=0; i<5000000; ++i) {}      // Uncomment this and comment previous line and everything works
        palTogglePad(GPIOC, GPIOC_LED1);
    }

    return 0;
}


What happens is that I got unhandled exception when calling chThdSleepMilliseconds. BTW there is hardfault handler defined and I am sure that it works.
Firmware update is performed over CAN bus. This is how I exit the bootloader:

Code: Select all

    canStop(&CAND1);

    chSysDisable();
    stStopAlarm();

    // Disable all NVIC interrupts
    for (size_t i=0; i<sizeof(NVIC->ICER) / sizeof(NVIC->ICER[0]); ++i) {
        NVIC->ICER[i] = 0xFFFFFFFF;
    }

    SCB->ICSR |= SCB_ICSR_PENDSVCLR_Msk;
    SCB->ICSR |= SCB_ICSR_PENDSTCLR_Msk;

    // Clear all NVIC pending interrupts
    for (size_t i=0; i< sizeof(NVIC->ICPR) / sizeof(NVIC->ICPR[0]); ++i) {
        NVIC->ICPR[i] = 0xFFFFFFFF;
    }

    // Clear all interrupt priorities
    for (size_t i=0; i<sizeof(NVIC->IP) / sizeof(NVIC->IP[0]); ++i) {
        NVIC->IP[i] = 0;
    }
   
    jump_to_firmware(APP_START_ADDRESS);


Jump to firmware method:

Code: Select all

inline
void __attribute__((noreturn)) jump_to_firmware(uint32_t address) {
    // Set new vector table
    SCB->VTOR = address;

    uint32_t *addr_ptr = (uint32_t *) address;

    // Set main stack pointer
    __set_MSP((uint32_t) addr_ptr[0]);

    // Jump to application
    typedef void (*func_ptr)(void);
    ((func_ptr) addr_ptr[1])();

    for(;;) {}
}


Linker script is defined as follows. One script which defines regions:

Code: Select all

MEMORY
{
    bootloader      : org = 0x08000000, len = 48K
    app             : org = 0x0800C000, len = 976K
    flash2          : org = 0x00000000, len = 0
    flash3          : org = 0x00000000, len = 0
    flash4          : org = 0x00000000, len = 0
    flash5          : org = 0x00000000, len = 0
    flash6          : org = 0x00000000, len = 0
    flash7          : org = 0x00000000, len = 0
    ram0            : org = 0x20000000, len = 128k      /* SRAM1 + SRAM2 */
    ram1            : org = 0x20000000, len = 112k      /* SRAM1 */
    ram2            : org = 0x2001C000, len = 16k       /* SRAM2 */
    ram3            : org = 0x00000000, len = 0
    ram4            : org = 0x10000000, len = 64k       /* CCM SRAM */
    ram5            : org = 0x40024000, len = 4k        /* BCKP SRAM */
    ram6            : org = 0x00000000, len = 0
    ram7            : org = 0x00000000, len = 0
}

And it is included by 2 other scripts which just define aliases required for ChibiOS linker to work.

Main and process stack sizes are both set to 2KB. Stack pointers are initialized correctly. Application has STM32_NO_INIT defined, since both targets shares same initialization code. All debugging checks are enabled.

Looking over registers values in debugger I could not find anything useful. Any thought?

Thanks!

Re: STM32F405 bootloader issues

Posted: Fri Jan 17, 2020 10:13 pm
by Giovanni
Hi,

Are you jumping into the application in thread mode? (as opposed to exception mode). Also verify that the application has the vectors table where expected and is pointed by VTOR. Also, do you set the MSP initial value yourself? it is done in HW on reset.

Giovanni

Re: STM32F405 bootloader issues

Posted: Fri Jan 17, 2020 10:29 pm
by nameofuser1
Giovanni wrote:Hi,

Are you jumping into the application in thread mode? (as opposed to exception mode). Also verify that the application has the vectors table where expected and is pointed by VTOR. Also, do you set the MSP initial value yourself? it is done in HW on reset.

Giovanni


Yes, jump is performed from a thread mode i.e. chibios task.

Vector table is there. I can see the right MSP value at the application address.

MSP is set manually only before jump from bootloader to application. This may be unnecessary since they are the same in bootloader and app. But just to make it clear that MSP is correctly initialized to the required by application value)

Also it is worth to notice that the same code (almost the same, when I tested it there were no manual nvic interrupts disabling, I have added them later because of the problems with f4) worked fine on stm32l051.

Re: STM32F405 bootloader issues

Posted: Fri Jan 17, 2020 11:17 pm
by nameofuser1
IPSR Register states that executed interrupt number is 66. Which according to this page
https://developer.arm.com/docs/dui0553/latest/the-cortex-m4-processor/programmers-model/core-registers#BABGBIBI
have irq position 50, which in case of stm32f405 is timer 5 interrupt, which is used as system timer. Maybe it is a linker issue but I can not see the way. Will check it.

Re: STM32F405 bootloader issues

Posted: Sat Jan 18, 2020 6:55 am
by Giovanni
Hi,

Try stopping that timer before jumping to the application.

Giovanni

Re: STM32F405 bootloader issues

Posted: Sat Jan 18, 2020 1:18 pm
by nameofuser1
Giovanni wrote:Hi,

Try stopping that timer before jumping to the application.

Giovanni


Nah, it does not help. Moreover I have revealed that any interrupt causes application to go to unhandled exception. Which is quite strange and quite possible that the issue has nothing to do with Chibi. However...

First 256 bytes of app region are reserved for application header therefore application actual start address is 0x0800C100.
Here is what I analyzed and I can not see any problems.
Image

Seems like I am missing something obvious but I don't know what.

Re: STM32F405 bootloader issues

Posted: Sun Jan 19, 2020 11:36 am
by nameofuser1
The problem was vector table alignment! Also I found it necessary to set STM32_NO_INIT otherwise crash when reinitialise clocks.

Thanks!

Re: STM32F405 bootloader issues

Posted: Mon Mar 09, 2020 2:05 pm
by kalpesh
nameofuser1 wrote:The problem was vector table alignment! Also I found it necessary to set STM32_NO_INIT otherwise crash when reinitialise clocks.

Thanks!


Hi,

I wanted to relocate my chibios to sector 5(0x08020000).

How are you setting the vector table offset. I am using STM32F407 controller.

I am able to figure out the flash address in .ld file

Thanks

Re: STM32F405 bootloader issues

Posted: Wed Mar 11, 2020 9:55 am
by MGeo
Hi nameofuser1,

I am also struggling my way through a CAN bootloader problem for F4 that I believe is vector table related. Would you be willing to share a working example code?

Best Regards,
George