usb gadget with cdc ethernet not work

[junwushi]

rndis feature is not work, show linux USB Ehternet/RNDIS gadget #4 in window device tree ,but it is with "！“，does not work.

[junwushi]

if building kernel with usb gadget->serial gadget(with cdc acm and cdc obex support), the serial comport device will often not work,many times reboot the linux device ,the comport device will work in window xp/10.

[yachen]

Hi @junwushi ,

We are aware of the RNDIS issue and have engineer checking it now.
Can you provide us your kernel config for CDC issue? We've test it before and have other customers using it but didn't see the issue you report. Thanks.

Sincerely,

Yi-An Chen

[junwushi]

Dear Chen,
i already upload my ".config" file,please remove the extension ".zip" and decompress it with TAR.
config.tar.zip

[yachen]

Hi @junwushi ,

I'm able to reproduce the CDC unstable issue and have forwarded the issue to the engineer who maintain the NUC970 gadget driver. Will update the fix to Github as soon as it's fixed.

Sincerely,

Yi-An Chen

[yachen]

Hi @junwushi ,

Please check if commit c1a9947 fix CDC issue or not.
RNDIS issue is still under investigating.

Sincerely,

Yi-An Chen

[junwushi]

rndis still not work, device driver install normal,but network device always show in disable status,can't enable even you maunul enable it. the attach is the rndis driver for windows.
linux.rar.zip

[yachen]

Hi @junwushi ,

This patch is intent for fix the "usb gadget->serial gadget serial comport device will often not work" issue you reported. Please let us know if this fixed the CDC issue. Thanks.
We're still working on the RNDIS issue and will push to this repository after it's fixed.

Sincerely,

Yi-An Chen

[junwushi]

yes, the CDC seems stable,will observe it a long time.

[junwushi]

the issue is still there, usually all seems ok(device is ok, port is ready). but just can't comunicate,type any char not response in ttyGS0(getty). after reboot many times ,it is restore working. why?

[yachen]

Hi @junwushi ,

May I know how do you test the ttyGS0? I'm testing with putty on my Windows machine and cannot reproduce the problem so far.

Sincerely,

Yi-An Chen

[junwushi]

if application open the ttyGS0 ,then disconnect the usb cable,the ttyGS0 device lost in linux,but the application maybe hang that still perform some function of the device ttyGS0 (like selct() etc.). and window side does not know the comport is invalid, not received any notify for disconnect.

[junwushi]

other thing,the battery adc reference voltage use #define INTERNAL_VALTAGE 2500 in bsp adc driver,but use 3300 is corrent ADC data result in fact . why? please confirm my supcisions are corrent? i am not sure,and the program guide docment is so simple.

[schung1218]

Hi @junwushi
The battery voltage detection select internal voltage(2.5v) or external reference pin.
if the external reference pin connect 3.3v, use 3300 is correct.
if the external reference pin is floating , use 2500 is correct.

[junwushi]

sometimes hang up in udc driver infinite loop line:
"
pr_devel("RxED dma triggered\n");
while ((_raw_read(controller.reg + REG_USBD_IRQ_STAT) &0x20 )==0 );
"
when if you multiple plug on/off the usb cable and reopen /dev/ttyGS0 for comunucation.

[junwushi]

and I found the USB_FLT_DET irq never execute,not print plug in and un plug message in console.

[yachen]

@junwushi ,

What board are you testing? "USB_FLT_DET irq never execute" should be hardware issue.

Sincerely,

Yi-An Chen

[junwushi]

it is host&device otg mode, the ph0 pin always high voltage,becase usb VCC it is connect battery. how to design usb0 in otg mode and ph0 can indentify device plug in and off? but a lot of infinite loop code in udc driver is not good approach,please use better way to handle those exception. please slove it asap.

[yachen]

Hi @junwushi ,

Are you using Nuvoton's DEV board? If so, please set SW34:1 to OFF position and change R83 to 20K Ohm, R84 to 39K Ohm.

Sincerely,

Yi-An Chen

[junwushi]

my device usually die and show the "hangup1" that add by my self for debug ,why?

write_packet(struct nuc970_ep *ep, struct nuc970_request *req)
{
struct nuc970_udc *udc = &controller;
unsigned len, tmp;
u8 *buf;
u32 data, i;
u32 max;

buf = req->req.buf + req->req.actual;
prefetch(buf);

// if (udc->gadget.speed == USB_SPEED_FULL)
// udelay(500);

if (ep->ep_num == 0)
{ //ctrl pipe don't use DMA
	max = ep->ep.maxpacket;
	len = min(req->req.length - req->req.actual, max);

	if (len == 0)
	{
		if (req->req.zero&&!req->req.length)
			__raw_writel(CEP_ZEROLEN, controller.reg + REG_USBD_CEP_CTRL_STAT);
	}
	else
	{
		i=0;
		while ((__raw_readl(controller.reg + REG_USBD_CEP_IRQ_STAT) & 0x1000) != 0x1000)
		{
			i++;
			if (i>10000) printk("hang up1\r\n");
		}
			;

[yachen]

Hi @junwushi ,

The loop is waiting for previous transfer to complete. Shouldn't stuck there. Did you make other modification as well?
Anyway, please pull latest driver, we fixed some issues including the udc_transfer() always return 0 you reported.

Sincerely,

Yi-An Chen

[junwushi]

the udc_transfer() always return 0 maybe right, becase i check that code in the dma irq process to increase the count. so don't need return send bytes.
the last code i am checking

[junwushi]

"udc_transfer() always return 0" is not issue, please change back it, that is right, now test the new code ,that not working, and change back udc_transfer() return 0 that working.

[yachen]

Hi @junwushi ,

Updated, please pull again. Many thanks for the feedback.

Sincerely,

Yi-An Chen

[junwushi]

ok, working

[junwushi]

still same issue in udc driver. write_packet only die in while {} section and wait forever.
other things, below code, first unlock and then lock is right?
static void nuke (struct nuc970_udc *udc, struct nuc970_ep *ep)
{
while (!list_empty (&ep->queue))
{
struct nuc970_request *req;
req = list_entry (ep->queue.next, struct nuc970_request, queue);
list_del_init (&req->queue);
req->req.status = -ESHUTDOWN;
spin_unlock (&udc->lock);
req->req.complete (&ep->ep, &req->req);
spin_lock (&udc->lock);
}
}

[junwushi]

now i used the USB cable that maybe not good and then print below message cycle,change another cable that not show any message,i think the driver need consider the unreliable situation,avoid kernel to hangup.
[ 309.680000] g_serial gadget: high-speed config #2: CDC ACM config
[ 414.200000] g_serial gadget: high-speed config #2: CDC ACM config
[ 416.310000] g_serial gadget: high-speed config #2: CDC ACM config
[ 438.370000] g_serial gadget: high-speed config #2: CDC ACM config
[ 442.360000] g_serial gadget: high-speed config #2: CDC ACM config
[ 452.400000] g_serial gadget: high-speed config #2: CDC ACM config
[ 484.570000] g_serial gadget: high-speed config #2: CDC ACM config
[ 528.790000] g_serial gadget: high-speed config #2: CDC ACM config
[ 530.830000] g_serial gadget: high-speed config #2: CDC ACM config
[ 534.840000] g_serial gadget: high-speed config #2: CDC ACM config
[ 536.830000] g_serial gadget: high-speed config #2: CDC ACM config
[ 657.340000] g_serial gadget: high-speed config #2: CDC ACM config
[ 657.600000] g_serial gadget: high-speed config #2: CDC ACM config
[ 657.870000] g_serial gadget: high-speed config #2: CDC ACM config
[ 673.170000] g_serial gadget: high-speed config #2: CDC ACM config
[ 673.450000] g_serial gadget: high-speed config #2: CDC ACM config
[ 673.730000] g_serial gadget: high-speed config #2: CDC ACM config
[ 699.050000] g_serial gadget: high-speed config #2: CDC ACM config
[ 699.310000] g_serial gadget: high-speed config #2: CDC ACM config
[ 764.210000] g_serial gadget: high-speed config #2: CDC ACM config
[ 764.470000] g_serial gadget: high-speed config #2: CDC ACM config
[ 789.890000] hangup1!
[ 799.800000] g_serial gadget: high-speed config #2: CDC ACM config
[ 800.040000] g_serial gadget: high-speed config #2: CDC ACM config
[ 800.330000] g_serial gadget: high-speed config #2: CDC ACM config
[ 800.580000] g_serial gadget: high-speed config #2: CDC ACM config
[ 800.870000] g_serial gadget: high-speed config #2: CDC ACM config
[ 801.170000] g_serial gadget: high-speed config #2: CDC ACM config

[yachen]

We think the lock/unlock could be removed in nuke(). Will do some more test before release update.

[junwushi]

new issues:
I connect the 3g module in USB port 2, it is show below error,and I am be care of to check hardware, not found any problem:

[ 2.710000] usb 2-2: new low-speed USB device number 2 using nuc970-ohci
[ 2.900000] usb 2-2: device descriptor read/64, error -62
[ 3.190000] usb 2-2: device descriptor read/64, error -62
[ 3.480000] usb 2-2: new low-speed USB device number 3 using nuc970-ohci
[ 3.670000] usb 2-2: device descriptor read/64, error -62
[ 3.960000] usb 2-2: device descriptor read/64, error -62
[ 4.250000] usb 2-2: new low-speed USB device number 4 using nuc970-ohci

[yachen]

Hi @junwushi ,

This is a USB signal quality issue. We have other customer's hardware got same error.
First the dongle was misidentified as low speed device, and then driver report error -62.

Sincerely,

Yi-An Chen

[yachen]

Hi @junwushi ,

Please pull 737c84e and see if it fix the write_packet() loop forever issue.
We saw similar issue while connecting with some PC, and this patch fixed it.

Sincerely,

Yi-An Chen

[yachen]

Close unless there's further discussion on this issue.

[swex]

ethernet/RNDIS still not working, any update on this?