Skip to main content
Visitor II
February 19, 2020
Solved

STM32G431KB; Fatal problem with USB initialization function

  • February 19, 2020
  • 7 replies
  • 4091 views

FreeRTOS is currently active. However, the problem occurs before FreeRTOS initialization (before calling osKernelInitialize ()).

The board used is a board written by hand rather than a NUCLEO board. When I activate my Peripheral devices other than USB-PD and run the FreeRTOS application, I confirm that it works correctly.

The point where the problem occurs is inside the USB_DisableGlobalInt function. In the process of masking the interrupt mask to USBx-> CNTR, all interrupts are immediately interrupted (including the SWD of ST-LINK) and the chip is reset after a certain time.

Here is the call stack at the time of occurrence:

[0] from 0x08004b88 in USB_DisableGlobalInt+0 at Drivers/STM32G4xx_HAL_Driver/Src/stm32g4xx_ll_usb.c:117

[1] from 0x08004aa0 in HAL_PCD_Init+28 at Drivers/STM32G4xx_HAL_Driver/Src/stm32g4xx_hal_pcd.c:169

[2] from 0x08000908 in MX_USB_PCD_Init+32 at Src/main.c:483

[3] from 0x080009b2 in main+34 at Src/main.c:122

The code for each call stack is as follows:

[0]

 106 HAL_StatusTypeDef USB_DisableGlobalInt(USB_TypeDef *USBx)
 107 {
 108 uint16_t winterruptmask;
 109
 110 /* Set winterruptmask variable */
 111 winterruptmask = USB_CNTR_CTRM | USB_CNTR_WKUPM |
 112 USB_CNTR_SUSPM | USB_CNTR_ERRM |
 113 USB_CNTR_SOFM | USB_CNTR_ESOFM |
 114 USB_CNTR_RESETM | USB_CNTR_L1REQM;
 115
 116 /* Clear interrupt mask */
 117 USBx->CNTR &= ~winterruptmask; // << Stucks at this point
 118
 119 return HAL_OK;
 120 }

[1]

 154 {
 155 hpcd->MspInitCallback = HAL_PCD_MspInit;
 156 }
 157
 158 /* Init the low level hardware */
 159 hpcd->MspInitCallback(hpcd);
 160 #else
 161 /* Init the low level hardware : GPIO, CLOCK, NVIC... */
 162 HAL_PCD_MspInit(hpcd);
 163 #endif /* (USE_HAL_PCD_REGISTER_CALLBACKS) */
 164 }
 165
 166 hpcd->State = HAL_PCD_STATE_BUSY;
 167
 168 /* Disable the Interrupts */
 169 __HAL_PCD_DISABLE(hpcd); // <<< Stucks At This Point
 170
 171 /* Init endpoints structures */
 172 for (i = 0U; i < hpcd->Init.dev_endpoints; i++)
 173 {

[2]

 475 hpcd_USB_FS.Instance = USB;
 476 hpcd_USB_FS.Init.dev_endpoints = 8;
 477 hpcd_USB_FS.Init.speed = PCD_SPEED_FULL;
 478 hpcd_USB_FS.Init.phy_itface = PCD_PHY_EMBEDDED;
 479 hpcd_USB_FS.Init.Sof_enable = DISABLE;
 480 hpcd_USB_FS.Init.low_power_enable = DISABLE;
 481 hpcd_USB_FS.Init.lpm_enable = DISABLE;
 482 hpcd_USB_FS.Init.battery_charging_enable = DISABLE;
 483 if (HAL_PCD_Init(&hpcd_USB_FS) != HAL_OK) // << Stucks at this point
 484 {

I don't know if this is a known issue, but I couldn't find it when I tried searching on Google.

Please let me know if there is any additional information you need to solve the problem, such as board configuration or CubeMX settings.

Thanks.​

    This topic has been closed for replies.
    Best answer by waclawek.jan

    > The error was resolved when I switched clock source to HSI ...

    So it was missing clock to USB?

    But, you've said above,

    > It is set to use HSI48,.

    So how is it?

    For crystal capacitors see AN2867, but generally 22pF for 24MHz should be in most of the cases OK and the oscillator should work, even if not optimally. Check HSE oscillations by outputting it to MCO and measuring there.

    JW

    7 replies

    Super User
    February 19, 2020

    Check, whethr USB clock is enabled in RCC.

    JW

    SKang.2Author
    Visitor II
    February 19, 2020

    I've checked clock configuration. It is set to use HSI48, instead of PLLQ, since PLLQ is can't be set to 48MHz by adjusting PLL parameters, when the SysClk is set to 170MHz. Should I use PLLQ, despite of reducing SysClk speed as multiplicand of 48MHz?

    Super User
    February 19, 2020

    I guess, any clock source is OK for the initial setup - the USB data transmittion may not work properly with an incorrect frequency source, but reset etc. should work.

    My question was more that check whether RCC_APB1ENR1.USBEN is set.

    JW

    SKang.2Author
    Visitor II
    February 19, 2020

    Yes, when I evaluate below expression, it returns 1.

    (RCC->APB1ENR1 & RCC_APB1ENR1_USBEN) != 0

    Super User
    February 19, 2020

    Single-step in disasm. Show line where the "freeze" occurs, together with context (previous lines, content of registers).

    JW

    SKang.2Author
    Visitor II
    February 19, 2020

    I'm using gdb-dashboard, you'll may recognize statement easily with images.

    Program runs properly before branch into the function USB_DisableGlobalInt()

    Right after jump into this function, it seems working properly.

    Yet if I step one instruction on this statement, connection immediately shutdown and freezes.

    SKang.2Author
    Visitor II
    February 19, 2020

    Sorry for giving vague description for my situation ...

    Can you check whether my external crystal circuits correctly composited?

    The error was resolved when I switched clock source to HSI ...

    Should I reduce C2 and C3 on here?

    In this case, Pin 2 and 4 of crystal is just shield pin ... don't care it.

    0690X00000DBujfQAD.png

    Super User
    February 19, 2020

    > The error was resolved when I switched clock source to HSI ...

    So it was missing clock to USB?

    But, you've said above,

    > It is set to use HSI48,.

    So how is it?

    For crystal capacitors see AN2867, but generally 22pF for 24MHz should be in most of the cases OK and the oscillator should work, even if not optimally. Check HSE oscillations by outputting it to MCO and measuring there.

    JW

    SKang.2Author
    Visitor II
    February 19, 2020

    For your question; I'm not sure what the exact cause was. When I changed the clock source for the entire system to HSI from the HSE clock, the program run without any error. 

    At least, it wasn't because of the missing clock to USB. The clock source for the USB peripheral has always been HSI48 without change ... 

    At this point, guessing that the crystal circuit has some trouble seems reasonable.

    To ensure this, I should measure the exact clock speed of HSE... as you mentioned. 

    I'll check it, thanks.

    Visitor II
    August 13, 2020

    Hi!

    I'm actually facing a similar issue, also in USB_DisableGlobalInt and with G431KB.

    The MCU is operating as normal for other peripherals, e.g. I can run a simple blinky program and it works fine.

    But when i enable the USB functionality, the MCU ends up with a fatal crash in USB_DisableGlobalInt.

    I've traced this down to accessing the USB_FS_DEVICE registers, for example CNTR. Reading this register causes a fatal crash. (screenshot)

    I've verified that RCC->APB1ENR1->USBDEN is set. (screenshot).

    I'm using HSI (screenshot of RCC->CR). (screenshot)

    Note: The regnames don't exactly match the STM RM0440 PDF manual, but the bit numbers is listed on the right for refence.

    I've tried a number of options, and really am quite stuck now :(

    Hoping someone here might have the same issue or some hint on how to resolve it.

    @SKang.2​ : Did you ever figure out the true cause of your issue?

    @WPete.2​ : You had some good comments on SKang's issue - any insights as to what I might be facing?

    Detailed screenshots below...

    Crashing Source Code Segment:

    0693W000003PHbzQAG.png

    Disassembly

    0693W000003PHYXQA4.png

    CPU Registers before crash0693W000003PHcJQAW.png

    Fatal Crash (after executing ldhr.w instruction (i.e. reading USB_CNTR@0x40005c40)

    I also get a crash if I use the debugger to read that memory space.

    0693W000003PHcnQAG.png

    APB1ENR1 (I.e. USB clock enabled)0693W000003PHetQAG.png

    APB1ENR2 (i.e. USB-C power functinality disabled)0693W000003PHf3QAG.png

    RCC->CR (i.e. HSI mode selected)0693W000003PHfIQAW.png

    RCC->PLLCFGR (i.e. HSI Mode and clock configuration)0693W000003PHfNQAW.png

    Super User
    August 13, 2020

    Next time, please start your own thread, with links to relevant threads.

    How is the 48MHz clock (USB, RNG) selected? See RCC_CCIPR.CLK48SEL. If you did not touch it, it's set to HSI48.

    HSI48 is enabled? See RCC_CRRCR.

    JW

    Visitor II
    August 13, 2020

    Hi!

    Ah, hah! Yeah, that was it. RCC_CRRCR.HSI48 was not enabled, so the USB was not getting a proper clock. Flipped the bit and then it went just fine!

    Thanks!!