STM32F405 bootloader issues

Discussions and support about ChibiOS/RT, the free embedded RTOS.
nameofuser1
Posts: 7
Joined: Thu Oct 10, 2019 10:08 am
Been thanked: 2 times

STM32F405 bootloader issues

Postby nameofuser1 » Fri Jan 17, 2020 9:33 pm

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!

User avatar
Giovanni
Site Admin
Posts: 14444
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 1074 times
Been thanked: 921 times
Contact:

Re: STM32F405 bootloader issues

Postby Giovanni » Fri Jan 17, 2020 10:13 pm

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

nameofuser1
Posts: 7
Joined: Thu Oct 10, 2019 10:08 am
Been thanked: 2 times

Re: STM32F405 bootloader issues

Postby nameofuser1 » Fri Jan 17, 2020 10:29 pm

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.

nameofuser1
Posts: 7
Joined: Thu Oct 10, 2019 10:08 am
Been thanked: 2 times

Re: STM32F405 bootloader issues

Postby nameofuser1 » Fri Jan 17, 2020 11:17 pm

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.

User avatar
Giovanni
Site Admin
Posts: 14444
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 1074 times
Been thanked: 921 times
Contact:

Re: STM32F405 bootloader issues

Postby Giovanni » Sat Jan 18, 2020 6:55 am

Hi,

Try stopping that timer before jumping to the application.

Giovanni

nameofuser1
Posts: 7
Joined: Thu Oct 10, 2019 10:08 am
Been thanked: 2 times

Re: STM32F405 bootloader issues

Postby nameofuser1 » Sat Jan 18, 2020 1:18 pm

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.

nameofuser1
Posts: 7
Joined: Thu Oct 10, 2019 10:08 am
Been thanked: 2 times

Re: STM32F405 bootloader issues

Postby nameofuser1 » Sun Jan 19, 2020 11:36 am

The problem was vector table alignment! Also I found it necessary to set STM32_NO_INIT otherwise crash when reinitialise clocks.

Thanks!

kalpesh
Posts: 19
Joined: Mon Dec 09, 2019 11:53 am

Re: STM32F405 bootloader issues

Postby kalpesh » Mon Mar 09, 2020 2:05 pm

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

MGeo
Posts: 22
Joined: Wed Jul 26, 2017 12:05 pm
Been thanked: 4 times

Re: STM32F405 bootloader issues

Postby MGeo » Wed Mar 11, 2020 9:55 am

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


Return to “ChibiOS/RT”

Who is online

Users browsing this forum: No registered users and 10 guests