Handling SET CONFIGURATION implemented in hardware

[jefftrull]

I've been debugging a reset problem and tracked it down to the fact that the SET CONFIGURATION logic inside TinyUSB does not get called, because the hardware handles the request directly. As a result, post-reset the _usbd_dev.itf2drv table is invalid and my CDC class accesses (in particular SET LINE CONTROL) fail.

Is there a simple way to handle this within the existing TinyUSB codebase? And in general, what facilities are there for interoperating with hardware-implemented requests?

[hathach]

I never seen an hardware that handle SET CONFIGURATION, your info is too generic. Could you provide details on your setup, board, mcu, sdk, examples and your compiling code ?

[jefftrull]

Hi! I am porting tusb to a new platform (or actually, an old platform - a Canoscan 4200f scanner from the mid 2000s). It's based on an ALi 8051 scanner ASIC, the M5623. The SDK is a custom work by myself involving a RISCV emulation layer by @cyrozap (I am also doing one based on SDCC in parallel).

Through extensive debugging I have learned that the itf2drv table is invalidated by reset, but its entries should be set by a subsequent SET CONFIGURATION performed by the host. Unfortunately the code inside tusb for this never gets executed because it's implemented in hardware. I am confident in this for two reasons:

1. Documentation for a related chip in the same timeframe by the same manufacturer, the M5621, lists SET CONFIGURATION as implemented in hardware
2. The USB interrupt service routine never receives this command, but I can see from Wireshark that it is executed.

Currently I am working around the problem by commenting out this line, after which the device successfully enumerates with tusb. Is there a better approach?

[hathach]

that is weird implementation of M5623. However, you can walkaround by faking an SET_CONFIGURATION when receving an full GET_CONFIGUATION since they are normall next to each other. There is an weak hook called dcd_edpt0_status_complete() which is called after an control transfer is complete. You could examine the request packet if that is GET_CONFIGURATION with total length > 9 than fake the SET_CONFIGUATION by calling dcd_event_setup_received() with according packet. This way you put your hack into your own dcd without modifying the usbd stack making updating easier.

e.g samd use this hook to cleanup/prepare for next setup
https://github.com/hathach/tinyusb/blob/master/src/portable/microchip/samd/dcd_samd.c#L197

[jefftrull]

Well, I've tried to do this and am encountering two problems:

1. The system never seems to send a GET_CONFIGURATION. It does send a GET_DESCRIPTOR CONFIGURATION, though. However
2. this transaction doesn't call dcd_edpt0_status_complete when it is done (only a handful of transactions do, in my observation)