cancel
Showing results for 
Search instead for 
Did you mean: 

STM32H743 USB CDC HardFault

Jerry_Hu
Visitor

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. 

Jerry_Hu_1-1761243064154.png

 

 

 

 

 

 

 

 

 

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

Jerry_Hu_0-1761242223741.png

 

Thanks in advance.

2 REPLIES 2
AScha.3
Super User

Hi,

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

see my setting, just as example:

AScha3_0-1761245525881.png

AScha3_1-1761245569181.png

>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:

AScha3_2-1761245732518.png

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

AScha3_3-1761245807020.png

+

btw

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

AScha3_4-1761245931527.png

 

If you feel a post has answered your question, please click "Accept as Solution".
TDK
Super User

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.

If you feel a post has answered your question, please click "Accept as Solution".