2022-04-13 11:30 AM
Hi everyone,
I'm developing a device based on a STM32WB55 which has a USB interface. Using CubeMX I created a project with a Custom HID device, FreeRTOS + CMSIS v2.
I need to send frames of a proprietary protocol which content usually don't exceed 64 bytes, but sometimes these frames could be up to 255 bytes.
For some reason, I can only send interrupt reports (bulk is not possible), so I made a function that splits the frames into several 64 bytes packets and then send them successively.
On the first try, I did it by blocking the CUSTOM_HID_SendReport() call with a while(USBD_BUSY == CUSTOM_HID_SendReport(...)); It works, but this is not a good way as the microcontroler ressources are blocked until the bus becomes USBD_OK.
I then tried using a semaphore, so that I try to get the semaphore using osSemaporeAcquire() before calling CUSTOM_HID_SendReport().
The problem I'm facing is that I can't find the best place in the USB Stack to release the Semaphore when the report has been sent, to unlock the following packet and so until the entire frame has been sent.
I exposed the complete problem in hope that anybody could help me, even if I'm possibly not using the best/proper way to do it.
Thanks in advance for your help and time !
Solved! Go to Solution.
2022-04-21 06:39 AM
Hello !
Thanks for your answer, I don't really understand what you mean by updating the report characteristic 🤔
I forgot to update this post actually, but I figured out that my semaphore wasn't properly initialized (as I called osSemaphoreNew() in the ISR that init the HID class). Plus I only verified that the osSemaphoreAcquire() didn't return osTimeout (while it returned another error as the semaphore wasn't created due to the ISR call) so it was like the osSemaphoreAcquire() never existed in the algorithm...
It decided to put its init in the MX_USB_Device_Init() function for test purpose and this solution seems to work regarding to the timings recorded.
The function USBD_CUSTOM_HID_DataIn() seems to be called at the end of a transmission and I managed to test it with . The challenge is now to find when I could create the semaphore according to my design because we want to this semaphore to be created and destroyed when the USB is respectively connected and disconnected to the computer.
I am currently trying another solution using event flags which could better suit to my needs: the event flags could handle both the USB's connection status (connected/disconnected) and the availability of the bus. In a design point of view, this solution makes me more eligible to initializing it in the MX_USB_Device_Init() because the event flags is related to the USB "in a larger way".
But when I run the program, I manage to make it work for a while and communicate with the computer and then, the target stops running and the debugger just freezes for no reason so I can't pause the program and try to understand which context make it suddenly stop like that :(
2022-04-21 03:08 AM
Hello,
Maybe you can release the semaphore once the report characteristic is updated.
Best Regards
2022-04-21 06:39 AM
Hello !
Thanks for your answer, I don't really understand what you mean by updating the report characteristic 🤔
I forgot to update this post actually, but I figured out that my semaphore wasn't properly initialized (as I called osSemaphoreNew() in the ISR that init the HID class). Plus I only verified that the osSemaphoreAcquire() didn't return osTimeout (while it returned another error as the semaphore wasn't created due to the ISR call) so it was like the osSemaphoreAcquire() never existed in the algorithm...
It decided to put its init in the MX_USB_Device_Init() function for test purpose and this solution seems to work regarding to the timings recorded.
The function USBD_CUSTOM_HID_DataIn() seems to be called at the end of a transmission and I managed to test it with . The challenge is now to find when I could create the semaphore according to my design because we want to this semaphore to be created and destroyed when the USB is respectively connected and disconnected to the computer.
I am currently trying another solution using event flags which could better suit to my needs: the event flags could handle both the USB's connection status (connected/disconnected) and the availability of the bus. In a design point of view, this solution makes me more eligible to initializing it in the MX_USB_Device_Init() because the event flags is related to the USB "in a larger way".
But when I run the program, I manage to make it work for a while and communicate with the computer and then, the target stops running and the debugger just freezes for no reason so I can't pause the program and try to understand which context make it suddenly stop like that :(