STM32F303VCT - Code hangs on sysTick IRQ enable

[jlag]

STM32F303VCT

STM32CubeIDE 1.14.1

Simple program generation with IDE, main() while loop user code that toggles a GPIO.

System hangs during HAL_Init() for the sysTick vector in: 

void HAL_NVIC_EnableIRQ(IRQn_Type IRQn)
{
/* Check the parameters */
assert_param(IS_NVIC_DEVICE_IRQ(IRQn));

/* Enable interrupt */
NVIC_EnableIRQ(IRQn);
}

Break the debugger and we are at an invalid address: 0x1FFFEf06.

I am assuming there is something wrong with either the vector table location and/or the NVIC configuration, but the vector table at 0x08000000 and code/flash are identical to the code that runs on Discovery board.

Both are using SWD. Discovery board is loaded/debugged via ST_LINK USB, custom board is loaded/debugged via STLINK-V3MINIE, USB to SWD.

I have been through many threads regarding user vector table locations, offsets, etc but none have seemed to help. All looks good.

Is there something that the ST-LINK on the Discovery board is doing during load/boot that the V3MINI isn't that could be affecting interrupt configuration?

[waclawek.jan]

Connect BOOT0 pin to 0V.

JW

[TDK · Accepted solution]

Sounds like the vector table isn't set correctly.

Uncomment the line that defines USER_VECT_TAB_ADDRESS in system_*.c. Verify with SCB->VTOR value.

[jlag]

Thanks JW, it is grounded via 10K Ohms though.

[jlag]

@TDK, thank you for suggesting this. I had tried USER_VECT_TAB_ADDRESS yesterday and had no success. This was a previous issue where uwTick was not being incremented as the ISR for its update was never called (assuming related vector table/NVIC config issue). 
Since then, I am running a simple project, opposed to the full application I was running yesterday.

But alas, uncommenting USER_VECT_TAB_ADDRESS has allowed the simple application to run, VTOR is 0x0800 0000 and Tick increment is working as expected.

I will try the USER_VECT_TAB_ADDRESS once again in the full application on the custom board now, and verify it works there as well.

-JL 

[TDK]

What value is in SCB->VTOR?

When your code is "stuck", look at VECTACTIVE field within SCB->ICSR to determine which interrupt it's in. Likely it's in SysTick (VECTACTIVE=15) and likely it's in the wrong place due to a bad vector table.

You can view these values in the SFRs window during debugging.

Show screenshots if you can. It helps to see what you're looking at exactly. Sometimes simple things to fix can be lost in translation.

[jlag]

@TDK No longer stuck (in that place at least), as stated SCB->VTOR  is 0x0800 0000 and HAL_Init is completed along with timer isr's functioning.

Now comes an issue with custom board timeout waiting for RCC_FLAG_HSERDY in SystemClock_Config()->HAL_RCC_OscConfig().

Timer ticks are incrementing but RCC_FLAG_HSERDY never == RESET.

Will try increasing timeout as a start, but looks like something may be different for the RCC config on custom board vs dev board.

Looking at the osc HW setup now...

EDIT: This one is solved, EE has an XTAL on board, I switched to ceramic resonator on PF0/1 and all is well.

[waclawek.jan]

@TDK , how can the non-running case be explained here?

Under default circumstances, VTOR does not need to be changed from is default. Obviously, here, the System memory is mapped at address 0. If BOOT0 is grounded, and there are no option bits to boot into System memory, then how does this happen? Does Cube have some settings under which it changes the mapping, maybe unbeknownst to the user?

I'm asking as these questions come up quite often, although usually it's a Pattern6 or similar "empty FLASH boots" model, where the explanation is sort of easy, but here?

JW

[TDK]

@waclawek.jan On reset, VTOR=0 as you said. The application starts running (BOOT0 is low), but the application doesn't update VTOR by default due to some absolutely inane decision by someone on the CubeMX team. When SysTick is activated, it jumps to the offset in system memory rather than the one that should be specified in flash if VTOR was correctly set to 0x08000000.

The code starts running here, since the problem occurs only after enabling NVIC_EnableIRQ.

[waclawek.jan]

@TDK,

> The application starts running (BOOT0 is low),

Yes, but that also means, that User FLASH is mapped (aliased) at 0, so there's no need to change VTOR.

@jlag,

Can you please revert temporarily to the failing state, and then read out content of address 0x0000'0000 and compare it with content of address 0x1FFF'D800? Also, can you please read out and post content of SYSCFG_CFGR1 (because of its MEM_MODE field)?

Thanks,

JW