STM32F7, custom bootloader loads firmware but firmware fails on call to HAL_TIM_Base_Start.

[Cvign.1]

Hello,

I'm working with a STM32F7 MCU, Using Keil uVision.

I'm developing a cutom bootloader and I have to shift another firmware in memory for it to launch.

Firmware developed by another team that uses interrupts.

I successfully launched simple led toggling programs to verify that the bootloader works fine.

The firmware I'm having an issue gives me the following behavior:

I have my target with the bootloader already in place.

I start the debugger with the firmware write shifted to the correct position. The debugger launches, executes the bootloader and jumps to the firmware.

The first call in the main function is HAL_Init() which then calls HAL_InitTick().

At the end of the HAL_InitTick() [stm32f7xx_hal_timebase_TIM.c] there is a call to HAL_TIME_Base_Start() that if I step other makes the program crash.

The debugger that should have stopped for the step keeps running.

After I stop it the ProgramCounter points back to bootloader address zone.

I'm at a loss for what to look for.

[waclawek.jan]

Tried to step *into* the offending routine, or *over* it? Try also stepping in disasm to find the exact instruction causing the problem.

VTOR is properly set for the new ISR table?

Stack pointer points into a valid memory area?

JW

[Cvign.1]

I really meant 'step other' the function.

if I 'step into' the function and only repeat that action, the debugger can go quit far in the execution.

But whenever I do 'step other' the debugger doesn't stop and get in the same situation.

I tired to pinpoint until when the 'step other' stopped working.

The PC and SP values are correct and in separate zones when running bootloader or application.

The VTOR is set at the end of bootloader :

#if(SET_VECTOR_TABLE)
 SCB->VTOR = Address_for_firmware_zone;
#endif

And Jump made from the @(Address_for_firmware_zone + 4).

[Cvign.1]

My god I wrote 'other' instead of 'over' 4 times in one day. :astonished_face: :grinning_face_with_sweat:

Really need my week-end. :face_savoring_food:

[TDK]

You can look at the code in HAL_TIM_Base_Start. Nothing in there should be crashing your code if your parameters are valid. Perhaps you're passing a null or invalid pointer.

Did you update the vector table when you jump to the program code? It could be calling a now-invalid interrupt, possibly the timer update interrupt.

You could look at VECTACTIVE to see if it's in an ISR.

[Cvign.1]

I checked the values and they were correct. VTOR set as above reply.

I'll try to check that VECTACTIVE you're talking about.

[Cvign.1]

@Community member​ and @TDK​ thank you for both pointing out the VTOR.

I worked on it, checked it, thought I had it handled but you guys pointing that out got me wondering.

I was assuming that only setting it the bootloader was enough. I checked the launched code and discovered the [system_stm32f7xx.c] System_init() set the SCB->VTOR.

Setting the new value to VECT_TAB_OFFSET was the missing piece.

[waclawek.jan]

> if I 'step into' the function and only repeat that action, the debugger can go quit far in the execution.

Oh indeed, single-stepping covers up issues related to interrupts, as interrupts are internally disabled by the debugger for singlestepping (otherwise you'd be annoyed by stepping into the ISRs all the time). "Stepping over" with a function call usually works so that the debugger places a breakpoint after the function call and then lets the processor run.

Sorry for misleading.

> discovered the [system_stm32f7xx.c] System_init() set the SCB->VTOR.

Corollary is, that by including any "library" code you assume responsibility for it, exactly as if you'd write it yourself.

Maybe it's better to write it yourself, then... :)

JW

[Cvign.1]

That first part gives me a good understanding of what was happening with 'step over' and 'step into'. I had an intuitive understanding but that helps.

I'll be more aware of that.

Concerning the responsibility of knowing the tools you use, you are right.

The firmware was developed by another team. Not checking their initialization was my error.

Thanks for the good discussion.