tusb_deinit() deletes a queue on which tud_task() is blocked ...

[mudrovc]

I'm using the stack with STM32F777 core, FreeRTOS and custom board.

I have a separete task just to call tud_task() in a loop. I'm tring to catch USB cable disconnect event (the board is self powered). There is an external GPIO for this functionality. After detecting the situation - I'm calling tusb_deinit(). Up to this moment it looks fine.

The call of tusb_deinit() effectively deletes the _usbd_q queue. But at this time the tud_task() is waiting on the same queue. Which is FreeRTOS confilct in fact. Did I'm make something in wrong sequence? Or I'm missing something? Or it's a bug?

[HiFiPhile]

You need to call tusb_deinit in USB task, check new example in #3378
https://github.com/hathach/tinyusb/blob/dwc2_deinit/examples/dual/dynamic_switch/src/main.c

[mudrovc]

Ahaaaa, thanks!

I have missed the fact that tud_task_ext() accepts timeout as parameter. This changes the game.

Meanwhile I made a workaround of my problem via a small change in tud_deinit() code. I just add the following line just before the queue deletion.

// Deinit device queue & task
dcd_event_bus_signal(rhport, DCD_EVENT_UNPLUGGED, false);
osal_queue_delete(_usbd_q);
_usbd_q = NULL;

This signals an event to the tud_task() message queue and effectively unblocks it, before queue deletition. This resolves the FreeRTOS conflict in my code. The advantage in this solution is that tud_umount_cb() is invoked as bonus. I'm using it for external state machine transitions. The DWC2 driver cannot detect properly unplug of the usb cable in my configuration, so this callback is not activated by original code.
Anyway this is not a really good solution, I know. I'm sharing it, just to note if the tud_umount_cb() internal call is important for somebody else.

Thanks again for the help!

[HiFiPhile]

I made a workaround of my problem via a small change in tud_deinit() code. I just add the following line just before the queue deletion.

If USB task is in standby and blocking on the queue your workaround works. However if the task is processing but the stack is deinited by another task it's very dangerous that no one knows where read/write will goes !

Even programming on Windows/Linux it's a bad idea to free a resource from one thread using by another thread.

[mudrovc]

I'm absolutely agree with you. As I wrote - this is not a good solution. Just wrote it to note you that it invokes de-enumaration callback. Probably it's good (or maybe not) to have this feature in this case, realized in another way of course.

The problem is that DWC2 driver do not detect properly cable unplug condition. I know, this is problem of the synopsys silicon, not the software. That's why in my design, I have a hardware detection of this condition via an external pin. I'm catching it outside of the stack and I need to react properly.

But in fact there is no way to signal the stack "from outside" for cable disconect with an API call. The only way to react is to kill(deinit) the stack. Which is working, if the tud_task() is not blocked "forever". Now I know how to do it, thanks again. But it looks like to switch off the TV via the mains cable instead of power button ;)

If I have a way to signal the stack for this situation, it will unblock tud_task internally, and the de-enumration calback will also be invoked. Which looks a bit more clear as a program flow. But this is my point of view, probaly I'm missing something. The solution you proposed me - works properly, I tested it. This is clear!

P.S. I'm working with external HS ULPI, maybe this also makes some sense...

[HiFiPhile]

Could you clarify what you need exactly ?

For post-deinit stuff you can place the code in tud_suspend_cb instead of tud_umount_cb, with your external signal you can distinguish between suspend or disconnection.

For manual forced disconnection you can use tud_disconnect()/tud_connect() but I haven't tried them with ULPI phy.

[mudrovc]

I don't need anything for the moment - all works fine currently, when I have a possibility to select timeout for tud_task(). I had some expectations, but this is due to my previous usage of other USB stacks.

The main "problem" comes from the following: When USB cable is unplugged but device is self powered, the synopsys core stops without any events for this condition (no interrupts). I don't know is it comming from the synopsys silicon, or external HS PHY in my case - but this is the case. Calling of tud_disconnect() does not generate tud_unmount_cb in this case. There is no any USB interrupts when cable is unplugged. One solution is to catch the situation is the SOF missing. But this makes additional ISR load of the system. So I'm catching this condition via external hardware - GPIO or ADC to read VUSB. So now I need to kill the stack outside, without internal stack automation. When tud_task() is used - this is not possible, since the task is continously blocked on the queue at this moment. But with tud_task_ext and a proper timeout - all is fine.

Thanks again. The problem is resolved.