You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am sharing how to correct a flaw in the TinyUSB USBTMC driver that I discovered.
I am running on an STM32H5 processor, running FreeRTOS OS and setting it up to communicate with USB488 protocol.
I initially started out using this driver interfacing through the Keysight I/O Libraries drivers to get communication up and running with the H5 target device. Query reads were working fine in this configuration.
After adding code to support using Windows built-in WinUSB drivers instead, I discovered that attempts by the application "read" responses, after sending a query command, were hanging up. I eventually discovered that this was due to "usbtmc_app_task_iter" getting stuck in case 2, due to a lack of events occurring to trigger the next state of this routine.
After further investigation, I discovered that this was the case even using the Keysight drivers. But there is a peculiarity in the Keysight drivers that hides this problem. The Keysight drivers would eventually transmit a couple of class 7 setup request that would break the lockup and allow TinyUSB to finish transmitting its response back to the host, making it look like things were working, when actually they were not.
To Fix this I had to add the following routine to usbd.c
I then added calls to this routine into case 2 and case 3 of usbtmc_app_task_iter, to keep the event queue filled and keep things moving along in the task. This is necessary if you want to operate through a WinUSB driver.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
I am sharing how to correct a flaw in the TinyUSB USBTMC driver that I discovered.
I am running on an STM32H5 processor, running FreeRTOS OS and setting it up to communicate with USB488 protocol.
I initially started out using this driver interfacing through the Keysight I/O Libraries drivers to get communication up and running with the H5 target device. Query reads were working fine in this configuration.
After adding code to support using Windows built-in WinUSB drivers instead, I discovered that attempts by the application "read" responses, after sending a query command, were hanging up. I eventually discovered that this was due to "usbtmc_app_task_iter" getting stuck in case 2, due to a lack of events occurring to trigger the next state of this routine.
After further investigation, I discovered that this was the case even using the Keysight drivers. But there is a peculiarity in the Keysight drivers that hides this problem. The Keysight drivers would eventually transmit a couple of class 7 setup request that would break the lockup and allow TinyUSB to finish transmitting its response back to the host, making it look like things were working, when actually they were not.
To Fix this I had to add the following routine to usbd.c
bool tud_send_event_to_resume (uint8_t rhport)
{
dcd_event_t const event_resume = {.rhport = rhport, .event_id = DCD_EVENT_RESUME};
return queue_event(&event_resume, true);
}
I then added calls to this routine into case 2 and case 3 of usbtmc_app_task_iter, to keep the event queue filled and keep things moving along in the task. This is necessary if you want to operate through a WinUSB driver.
Beta Was this translation helpful? Give feedback.
All reactions