STM32H743 USB CDC HardFault

[Jerry_Hu]

Hi ST Community, 

 

Our project uses STM32H743 (LQFP100). The system clock is set at the max 480MHz.

The USB Device interrupts would occasionally cause a HardFault. For example, if we plug in or unplug the USB.

The data hpcd would occasionally be 0xFFFFFFFF. Sometimes it's the hpcd->pClass[0]

We have enough size for the stack and heap.

A "workaround" is to lower the system clock to 240MHz...

 

What we don't understand is that the USB clock source is from the "RC48" 48MHz clock, independent from the system clock, which sources the HSE. How does lowering the system clock help resolve this issue? We also tried using HSE to generate the 48MHz for the USB, but the USB just doesn't run.

Is there other settings or configurations that we might have set incorrectly?

 

Another thing to mention is that we have a conflict with the RCC CRS SYNC. 

 

 

 

 

 

 

 

 

 

Attached is our clock configuration and .ioc file for your reference.

 

Thanks in advance.

[AScha.3]

Hi,

at first use the HSE->PLL for the USB clock : 48.0 MHz

see my setting, just as example:

>We also tried using HSE to generate the 48MHz for the USB, but the USB just doesn't run.

Cannot be - if you set the values correct/real : HSE clock; 

here set your real frequency:

+ check internal clock at MCO 1 or 2, with scope, should be, what you set:

+

btw

whats strange: your flash wait states at 0 , impossible at xxx MHz core clock, see mine at 200MHz:

 

[TDK]

If data hpcd is getting overwritten, set a hardware watchpoint on it to see when and where it occurs. Probably an out of bounds write.

Changing the clock rate is likely not the problem here. There are many explanations for why changing clock can change program behavior, but they're not relevant. Address the problem directly.

RC48 is fine as a clock source for USB device as the peripheral will do clock recovery to ensure a steady clock. Also likely not the problem.

[Jerry_Hu]

Hi all, 

 

Thank you all for your inputs. 

For more information, we got it to work with SYSCLK=400MHz and "VBUS Sensing Disabled", but still didn't get the same setup to work when SYSCLK=480MHz...

 

I agree with TDK that the SYSCLK is not likely to be the problem. At this point, we are not sure why the SYSCLK matters in our case but changing this single variable does affect the outcome.

 

Any suggestions are welcome. Thanks.

[Gyessine]

hello @Jerry_Hu 
I reviewed your IOC file and noticed that the input frequency is set to 48 MHz. Could you confirm whether the HSE clock you are using in your hardware is indeed providing a clean 48 MHz signal?
BR
Gyessine

[Jerry_Hu]

Hi all,

 

We’ve determined that the hard fault caused by hpcd->pClass[0] being 0xFFFFFFFF was due to a memory configuration issue, not related to the clock speed. Specifically, the minimum heap and stack sizes were set larger than the available ITCM-RAM (128 KB).

 

After reducing the minimum heap and stack sizes and moving the USB handlers to DTCM-RAM, the project now runs without issues at SYSCLK = 480 MHz.

 

Thank you all for your support!