Issue with interrupt in custom bootloader on STM32F070CBT6
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-11-16 2:11 AM - edited ‎2024-11-16 2:12 AM
Dear STM32 Community,
I am encountering an issue with a custom bootloader implementation on the STM32F070CBT6 microcontroller. The same bootloader and application setup work flawlessly on the STM32F072RBT6, but when applied to the STM32F070CBT6, the application appears to get stuck, and interrupts do not function as expected.
- Both MCUs (STM32F072RBT6 and STM32F070CBT6) are Cortex-M0 series.
- Bootloader starts at Flash base (0x08000000) and jumps to the application located at 0x08004000.
- Bootloader to Application Jump Function:
static void goto_application(void) {
void (*app_reset_handler)(void) = (void (*)(void))(*(volatile uint32_t *)(0x08004000 + 4));
__disable_irq();
HAL_RCC_DeInit();
HAL_DeInit();
SysTick->CTRL = 0;
SysTick->LOAD = 0;
SysTick->VAL = 0;
__set_MSP((*(volatile uint32_t *)0x08004000));
app_reset_handler();
}
​
Application Code Setup (STM32F072RBT6): The following setup works perfectly in the application.
__enable_irq();
for (i = 0; i < 48; i++) {
VectorTable[i] = *(uint32_t*)(0x08004000 + (i << 2));
}
__HAL_RCC_SYSCFG_CLK_ENABLE();
__HAL_SYSCFG_REMAPMEMORY_SRAM();
​
Using the same bootloader and application setup, the STM32F070CBT6 application does not work as expected. It seems to get stuck, and interrupts do not function.
Are there any specific differences in handling interrupts, vector table remapping, or peripheral initialization between the STM32F072RBT6 and STM32F070CBT6 that could cause this behavior?
Could there be additional steps required for the STM32F070CBT6 to support bootloader-to-application jumps with interrupt functionality?
Any guidance or suggestions to resolve this issue would be greatly appreciated.
Thank you in advance for your support!
- Labels:
-
STM32F0 Series
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-11-16 2:44 AM
You kip show how you place
VectorTable[i]
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-11-17 7:40 PM
uint32_t* VectorTable = (uint32_t*)0x20000000;
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-11-17 9:11 PM
This isnt place or reservation space. Your RAM in linker require move start or other reserve methods...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-11-17 9:20 PM - edited ‎2024-11-17 9:20 PM
@MM..1 thanks but its worked in stm32f072rbt6 MCU , problem was its not working in stm32f070cbt6.
can you explain me why ?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-11-18 3:04 AM
KEIL IDE ??? Somebody setup project for RB right. Normal new projects isnt ready for bootloader use.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2024-11-18 4:11 AM
Check/compare the linker settings in both projects. Check for memory address ranges - Flash and RAM set for bootloader and the application. 192 bytes of RAM at 0x20000000 should be excluded from use or explicitly reserved for vector table as a separate RAM section.
Also, check the assembly code generated for jump to application. It should not use sp register. If sp is used, change the optimization level to O2.
