Skip to main content
KMuel
KMuel
Associate
February 17, 2021
Question

USB Device does not work when starting BLE stack on STM32WB55

  • February 17, 2021
  • 4 replies
  • 4082 views

I want to use USB_Device with CDC class and BLE together. USB_Device is used as virtual COM port. The BLE stack is initialized as server.

Without initializing the BLE-Stack, USB device runs as expected. I can connect with a terminal, running on PC, with the serial port.

The BLE stack is running anyway, I can connect with STM32 Sensor App. But at the moment the BLE stack is initialized, the USB_Device stops working. A connection via terminal is not possible anymore.

Debugging the problem shows, that no USB interrupts are generated anymore. The problem seems to occure, when the sequencer runs the task with ID CFG_TASK_SYSTEM_HCI_ASYNCH_EVT_ID (BLE stack initialisation). This tasks is called each time the shci_notify_asynch_evt notification is received. By the way, heap is set to 0x2000 and stack to 0x800.

I have generated the code with STM32CubeIDE Version: 1.5.1, using STM32Cube FW_WB V1.10.1. Additionally, I have followed and changed code according to Chapter 3 of STM presentation "How to add BLE functionality easily using STM32CubeMX". I am working on Nucleo-WB55-Board.

    This topic has been closed for replies.

    4 replies

    垒垒.1
    垒垒.1
    Associate
    November 6, 2021

    Hi! I also met the same problem. Have you solved this problem now?

    KMuel
    KMuelAuthor
    Associate
    November 8, 2021

    Yes, the problem was solved by STM: they sent me a new template, see attached file, with the follwowing explanation:

    "The USB stopped working after after APPE_Init because CPU2 switched off the USB clock. The USB and RNG IPs share the same source clock. During the startup the CPU2 choose as clock source HSI48 and when wireless stack is started then it switched it off. More information about this could be found in AN5289 search for sem5, USB or CPU2 startup.

    To prevent this problem it is useful to block the hardware semaphore 5 before starting the CPU2. You should also decide what valid clock source you would like to use for the USB peripheral. You could use HSI48 with some of the CRS synchronization or you can use PLL with HSE as source. I have edited my previous attempt to show the two possibilities.

    SystemClock_Config is edited to use HSE as source for PLL and USB clock source to be the PLL. Then you can choose to change the USB clock source as HSI48 with PeriphClock_Config() or let it use the PLL and only block the Sem5 with LL_HSEM_1StepLock( HSEM, 5 );"

    Did this solve your problem?

      PATRICK COMBETTE
      PATRICK COMBETTE
      Associate III
      December 2, 2021

      Hello,

      I encounter the same issue with my application.

      My software main function uses :

      • FreeRTOS (not sequecer, I hav one task for BLE, another for USB, and my main task for ANA measurements and processing)
      • ANA for 10 ch measurement and check values
      • GPIO digital out for status depending on ANA measurements
      • FLASH memory to store settings
      • USB VCP communication with a PC for settings and data loggin
      • BLE for remote user app interface

      Since I have added the BLE functionnality, the USB communication which was running well, doesn't start anymore.

      Reading your post, I tested not to call CPU2_Init (of course BLE is not activated), and with this setting the USB VCP operates normally.

      So it confirms it's the same issue.

      My question is (are!) :

      • Could you give much more details on what you mean "block HW SEM befoores stating CPU2" ?
      • How and where can I do that ?
      • Is there something else after CPU2 is initialized ?

      Thank a lot for your ideas.

      Regards

      Patrick

      KMuel
      KMuelAuthor
      Associate
      December 6, 2021

      See Template attached to previous reply, main.c, line 468:

       /**

        * This prevents the CPU2 to disable the HSI48 oscillator when

        * it does not use anymore the RNG IP

        */

       LL_HSEM_1StepLock( HSEM, 5 );

      PATRICK COMBETTE
      PATRICK COMBETTE
      Associate III
      December 7, 2021

      Hi !

      Thank you KMuel, it works now.

      I don't know how you did discover this issue and the way to solv eit, but it's well done !!

      So thank you again,

      Have a nice day.

      Patrick

      Terms & ConditionsAccessibility statement