g_ether hangs TCP session eventually.

Phillip,

Do you have the link to the patch you mentioned?

Can you please provide more details about your failure case? what tool do you use to reproduce the issue? AM3517 USB works in high-speed or full-speed? Is CPPI DMA enabled or not?

Bin Liu,

Thank you for the response.

Patch link is http://e2e.ti.com/cfs-file.ashx/__key/CommunityServer-Discussions-Components-Files/354/1780.0001_2D002D00_MUSB_2D00_Fix_2D00_for_2D00_CDC_2D00_Host_2D00_issue_2D00_when_2D00_streaming_2D00_more.patch.log

This is reproducible using tftp, and doing gets from a batch file on the Windows 7 PC.  Of course, you have to bring up udpsvd on the AM3505.

This IS a High Speed USB port.

CPPI DMA, I'll have to check.  What I think are the pertinent lines from the .config file follow:

CONFIG_MUSB_PIO_ONLY=y

# CONFIG_USB_INVENTRA_DMA is not set

# CONFIG_USB_TI_CPPI_DMA is not set

# CONFIG_USB_TI_CPPI41_DMA is not set

# CONFIG_USB_TUSB_OMAP_DMA is not set

It looks to me like no DMA is enabled for USB at all.

****************************************************************************************************************************************

I have built a kernel with DMA enabled and tftp still fails within about 15 minutes looping on a 2.3 MB file get from the AM3505 to a PC,

all transfers initiated by the PC.

Pings do not hang, at least as soon as tftps.  I have been running it for nearly an hour now, in both directions at once.

Phil

It is a high-speed usb port, but it can also work in full-speed mode. Please provide the log of command 'cat /proc/driver/musb_hdrc.0', which will show the speed negotiated with host. Or when you connect the USB cable, the AM3505 serial console will print out a message which tells the speed.

Yes, you don't have CPPI enabled, the patch you referred will not fix your issue.

Bin Liu,

root@am3517-evm:~# cat /proc/driver/musb_hdrc.0 Status: MHDRC, Mode=Peripheral (Power=f0, DevCtl=99) OTG state: b_peripheral; active Options: ?dma?, peripheral, debug=0 [eps=16] Peripheral address: 01 CPPI: txcr=2048 txsrc=0 txena=0; rxcr=0 rxsrc=0 rxena=0 Gadget driver: g_ether

ep0 (hw0): 1buf, csr 0000 maxp 0000         (queue empty)

ep1in (hw1): 1buf dma, csr 2404 maxp 0200 TX DMA0: 00000000 00000000, 00000000 00000000; 00000000 00000000 00000000 .. 00000000         (queue empty)

ep1out (hw1): 1buf dma, csr 2000 maxp 0200 RX DMA0: 0 left, 00000000 00000000, 00000000 00000000; 00000000 00000000 00000000 .. 00000000         req cf747400, 0/2048         req cf747440, 0/2048         req cf747480, 0/2048         req cf7474c0, 0/2048         req cf747500, 0/2048         req cf747540, 0/2048         req cf747580, 0/2048         req cf7475c0, 0/2048         req cf747600, 0/2048         req cf7473c0, 0/2048

ep2in (hw2): 1buf dma, csr 2404 maxp 0008 TX DMA1: 00000000 00000000, 00000000 00000000; 00000000 00000000 00000000 .. 00000000         (queue empty)

The .config options now look like:

# CONFIG_MUSB_PIO_ONLY is not set

# CONFIG_USB_TI_CPPI_DMA_HW is not set

CONFIG_USB_TI_CPPI41_DMA_HW=y

# CONFIG_USB_INVENTRA_DMA is not set

# CONFIG_USB_TI_CPPI_DMA is not set

CONFIG_USB_TI_CPPI41_DMA=y

# CONFIG_USB_TUSB_OMAP_DMA is not set

Ok, the log shows that it runs in high-speed mode, with DMA enabled.

Can you please disable CPPI DMA to see if the issue still exists? Meanwhile I will try if I can replicate the issue on AM3517 EVM with SDK 5.5.1.0 kernel using tftp command. How big is the file to transfer? How soon the link hangs?

Hello, Bin Liu.

About High speed and DMA: I was running in PIO mode up to the very last time, when I enabled DMA to see if it affected the result.  It hangs whether or not DMA is enabled.

I am transferring a 2.3 MB file, since this is the size of the video frame that I will be transferring programmatically.  It usually hangs after less than 30 trips through a batch file loop on the PC.  However, the size of the file does not seem to matter.  It will hang on smal files or large, if enough repetitions are done.

At the risk of being redundant, I consider it significant that the link does not hang on pings.  I tested with 4096-byte buffers, going both directions at once.  It ran for an hour.  I will increase the buffer size of pings to the maximum allowed and try that, but I don't expect the link to hang.  There is something different about pings.  I'm not sure whether ping uses the entire TCP/IP stack or not.  Determining that might give a clue.

Late breaking news:

I ran the largest buffers that the two pings would allow, 65505 from the AM3505 and 65500 from the PC, and there was no hang.  There was, however, what I would call a "hiccup" when I accessed the internet on my PC.  That could well be a traffic problem with Windows 7.  Both sides recovered and continued.  Here is the output from the AM3505 console:

65513 bytes from 10.10.10.10: seq=356 ttl=128 time=14.790 ms
65513 bytes from 10.10.10.10: seq=357 ttl=128 time=14.781 ms
[57232.314605] musb_g_ep0_irq 707: SetupEnd came in a wrong ep0stage setup
[57232.324310] rndis_msg_parser: unknown RNDIS message 0x80000004 len 28
[57232.330902] g_ether gadget: RNDIS command error -524, 0/12
[57232.444030] g_ether gadget: high speed config #2: RNDIS
65513 bytes from 10.10.10.10: seq=367 ttl=128 time=16.388 ms
65513 bytes from 10.10.10.10: seq=368 ttl=128 time=15.106 ms

The AM3505 ping always seems to add 8 bytes to the buffer size; hence 65513 instead of 65505.  I don't know why.  The PC seems to use the exact buffer size specified on the command line.

Phil

Phillip,

I took the SDK 5.5.1.0 prebuilt uImage (which has CPPI disabled) on AM3517EVM, and used the following script on evm to download a file in a loop from a Linux PC. But I don't see the timeout issue - the script can run more than 50 iterations until I Ctrl-C'd it. I tested multiple times.

cnt=0
while true; do
        tftp -l /dev/null -r uImage.am3517.5510 -g 192.168.3.3 || break
        echo cnt: $((cnt += 1))
done

I did not use udpsvd though (I never used it and not familiar with it), and the host is Linux not Win7.

Have you tried with Linux host? or do you have an AM3517 EVM to replicate the issue?

And have you tried wireshark on host if there is any clue?

Phillip Norisez said:

[57232.314605] musb_g_ep0_irq 707: SetupEnd came in a wrong ep0stage setup
[57232.324310] rndis_msg_parser: unknown RNDIS message 0x80000004 len 28

This sounds like an issue related to RNDIS, probably CDC ECM will not have the issue. So please test it with a Linux PC to see if we can narrow it down to Windows only. I heard the open source RNDIS support is not that great due the proprietary spec of RNDIS.

By the way, if possible please post your update into a new post instead of editing the existing post, because we don't get the email notification for the modification, then missed the update.

Thank you, I will ceratinly not append to posts hereafter.

Yes, I suspected that it was an RNDIS issue.  Since retries worked on it, and the link whas not hung, I discounted it.  It's nice to know that you also see nothing sinister in it. 

Bin Liu,

I do not have a linux host here to try.  Just WIndows 7.  If it is necessary, I can find one.  But I really need you to see it with udpsvd.

udpsvd is the mechanism I need to use.  I need the host able to tftp down to the AM3505, not the other way around.  To start udpsvd on the AM3517 EVM:

   udpsvd -vE 10.10.10.11 69 tftpd -c -u root / &

For the 10.10.10.11, substitute the AM3517EVM's IP.  Please try this and run the transfer loop on the host to get the file from the EVM, not as you have done it.

I was only using updsvd for this report as a stand in for my own TCP sockets server code, so that I could report the issue with a "standard" server in the AM3517 PDP, thus eliminating my code.

In contrast, I have run mutual pings up to 2500 times and not seen the issue.  I put wireshark on the pings and saw nothing suspicious.  I'll try with updsvd to see if I can see anything.  Good suggestion.

Phil

Bin Liu,

I tried the wireshark test with the result that the hang's signature was that everything was normal up to the point that the AM3505 stopped responding to the Windows 7 PC.  It was during a normal transfer sequence.  The tftp client on the PC was sending an acknowledgement to a data packet received from the server on the AM3505, and the AM3505 never responded.  Restarting udpsvd did not restore the link.  The PC loop continued to try, and I saw ARP packets from the PC trying to find 10.10.10.11, but without any response.  Attempts to ping the PC from the AM3505 failed.  Attempts to ping the AM3505 from the PC also failed.

Thanks for the update.

I will try a setup with Win7 and udpsvd, and update when I have any progress, it might take some time though.

Bin Liu,

While you are waiting, I think you may find that a Linux host will cause it to hang if you do back-to-back gets to the udpsvd running on the AM3517.  Just a guess.  Thanks for devoting so much of your time to this.  I have a client breathing down my neck for a solution of some kind.

Phillip,

I tried the Windows tftp client: http://sourceforge.net/projects/tftputil/ on Windows XP, but I still don't see the issue as I was able to successfully 'put' a 1.5MB file >50 times.

I did get 'tftp read error' on evm when sometimes I clicked the 'put file' button too fast, but the link does not hang at all.

Do you have an AM3517 EVM to test it as while?

Phillip Norisez said:

if you do back-to-back gets to the udpsvd running on the AM3517

This does not trigger the issue either.

Bin Liu,

Sorry for the delayed response.  Please try letting it run overnight.  Thanks.

The Windows tftp client I use is GUI based, which cannot be used in bat script.

What tftp cli tool do you use?

Never mind. I found the Windows built-in tftp command.

If the issue does not show up today (the loop is already running over 400 iterations), I will leave the script running over this weekend.

Bin Liu,

Thanks for trying to reproduce my environment as closely as possible.  I am in the process of obtaining an AM3517 EVM board.  It is off site, and I need to get it back from the person that has it.  I intend to work the weekend on this.  If you could share with me anything that you even suspect, I could dive in and try to verify or dispell them.  Thanks.

Phil

Bin Liu,

How do I turn on debug output from your TCP/IP stack?  Perhaps there is a clue there.

Phil

0066.EVM.txt

1376.Windows7.txt

2046.config.txt

Bin Liu,

I have succeeded in reproducing the hang on a 3517 EVM and have attempted to document it for you sufficiently that you can reproduce it yourself.

The fiirst two attachments, EVM.txt and Windows7.txt, show the EVM and Windows sides of the exchange.  I have shown the entire boot sequence of the EVM so that you will be able to see the envirnment that loaded.  I logged in as root, and started up tftpd with the two commands "ifconfig usb0 10.10.10.11" and "updsvd -vE 10.10.10.11 69 -c -u root / &"  As you can see, it did not take long for the hang to occur, perhaps 2 minutes.  For your convenience, I have taken the liberty of adding the sequence numbers displayed on the EVM console by udpsvd/tftpd to the Windows log, so that you can see the correspondence.

The third attachment is the .config file that I used with a virgin linux-2.6.37-psp04.02.00.07.sdk to build the kernel.  I used xconfig to remove network devices and add the USB/g-ether device as a resident part of the kernel.  The root file system was created from ti-sdk-am3517-evm-05.05.01.00/filesystem/base-rootfs-am3517-evm.tar.gz, after restoring it to a local directory and using the command "mkfs.jffs2 -lqn –e 128 -r base-rootfs -o virginBaseRootfs.bin".  I used the Flash utility 1.6 to download both the kernel (uImage) and root filesystem (virginBaseRootfs.bin) to the EVM's NAND flash at the offsets 280000 and 780000, respectively, using HWECC, ONFI Compliant, and 1bit ECC.

Please notice that the version of the SDK and its PSP were not the latest, but onwes that I strarted development with in November of 2012.  Thus, it is possible that this issue was fixed in a later version, and I missed it.  I have now committed to the version that I have, and would find it quite disrupting to change versions now.  My alternative would be to identify the patch that fixed the later version and apply it to my version.

Correction to the tftfd startup command:  "updsvd -vE 10.10.10.11 69 tftpd -c -u root / &"

Phillip,

I got the lockup issue twice, one happened about ~3900 iterations, the second happened at 371 iterations. But the behavior I got is slightly different from what you see: I don't have the 'musb_g_ep0_irq 707: SetupEnd came in a wrong ep0stage idle' error message, and when the issue happens, ping does not work at all, ipconfig on host hags forever.

I will try to rebuild thee kernel with NET disabled, which is what you did, and run the test again.

Do you have access to USB protocol analyzer to capture a trace? I'd like to see what causes 'musb_g_ep0_irq 707: SetupEnd came in a wrong ep0stage idle' error.

Bin Liu,

Thanks.  I'm glad you were able to observe a lockup.

I have not tried ipconfig.  I will try it today and report results.

For me, the hang is not always cooincidental with the "SetupEnd" error.  In fact, it usually isn't. 

"with NET disabled" I did not disable the network protocols, only the network device. 

"Do you have access to USB protocol analyzer to capture a trace?"  I am informed that wireshark will do it, and I have wireshark.  I will try it.

Also, I do see the link recover sometimes from a "SetupEnd" error.

The SetupEnd error could be USB packet timing related, I don't think wireshark will capture it. The protocol analyzer is the right equipment for this.

We do not have a USB protocol analyzer, and I cannot justify the expense to buy or rent one at this time.  I am less concerned with the SetupEnd error than with the hang, itself.  That is, unless there is a demonstratable cause and effect relationship.  Right now, I have seen several hangs without any messages concerning SetupEnd error, so I conclude that it is possibly not related.

If the only way to get a protocol analyzer to catch the SetupEnd error is to do it using our 3505 board, I could send you one, preprogrammed, but with the ability to be reprogrammed via Flash1.6.  You would also have to use a serial port terminal emulator for a console, since the virtual USB COM port hardware is not functioning on our board for some reason.  The hardware is connected to a uart port of the 3505 and is not using the real USB port on the 3505 at all, so I would expect there to be no relationship between it and the g_ether hang.

Phillip,

I don't think it is necessary for you to buy a analyzer at this moment, since this is no evidence showing the SetupEnd error is related to the hang, as you said.

If you board can consistently reproduce the issue within a few minutes, it probably will help me to debug the issue if I have one, since my EVM takes hours to show the issue.

But could you please ask your local TI FAE to contact me first before ship me the board?

Boards are at a premium here, at the moment.  Is there any possibility of a technical resource doing an on-site visit to address this?  I address this not only to Bin Liu, but also to my local reps and SAE.

Bin Liu,

OK, the idea of a site visit met with silence.  So, I have verified that my EVM board fails within minutes.  Since it belongs to our local rep, Arrow Electronics, I feel that I need their permission to send it to you, but I will do so if you say so in order to expedite a solution to this issue.  I'm BCCing the rep's people in hopes that they will get back to me soon with permission.

Phillip,

Does your EVM fail within minutes consistently? Mine only failed ONCE in a few minutes, then all other tests failed in 4~5 hours, which makes the debug very difficult. Maybe it is also related to the host, I remember you mentioned in your setup when the issue happened, ping still works, but in my setup when the issue happened, ping/ipconfig hangs, and I cannot kill the cmd window which runs the tftp script, I have to force the power button to reboot the PC.

My debug progress has been very slow due to that I can only see the issue twice a day.

Please let your TI rep to contact me to discuss about shipping the board.

Bin Liu,

I have permission to send you the EVM board.  I need to have an address to which to send it.

Bin Liu,

The board will be on its way this (Tuesday, July 9, 2013) morning by next day air.  I have preloaded the kernel that I generated from a pure TI ti-sdk-am3517-evm-05.05.01.00.  Note that this is a retro version of the SDK.

I used the white USB cable in the kit.  If you do not havea Windows 7 PC, I can arrange to send you one of those, also, but it will be harder to do than the EVM kit.

Thanks,

Phillip

Phillip,

Thanks for the update. I will test with the EVM once I receive it.

I just got a Win7 PC later yesterday, and it runs for about 3 hours until now, but have not shown the issue yet.

Phillip,

I had my EVM running with Win7 host for 16 hours, but the issue did not happen.

I have also received your EVM, and have it up and running for 1 hour until now (with ~1300 tftp iterations) but still did not see the issue yet.

I will leave it running over night, but just want to check with you on your Win7 RNDIS driver configurations. What I did was that right-click on "RNDIS/Ethernet Gadget" listed in Device Manager on Win7, clicked "Update Driver Software...", then followed the procedure in the attached screen shots below to install the RNDIS driver. And the driver version is "6/21/2006 6.1.7600.16385". Please check if this is different from your configuration.

I also want to mention that with your EVM, the host is unable to download image_000000.raw, the EVM serial console reports JFFS2 CRC error. So what I did was copying the file from / to /dev/shm/, and pointed the directory to tftpd.

Bin Liu,

Regarding the JFFS2 errors, they have not seemed to affect anything, so I put resolving them on the back burner.  Besides, my application does not store images in files, but does a send() directly out of the mmapped device buffer.

My system is a 64-bit Windows 7, and it reports that the RNDIS driver is from Acer and is version 1.0.0.0.  I have attempted, on numerous occasions, to find and load a later version, but all that update driver does is fiddle around for a while and then report that I am running the most recent driver.  The computer is a Dell T1600, if that means anything to you.  Here is what I see when I try to update the driver via the "Pick from list" option. 

When it does hang, are you able to determine anything at all? I mean have you put a packet sniffer on the virtual ethernet link to determine if any message in particular may be responsible? Are you able to ping the EVM from the PC, and vice versa?

Yeah, I don't worry about the JFFS2 error either, I figured you application will have the data on DDR only.

Well, I don't know why your PC cannot use the Microsoft RNDIS driver. Maybe you can try to un-check 'Show compatible hardware' to see if there is more options? Do you have other PC with retail version of Win7 to test with? Or is it possible to re-install OS in T1600 to remove the already installed RNDIS driver?

I have your EVM running for 21 hours until now with Win7 host, and the issue still does not happen. I guess the RNDIS driver on the host plays an important role in this issue.

I only saw the hang issue with a WinXP host. When the issue happens, ping does not work from either side. ifconfig on EVM still works, but ipconfig on host hangs.

(After installed Win7 on my PC with XP dual boot, the Win7 installation updated the XP, now the RNDIS driver stops working on XP, it cannot start the device. So I am no longer be able to run tests on XP.)

When it hangs with XP, there is no any USB data traffic on the BUS, expect SOF packets.

Well, it looks like the ball is in my court while I sort out the RNDIS drivers and try that for a solution.

Your suggestion about the A different win 7 is a good one.  I'm trying to get my hands on a 32-bit Win 7 and see what that does.  I have tried a win 7 32-bit Embedded, and it takes long, but it still hangs.

I hope that you'll understand that TI is not yet off the hook on this one, until I can demonstrate that it is truly a Microsoft problem by direct evidence.

Meanwhile, I have another post on another issue that is also of high importance to me.

LATE BREAKING NEWS ON JFFS2:

 I am getting the following consistently on one of our boards.  I will add a new post on this if I determine that it is an issue.  I changed the text text that bothers me most to red.

[  129.524444] JFFS2 notice: (678) read_dnode: wrong data CRC in data node at 0x00c1104c: read 0x265ed94e, calculated 0xebe2518f.
[  129.536315] JFFS2 warning: (678) jffs2_do_read_inode_internal: no data nodes found for ino #2440
[  129.545471]
[  129.545471] =========================
[  129.550750] [ BUG: held lock freed! ]
[  129.554504] -------------------------
[  129.558258] jffs2_gcd_mtd4/678 is freeing memory cedf4c00-cedf4fff, with a lock still held there!
[  129.567352]  (&f->sem#2){+.+.+.}, at: [<c01b20c8>] jffs2_do_crccheck_inode+0xb0/0x108
[  129.575408] 2 locks held by jffs2_gcd_mtd4/678:
[  129.580047]  #0:  (&c->alloc_sem){+.+.+.}, at: [<c01b6618>] jffs2_garbage_collect_pass+0x1c/0x800
[  129.589172]  #1:  (&f->sem#2){+.+.+.}, at: [<c01b20c8>] jffs2_do_crccheck_inode+0xb0/0x108
[  129.597686]
[  129.597686] stack backtrace:
[  129.602203] [<c0049690>] (unwind_backtrace+0x0/0xe0) from [<c009e334>] (debug_check_no_locks_freed+0xf0/0x140)
[  129.612487] [<c009e334>] (debug_check_no_locks_freed+0xf0/0x140) from [<c00f4750>] (kfree+0xbc/0x11c)
[  129.621948] [<c00f4750>] (kfree+0xbc/0x11c) from [<c01b2100>] (jffs2_do_crccheck_inode+0xe8/0x108)
[  129.631134] [<c01b2100>] (jffs2_do_crccheck_inode+0xe8/0x108) from [<c01b67b4>] (jffs2_garbage_collect_pass+0x1b8/0x800)
[  129.642272] [<c01b67b4>] (jffs2_garbage_collect_pass+0x1b8/0x800) from [<c01b81d4>] (jffs2_garbage_collect_thread+0x168/0x1a0)
[  129.653961] [<c01b81d4>] (jffs2_garbage_collect_thread+0x168/0x1a0) from [<c0089fa4>] (kthread+0x7c/0x84)
[  129.663787] [<c0089fa4>] (kthread+0x7c/0x84) from [<c0044ad4>] (kernel_thread_exit+0x0/0x8)
[  129.672454] Returned error for crccheck of ino #2440. Expect badness...
[  145.860839] JFFS2 notice: (678) check_node_data: wrong data CRC in data node at 0x07675778: read 0x86414f40, calculated 0xc0e38fb0.
[  146.032684] JFFS2 notice: (678) check_node_data: wrong data CRC in data node at 0x045eedcc: read 0x77b51a99, calculated 0x2d1ab22b.
[  148.227905] JFFS2 notice: (678) check_node_data: wrong data CRC in data node at 0x076716d8: read 0x466821b4, calculated 0x32fb2b97.

Phillip Norisez said:

Your suggestion about the A different win 7 is a good one.  I'm trying to get my hands on a 32-bit Win 7 and see what that does.  I have tried a win 7 32-bit Embedded, and it takes long, but it still hangs.

The Win7 I am testing with is 64-bit.

Phillip Norisez said:

I hope that you'll understand that TI is not yet off the hook on this one, until I can demonstrate that it is truly a Microsoft problem by direct evidence.

Fully understood. We will try our best to continue support you as much as we can.

Phillip Norisez said:

Meanwhile, I have another post on another issue that is also of high importance to me.

LATE BREAKING NEWS ON JFFS2:

I am not an export on JFFS2, and I would recommend you to open a new post for this issue since I would think our flash experts will not monitor this thread because its subject implies it is for USB (g_ether). I also recommend you to post the new issue to AM3x forum, not this Linunx forum.

The AM3x forum is here:

http://e2e.ti.com/support/arm/sitara_arm/f/791.aspx

BIn Liu,

I have opened a support call with Microsoft about the version of the RNDIS driver.  Meanwhile, I have verified that this issue (the hang) occurs within minutes using a Windows 7 32-bit.  In fact, I was able to use one of our target production units to verify it, so it is indeed an issue for the product.

I searched MSDN for the revision that you specified, and found a hotfix which I already had on this computer.  So, I don't know where you got the revison number that you related.  Is there any possiblity that you can send me your driver and that I could try it here? 

Phillip,

I did fresh install of Win7 only and did not install any extra package.

Please let me know the exact filename you want me to send?

There seem to be many files associated with USB.  The one specifically reported is C:\Windows\system32\DRIVERS\usb8023.sys (file version 6.1.7601.18076) by device Manager for the "USB Ethernet/RNDIS Gadget #5" on my 64-bit system.  On my 32-bit Windows 7 Embedded system, the files are C:\Windows\system32\DRIVERS\rndismp6.sys(6.1.7600.16835) and C:\Windows\system32\DRIVERS\usb80236.sys (6.7601.18076).  The  behavior is the same on both systems.  The Embedded system is the ultimate target for the application that will be using the board.  There are two different boards, and they both act the same way, as does the EVM board which I sent you.  Both of the 8023 files seem to be associated with Win7 SP1.

A suggested course of action has come to light here that we need to pursue.  Can the computer, its hard drive, or a backup be sent here so that we can see if the problem resolves that way?  We will still have the problem that it manifests within hours.  However, if we cann distill the essence of the difference between your Windows and mine, we might be able to use that to proceed with completing development and some part of field trials.  I told the originator of this idea that, if you are willing, it is worth a try.

Or, how about a clone of its hard drive?  Or cloning it to a USB stick?  Or other ideas which you might suggest.

have you tried a certified USB cable? Some low quality cable will cause noise on the BUS can corrupt the USB packets.

I have tried it with several USB cables.  The latest is a Gigaware cable.  I will be glad to try whatever cable you suggest, if you can be more specific.  What brand is the one you are using?  How long is it?

Hello Bin Liu,

Is there any "Golden Code", used with a specific Linux build and Windows operating system, based on the logic pd board that would show this or part of this functionality? Anything code that would get us going in the right direction that is known to work? Phil has had this functionality working with the Beagle Board....we need the same for the AM35xx

Sevrum,

By 'Golden Code', do you mean kernel source code? From TI support perspective, AM37x (used on Beagle Board) uses the same kernel code base which is the same as AM35xx does - Arago linux-omap3.git.

I understand your frustration, unfortunately I am unable to replicate the issue with Win7 PC I have. But from what I observed during my investigation, I till suspect the RNDIS driver on Win7 host playing an important role in this issue, as I was seeing different packet traffic on the USB bus with two different Win7 PCs , when no USB communications by the application layer.

I am still trying my best to find any direction to get deep into this issue, meanwhile I am thinking if you can re-design your project to not use RNDIS for data transfer?