SIGTRAP when reducing HCLK

[avidroneg]

I'm in the middle of attempting to reconfigure the clock tree on my STM32F303K8. The old clock tree looks like

The new clock tree looks like

 

The old clock tree works fine. The new clock tree always fails on boot; not always in the same address but always in the neighbourhood of HAL_RCC_ClockConfig. An example stack trace looks like

In this case it claims to have failed on this line 769 of HAL_RCC_ClockConfig:

 /* Get Start Tick */
 tickstart = HAL_GetTick();

This is failing in the MX-generated code well before any of my own code runs. The goal is to keep the CPU clock at 64 MHz but reduce everything after the AHB prescaler. The diff of the RCC section in the .ioc file looks like this:

 

 

 

 

 

[TDK]

It looks like the vector table offset isn't set correctly.

Ensure USER_VECT_TAB_ADDRESS is #defined in the HAL configuration file, or that SCB->VTOR is otherwise being set correctly.

You could set __disable_irq() at the start of main() and see if it finishes, which would verify the above.

[avidroneg]

I will try that, but... why would only changing the clock tree corrupt the vector table offset? That's quite strange.

[TDK]

Okay so probably not that.

Not real sure, but what I would do is look at the RCC clock settings at the register level after or as they are set by HAL_RCC_ClockConfig and validate those against what is allowed per the reference manual. Perhaps look just prior to the system clock being changed at __HAL_RCC_SYSCLK_CONFIG.

Consider looking into the reason for the hard fault. STM32CubeIDE has a hard fault analyzer. Window -> Show View -> Fault Analyzer. Probably going to see an IMPRECISE_ERR which is hard to pin down but is usually something fundamentally wrong with the clock settings. Occasionally due to a power issue but if you're reducing the clock I doubt that's the case here.

[avidroneg]

The only other suspicious thing I saw was that MX modified this parameter:

FLASH_LATENCY_2

to

FLASH_LATENCY_0

 

[avidroneg]

Right, so manually reverting FLASH_LATENCY_0 to FLASH_LATENCY_2 fixes the issue. Searching the internet for this symbol didn't turn up much. I wonder what's going on here. FLASH_LATENCY_1 also succeeds.

MX even has a field for this, but it's disabled:

 

[TDK]

The reference manual would be the correct place to look for that info.

HCLK of 4 MHz doesn't require wait states.

 

> The goal is to keep the CPU clock at 64 MHz but reduce everything after the AHB prescaler.

Not entirely sure where the cortex clock is here.

 

RM says that HCLK is the Cortex clock which aligns with the RMs specifications on wait states.

 

Changing wait states to 2 suggests this may be incorrect, but the RM is typically the best source of info.

[avidroneg]

---

@TDK wrote:

> The goal is to keep the CPU clock at 64 MHz but reduce everything after the AHB prescaler.

Not entirely sure where the cortex clock is here.

RM says that HCLK is the Cortex clock which aligns with the RMs specifications on wait states.

Sigh. Yep. Back to 64 MHz, then...