[gadget driver] HOST turns unresponsive to gadget driver

I'm writing a multi-function composite gadget driver gadget driver similar to drivers/usb/gadget/ncm.c and multi.c using composite framework, with f_ncm.c (existing) and one vendor specific function file with an interface and endpoint descriptors.

When the module is loaded in the device and connected to desktop running Ubuntu[HOST], to verify the descriptors, the desktop turns unresponsive, but the device looks fine. The only way to come out is to power off and restart the host.

When I analyzed the logs using protocol analyzer it shows some timeout error as follows & then host just hangs.

Timeout error for getting string descriptor

2D 06 90 --> (and ep 0 & address 6)
C3 80 06 04 03 09 04 FF 00 97 BD --> (string)
D2 --> (ACK)
unfortunately I couldn't get more info because of the above issue.

could someone give some pointers to how can I find out where the problem is?

I also tried loading the module "g_ncm.ko" and executed "lsusb" on the host side. The lsusb (or cat /sys/kernel/debug/usb/devices) takes some time to respond [ 5 to10 secs ]. Is this expected/normal behavior? I've seen a similar module, which I think uses f_ncm.c and one more function which loads & runs almost instantly. Is there a way to optimize ?

5-10 seconds is long in the scheme of things, but there could be delay issues somewhere we are unaware of. Depending on the length of interrupts, and the number of them, and network backlog, there could be delays, but I would earmark that as suspicious. I saw Z80 systems with 128 levels of interrupt that had to be trashed in research; they were interrupted so much they never got to execute the main code :-/.

The next step can be tiresome and take you time. So accept that some routine(s) you think are ok are actually screwing you up. Look at your code again. Try any software debugging techniques.

Lastly, get a C --> Assembler --> machine code listing of your programme, and a logic analyser. You can hire the logic Analyser. Trigger on an address or data word at the beginning of your suspicious section. You get up what the computer does. So you can see which instruction it performs next. If everything looks OK, move on, etc. Suddenly you will se an unexplainable jump or word appear. Figure that out and you have solved it. Be prepared to lose a week at it, though. You could lose most of a week doing this.

@business_kid
Thanks for the warning and input

I'm pretty sure that the problem is not with the hardware, because there is one similar module which runs on the same hardware & with `lsusb` command I can read those descriptors which are actually the same as in https://github.com/boundarydevices/l...t/f_ncm.c#L146, the module name suggests that is is using "ncm" and also it works without any problem. I'm trying to find a hack to get it working as expected.

Anyway, I'll give it a try.

-Thanks

looks like someone had similar issue http://e2e.ti.com/support/arm/sitara...320035/1118205

shortening the string by removing " (NCM)" here https://github.com/boundarydevices/l...t/f_ncm.c#L342 solved the problem ! Don't know the reason yet.