Skip to main content
T
tstokes
Explorer II
December 6, 2024
Question

STM32H755 interrupt issue after secure boot (SBSFU)

  • December 6, 2024
  • 1 reply
  • 677 views

I have a firmware running on an STM32H755. All working fine until I added a secure bootloader to the firmware and now the firmware crashes when initialising TIM3.

My setup: 

STM32H755 on custom board

SBSFU (1_Image)

Cubeprogrammer and CubeIDE.


I've pinpointed the exact line that the firmware crashes on to be:

__HAL_TIM_ENABLE_IT(&htim3, TIM_IT_UPDATE); 
 
Things I've tried: 
  • Moving the call to MX_TIM3_Init to different points in the function. Still fails at that point.
  • Commenting out the offending line. Firmware runs past this point but I need the timer. 
  • Calling the initialise function as part of the UserApp that comes with SBSFU on a Nucleo board. This works.
  • Disabling the interrupt first. 
  • Hardcoding the address of the TIM3 DIER register
  • Checked Timer is not setup by SBSFU 

 

Might be Friday brain, but I'm really not seeing how this is connected to me having moved the firmware up a flashbank to make room for SBSFU.

Any thoughts greatly appreciated

Edit 1:

This appears to be interrupt related. I have put an __disable_irq() around the MX_INIT_** block in my main function and can now progress through this. However, the code then fallsover when using DMA.

0x800ae08
<signal handler called>() at 0xffffffe9
Init_DMA2_Transfer_FixedLocation_To_Fixed_Dest() at CW2_DMA.c:208 0x2400040e
seFillMemory16() at CW2_13748_API_hcl_parallel16.h:744 0x8082cba

There's nothing to go in the status registers.

I've check SP, LR and PC. 
sp 0x2401ff48
lr 0x8087c05 (Hex)
pc 0x2400040e <Init_DMA2_Transfer_FixedLocation_To_Fixed_Dest+42>

Any tips on debugging the route to the top two items on my stack would probably be a big help in getting to the bottom of this.






 
    This topic has been closed for replies.

    1 reply

    T
    tstokesAuthor
    Explorer II
    December 10, 2024

    Turns out that the 0x800ae08 address is in the bootloader's vector table. While the user application firmware knows where it's vector is the hardware doesn't. 

    A solution is to update the beginning of main to: 

    /* Private user code ---------------------------------------------------------*/
/* USER CODE BEGIN 0 */
extern const uint32_t g_pfnVectors[];

/* USER CODE END 0 */

/**
 * @brief The application entry point.
 * @retval int
 */
int main(void)
{
 /* USER CODE BEGIN 1 */
 SCB->VTOR = (uint32_t)g_pfnVectors; // Set the vector table base address
 /* USER CODE END 1 */

 // Rest of program...

}


    However, it seems like this is something that secure boot should be doing when loading the application so I need to dig around on that side. 

    Terms & ConditionsAccessibility statement