Break at address "0x429a683a" with stm32f469zi

[GMart.5]

Hi I'm trying to program a custom board with an stm32f469zi. Whenever I try to enter HAL_Init() at the very beginning of the code, I keep getting this error while trying to go through debugging:

Break at address "0x429a683a" with no debug information available, or outside of program code.

I set some breakpoints and traced it back to HAL_MspInit() where it contains this line of code:

HAL_NVIC_SetPriority(PendSV_IRQn, 15, 0);

I followed that even further (because the rest of the code works fine, I was following the trail of breaks) to NVIC_EncodePriority () under core_cm4.h. This function has a parameter called SubPriority where SubPriorityBits gets added onto it. It's precisely the line where SubPriorityBits gets all its bits but I'm not sure what this all means.

Is my project collapsing when it is trying to set up one of the interrupts? I have three global interrupts enabled in cubeMX: LTDC, DMA2D, and DSI.

[Tesla DeLorean]

So suggests the vector table is corrupt, or you're junking up the stack.

Make sure SCB->VTOR points to the correct memory address, and that it's 512-byte aligned.

[GMart.5]

I read through the mcu programming manual and found what the address offset is supposed to be (0x08). However, when looking through the code it says the offset must be multiple of 0x200. Would this pose a problem or does it work out?

[GMart.5]

After making this change, the error is the same but the code is different. I'm getting:

"Break at address "0x689b4b0a" with no debug information available, or outside of program code." Is this related to the same problem stated before?

[GMart.5]

All of my files are in C with the exception of some touchGFX files that are in .cpp but those should not be used when debugging this.

I noticed there was an #if defined(USER_VECT_TAB_ADDRESS) so which caused those defines for the flash memory and offset to never happen. I changed it to say #define USER_VECT_TAB_ADDRESS and now can see that SCB->VTOR gets a value of 0x8000000 (this is the same as 0x08000000, correct) but without the offset. Again, I get the same error but with code "Break at address '0x30ff002'... "

How would I check for the missing IRQ handlers and/or uninitialized structures?

[Tesla DeLorean]

ST's use of defines is frustrating and unnecessary.

At the end of SystemInit(), or wherever it is now, explicitly set SCB->VTOR to the vector table address..

SCB->VTOR = 0x08000000;

or

SCB->VTOR = &__Vectors;

>>How would I check for the missing IRQ handlers and/or uninitialized structures?

I'd use static analysis techniques and a debugger.

You'd need to make sure your stack and heap allocations are sufficient to support the code you've created.

Use bisection methods to focus on what is and is not causing failure. Reduce the code and inspect the system state in the failure case.

Use HardFault Handlers that output actionable information to determine the code that faults.

[GMart.5]

I've spent some time debugging and my break points are leading me towards the RCC. It keeps breaking at the end of HAL_RCC_ClockConfig during the while loop.

It doesn't make it to the return statement and just gives me the break error.

while (__HAL_RCC_GET_SYSCLK_SOURCE() != (RCC_ClkInitStruct->SYSCLKSource << RCC_CFGR_SWS_Pos))
 {
 if ((HAL_GetTick() - tickstart) > CLOCKSWITCH_TIMEOUT_VALUE)
 {
 return HAL_TIMEOUT;
 }
 }

GET_SYSCLK_SOURCE is equal to 8, and SYSCLKSource is equal to 2 and RCC_CFGR_SWS_Pos is equal to 2 so I would assume when it shifts over, they would eventually be equal and fall out of the loop. RCC_ClkInitStruct gets its intial values in main() before it gets passed to HAL_RCC_ClockConfig so I thought it would be initialized but perhaps not in practice. I allocated more space for heap to make sure there was enough room. I can see that my timer interrupt handler gets called often but always breaks on this. I see that there is an NMI_IRQHandler, but adding that in seem to make it worse. Does RCC use an IRQHandler?

Thanks for your help!

[Tesla DeLorean]

HAL_GetTick() would be reliant on the SysTick, or other source, clocking and incrementing the system's 1KHz / 1 ms ticker.

Custom board?

Are you sure the HSE clock source is functional? At a speed reflected by the HSE_VALUE define?

Capacitors on VCAP pins? Voltage observed?

Would suggest bringing up the system minimally, with a UART configured so you can output telemetry, progress and flow information.

[mattias norlander]

Maybe you can launch a debug session and use the Memory view to examine the isr_vector content by adding a monitor at 0x8000000. Does it seem correct? Use the Hex Integer rendering to get the right byte order.

Also in the SFR-view check that the node Cortex-M4 > VTOR points to 0x0 for Flash located ISR vector.