USB Host Ethernet Driver

Could the speed be tied to F_BUS_ACTUAL since that doesn't increase with the CPU speed like in previous versions?
 
In other news, with the new fixes I can now ping up to 8184 bytes which is the max the terminal lets me send so at least that works now.
 
Could the speed be tied to F_BUS_ACTUAL since that doesn't increase with the CPU speed like in previous versions?

Not sure where the other clocks factor in. Especially for USB.

Just put USB LAN on the last PJRC T4 Beta unit - at 912 it just turned into a heater. At 912 and 960 it printed first 2 'USB...' startup lines, but went cold at 960.

Running it seems at 816 on PJRC Beta breakout - PING is the same slower result.
 
In other news, with the new fixes I can now ping up to 8184 bytes which is the max the terminal lets me send so at least that works now.

Indeed larger Ping functions:
Code:
T:\T_Downloads\PSTools>ping 192.168.0.23 -n 10 -l 8192

Pinging 192.168.0.23 with 8192 bytes of data:
Reply from 192.168.0.23: bytes=8192 time=6ms TTL=64
Reply from 192.168.0.23: bytes=8192 time=6ms TTL=64
Reply from 192.168.0.23: bytes=8192 time=7ms TTL=64
Reply from 192.168.0.23: bytes=8192 time=6ms TTL=64
Reply from 192.168.0.23: bytes=8192 time=6ms TTL=64
Reply from 192.168.0.23: bytes=8192 time=6ms TTL=64
Reply from 192.168.0.23: bytes=8192 time=6ms TTL=64
Reply from 192.168.0.23: bytes=8192 time=6ms TTL=64
Reply from 192.168.0.23: bytes=8192 time=6ms TTL=64
Reply from 192.168.0.23: bytes=8192 time=7ms TTL=64

It quits somewhere after this size though:
Code:
T:\T_Downloads\PSTools>ping 192.168.0.23 -n 2 -l 10210

Pinging 192.168.0.23 with 10210 bytes of data:
Reply from 192.168.0.23: bytes=10210 time=7ms TTL=64
Reply from 192.168.0.23: bytes=10210 time=8ms TTL=64
 
I can't tell where latency is being introduced, based on the timestamps in the serial monitor ping replies are being queued at least within the same millisecond as receiving them so something isn't adding up somewhere.
Code:
05:25:52.546 -> rx_data(asix): 1520
05:25:52.546 -> rx_data(asix): 1520
05:25:52.546 -> rx_data(asix): 1520
05:25:52.546 -> rx_data(asix): 1520
05:25:52.546 -> rx_data(asix): 1520
05:25:52.546 -> tx_data(asix): 1518
05:25:52.546 -> tx_data(asix): 1518
05:25:52.546 -> tx_data(asix): 1518
05:25:52.546 -> tx_data(asix): 1518
05:25:52.546 -> tx_data(asix): 1518
 
I can't tell where latency is being introduced, based on the timestamps in the serial monitor ping replies are being queued at least within the same millisecond as receiving them so something isn't adding up somewhere.
...


Yeah - Averages of .9ms .vs. 1.26 ms reported time doesn't add up?

At 0.9 it could be doing 11,000 instead of 8900 - so some loss in overhead before.

But at 1.26 the possible in 10,000 ms would be 7936 - but same PsPing counts under 700? Second T4 with same adapter - from same dos box - gave same under 700 count.

I don't have the old lib code to compare … in some hours maybe I'll put it on a T_3.6 ...
 
I'm not sure how wwatson's MSC driver is able to wait until the data transfer completes, if I try to do it the same way he did it just locks forever and never frees up. Essentially I will have to have a way to do this because UDP messages get sent so fast that it fills up all my buffers before the first one is even sent, it won't make a difference for TCP, but UDP is losing messages because of it.
 
I'm not sure how wwatson's MSC driver is able to wait until the data transfer completes, if I try to do it the same way he did it just locks forever and never frees up. Essentially I will have to have a way to do this because UDP messages get sent so fast that it fills up all my buffers before the first one is even sent, it won't make a difference for TCP, but UDP is losing messages because of it.

Maybe @wwatson will get back to give your code a look. KurtW and MJS513 also have USBHost background that might help?
 
Ok so like I've said before, bigger buffers = more speed, I've been playing around with the TCP buffer size and the results speak for themselves, but that comes at the increase of RAM usage so there is a tradeoff to be made which would be up to whoever writes their Arduino sketch because the number isn't hardcoded. So with a TCP buffer size of 64k, a transmit buffer size of 64k, and a FNET heap size of 128k to cover the TCP buffer I'm getting these results:
Code:
17:03:38.379 -> Starting benchtx...
17:03:38.379 -> Benchmark client started.
17:03:38.379 -> Protocol: TCP
17:03:38.379 -> Remote IP Addr: 192.168.0.55
17:03:38.379 -> Remote Port: 7007
17:03:38.379 -> Message Size: 65536
17:03:38.379 -> Num. of messages: 100
17:03:38.379 -> 
17:03:39.512 -> Megabytes: 6.553600  Seconds: 0.9850  KBits/Sec: 53227.2081
17:03:41.292 -> Starting benchtx...
17:03:41.292 -> Benchmark client started.
17:03:41.292 -> Protocol: TCP
17:03:41.292 -> Remote IP Addr: 192.168.0.55
17:03:41.292 -> Remote Port: 7007
17:03:41.292 -> Message Size: 65536
17:03:41.292 -> Num. of messages: 100
17:03:41.292 -> 
17:03:42.345 -> Megabytes: 6.553600  Seconds: 1.0160  KBits/Sec: 51603.1496
So the speed is there it's just a matter of how much RAM you want to sacrifice for your needs, this used 44% of RAM on the T4.0 and probably won't compile on the T3.6.
 
Ok so like I've said before, bigger buffers = more speed
...

Makes sense - can't move a lot of data unless there is room for it to stream into or out of.

Watching the SD development - it runs at high speed with blocks of 512KB - and for real performance those blocks need to stream in multiples - easy work for a PC with RAM of multi GB's.
 
I'm not sure how wwatson's MSC driver is able to wait until the data transfer completes, if I try to do it the same way he did it just locks forever and never frees up. Essentially I will have to have a way to do this because UDP messages get sent so fast that it fills up all my buffers before the first one is even sent, it won't make a difference for TCP, but UDP is losing messages because of it.

Sorry I have been silent so long. I have been down with a severe cold for a week now. Today I continued to work on an example of your ASIX driver with MSC using a modified version of WXMZ's RawWrite sketch and your ASIXEthernet_test.ino sketch. Results so far are not to good but I need more time to play with it. This is the results of the first try:
Code:
USB Host InputFunctions example
USB Ready
Test logger_RawWrite
uSDFS_VER:30_Jun_19_07_17
BUFFSIZE :8192
Dev Type :2:/
File System FS_FAT32
Free Disk Size 1740204 clusters
Cluster Size 16 sectors
Sector Size 512 bytes

Change drive
A_00001.dat
stat FR_NO_FILE 0
 opened FR_OK 0

Mutex initialized: 0
Mutex initialized: 1
TCP/IP stack initialization is done.

SetMACAddress: 0050B6BE8BB4
MulticastJoin: 333300000001
MulticastTable: 
0
0
10000000
0
0
0
0
0
MulticastJoin: 3333FFE1815E
MulticastTable: 
0
0
10000000
0
0
0
0
10000
netif Initialized
Initializing DHCP
DHCP initialization done!
IPAddress: 0.0.0.0
SubnetMask: 0.0.0.0
Gateway: 0.0.0.0
DHCPServer: 0.0.0.0
State: 2


IPAddress: 192.168.0.103
SubnetMask: 255.255.255.0
Gateway: 192.168.0.1
DHCPServer: 192.168.0.1
State: 5


................................................................
.................................... (1453501006 - 0.022544 MB/s)
 (open: 290992 us; close: 4096000 us; write: min,max: 11985 10134972 us)

openDir FR_OK
A_00001.dat 32768000 2019-10-07 14:58:34
unmount FR_OK

Ping is working in Linux.

This is the result with ASIX adapter unplugged:
Code:
USB Host InputFunctions example
Test logger_RawWrite
uSDFS_VER:30_Jun_19_07_17
BUFFSIZE :8192
Dev Type :2:/
File System FS_FAT32
Free Disk Size 1736204 clusters
Cluster Size 16 sectors
Sector Size 512 bytes

Change drive
USB Ready
A_00001.dat
stat FR_OK 0
 opened FR_OK 0

................................................................
.................................... (13234998 - 2.475860 MB/s)
 (open: 361992 us; close: 33000 us; write: min,max: 11979 68980 us)

openDir FR_OK
A_00001.dat 32768000 2019-10-07 15:14:14
unmount FR_OK

I will add the sketch to MSC's examples folder soon.
Need more time to examine your USB driver for ASIX:)
 
Yeah that makes sense, not to mention the TCP buffer size let’s it transmit more messages before it stops and waits for an acknowledge message from the computer which is where the speed increase is really coming from in that sense because it’s spending less time waiting. The TCP buffer from the computer is 256k so that’s probably where it would need to be at to get 100Mbit/sec, but that’s not exactly realistic with the amount of RAM we have though. I believe without the overhead of USB we would achieve it without such huge buffers, but as it stands there’s quite a bit of latency if it has to wait for a response a bunch of times which is what you see with the ping tests since it’s responding to every message that’s received.
 
Not getting anywhere with this

@all,

I have been trying to figure out why MSC will not work properly with ASIXEthernet. It's going to take somebody with more Ethernet networking skills than I have. All other host USB interfaces like keyboard, mouse and joysticks work properly. Not sure how to proceed from here.:confused:

Here is the sketch I used to test with:
View attachment test_ASIX_rawWrite.zip

Upload to T4 or T36. It will go through initialization and the ASIX will show it's connected at stage 5. Then you can ping it showing about 0.6ms as an average. The RawWrite file will open and that's it! Waiting for RawWrite to complete can take up to several minutes complete unless you unplug the ASIX adapter. Then RawWrite completes as normal. Nothing Locks up.It can be very erratic. Sometimes you have to power off the T4 and power on again to even get MSC to do it's thing.

At his point I am at a loss. I truly believe it's a problem with MSC.:eek:
 
I think it’s the way you lock MSC while waiting for the USB transfer to complete, it appears to me like it only triggers if the previous transfer wasn’t complete before it sends the next one out. Which probably works fine with the other host drivers because they aren’t queuing as much data as mine does so the while loop never triggers. I don’t think the while loop works as you intended it to because when I try to implement the same while loop to wait for a transfer to complete the driver locks up and never returns.
 
I think it’s the way you lock MSC while waiting for the USB transfer to complete, it appears to me like it only triggers if the previous transfer wasn’t complete before it sends the next one out. Which probably works fine with the other host drivers because they aren’t queuing as much data as mine does so the while loop never triggers. I don’t think the while loop works as you intended it to because when I try to implement the same while loop to wait for a transfer to complete the driver locks up and never returns.

Ok, I see what you are saying. Time for a re-write. First understand the queuing process.

Thanks:)
 
Ok so I added an experimental method that seems to kind of work, it only gets called when the all the queue transmit buffers are full but it lets it get stuck in a while loop that just calls myusb.Task() from the arduino sketch so the usb continues to work so it sends out at least 1 queue transfer so another buffer is available. This is mainly for UDP since TCP never overflows my buffer limit, the transfer speeds of this method are dodgy at best, sometimes it's fast and sometimes it's slow but at least the messages aren't lost anymore. This really isn't my ideal solution, because like I said earlier I don't want it to just lock up and wait, but this is just experimental to test if it should be a thing. I also lowered all the buffers to 32k instead of 64k so there is more RAM for other code in the future, placed the FNET heap in DMAMEM, and doubled it's size so that it uses the other half of the T4.0 RAM that isn't normally used so more is available for other code, this didn't seem to impact the performance so I believe it's fine there.

Sadly I don't know what would speed up the TCP receive speeds, likely bigger queue receive buffers but the bigger buffer always seems to introduce random errors for some reason plus takes up more RAM space.
Here's my TCP transmit speeds with the 32k buffers and an increasing amount of messages to test stability at high numbers:
Code:
00:37:26.214 -> Starting benchtx...
00:37:26.214 -> Benchmark client started.
00:37:26.214 -> Protocol: TCP
00:37:26.214 -> Remote IP Addr: 192.168.0.55
00:37:26.214 -> Remote Port: 7007
00:37:26.214 -> Message Size: 32374
00:37:26.214 -> Num. of messages: 100
00:37:26.214 -> 
00:37:27.059 -> Megabytes: 3.237400  Seconds: 0.7860  KBits/Sec: 32950.6361
00:37:31.553 -> Starting benchtx...
00:37:31.553 -> Benchmark client started.
00:37:31.553 -> Protocol: TCP
00:37:31.553 -> Remote IP Addr: 192.168.0.55
00:37:31.553 -> Remote Port: 7007
00:37:31.553 -> Message Size: 32374
00:37:31.553 -> Num. of messages: 1000
00:37:31.553 -> 
00:37:38.341 -> Megabytes: 32.374000  Seconds: 6.7860  KBits/Sec: 38165.6351
00:37:56.934 -> Starting benchtx...
00:37:56.934 -> Benchmark client started.
00:37:56.934 -> Protocol: TCP
00:37:56.934 -> Remote IP Addr: 192.168.0.55
00:37:56.934 -> Remote Port: 7007
00:37:56.934 -> Message Size: 32374
00:37:56.934 -> Num. of messages: 10000
00:37:56.934 -> 
00:39:09.037 -> Megabytes: 323.740000  Seconds: 68.8560  KBits/Sec: 37613.5703
 
Ok so I added an experimental method that seems to kind of work,
...

Using code from 4 hours back now - machine and network rebooted - IP addr changed.

Pings still slow at 600 versus 8900 on fast PSping64. This is with T4 at 600 MHz.

Seeing this on SerMon for UDP then TCP:
Code:
Megabytes: 0.204800  Seconds: 0.1740  KBits/Sec: 9416.0920
Megabytes: 0.204800  Seconds: 0.1860  KBits/Sec: 8808.6022
Megabytes: 0.204800  Seconds: 0.1920  KBits/Sec: 8533.3333
Megabytes: 0.204800  Seconds: 0.1980  KBits/Sec: 8274.7475
Megabytes: 2.048000  Seconds: 1.7040  KBits/Sec: 9615.0235
Megabytes: 2.048000  Seconds: 1.7340  KBits/Sec: 9448.6736
Megabytes: 2.048000  Seconds: 1.7400  KBits/Sec: 9416.0920
Megabytes: 2.048000  Seconds: 1.7640  KBits/Sec: 9287.9819

fBench shows:
Code:
Udp	192.168.0.5	1.282	2,048,000	12,779.298
Udp	192.168.0.5	1.290	2,048,000	12,698.626
Udp	192.168.0.5	1.256	2,048,000	13,044.073
Udp	192.168.0.5	1.265	2,048,000	12,952.063
Tcp	192.168.0.5	1.638	2,048,000	10,000.988
Tcp	192.168.0.5	1.622	2,048,000	10,098.005
Tcp	192.168.0.5	1.627	2,048,000	10,068.497
Tcp	192.168.0.5	1.629	2,048,000	10,059.992

And again no connect at 912 MHz
 
I still don’t know what happened to ping and the transfer speeds are a little skewed when you don’t transfer a lot of data at once because there is a little delay at the start and end of a stream of messages that’s why I test with such high number to try and factor that out. However, at this point I am convinced we are achieving roughly the full 100Mbit/sec transfer speed, but with the overhead of some of the protocols it brings the speed tests down.
 
Ping was good before some prior change … never worked the same since :(

I got CONNECT at 912 MHz - also works at " F_CPU=816000000":
Code:
USB Host InputFunctions example
USB Ready

[COLOR="#FF0000"] F_CPU=912000000	deg  C=54[/COLOR]
Looped: 1  LoopedUSB: 3507  LinkSpeed: 10BASE
Looped: 1  LoopedUSB: 0  LinkSpeed: 10BASE
Looped: 6243687  LoopedUSB: 1680  LinkSpeed: 10BASE
Mutex initialized: 0
Mutex initialized: 1
TCP/IP stack initialization is done.

SetMACAddress: 0050B6BE8BB4
MulticastJoin: 333300000001
MulticastTable: 
0
0
10000000
0
0
0
0
0
MulticastJoin: 3333FFE225AB
MulticastTable: 
0
0
10000000
0
0
0
0
100000
netif Initialized
Initializing DHCP
DHCP initialization done!
IPAddress: 0.0.0.0
SubnetMask: 0.0.0.0
Gateway: 0.0.0.0
DHCPServer: 0.0.0.0
State: 2


IPAddress: 192.168.0.8
SubnetMask: 255.255.255.0
Gateway: 192.168.0.1
DHCPServer: 192.168.0.1
State: 5


Looped: 12670374  LoopedUSB: 3507  FNETMemFree: 64656  LinkSpeed: 100BASE
Looped: 12472042  LoopedUSB: 3486  FNETMemFree: 64656  LinkSpeed: 100BASE

I changed the END of setup() to this::
Code:
setup(){
…
  setHandleIsConnected(handleIsConnected);
#if defined(__IMXRT1062__)
  Serial.printf("\n F_CPU=%u", F_CPU_ACTUAL );
  Serial.printf( "\tdeg  C=%u\n" , (uint32_t)tempmonGetTemp() );
#endif
[COLOR="#FF0000"][B]  delay ( 1000 );[/B][/COLOR]
}

The loop() polling "It Seems" is too fast as higher speeds to allow 10 base to change to allow connection processing without the other things in the usbthread() processing first!

delay(2000) does not work for 960 MHz :(

I'm working on an alternative direction with the original suggested HACKED values - it works for 912 MHz without the delay(1000) in setup();
 
Leaving setup() without post #219's delay(1000);

This works for connect at 912 MHz - but still not 960 MHz.

I changed it to use a higher count { 4000 instead of 2000 } and 960 still fails, I added a counter to repeat { of 4 or 2000 times ) the higher count for multiple times at the start - neither worked for 960 MHz.

AFAIK - guessing - the higher call rates of this loop(){ ... myusb.Task(); asix1.read(); ...} before connection (USB? LAN?} starts without the other things in usbthread() prevent the initial connect?

But going back to the original HACKED concept of stay longer when usbthread() is first invoked:
Code:
void usbthread() {
  uint32_t cc = 0;
  while(1) {
    myusb.Task();
    asix1.read();
    checkLink();
    if(fnet_netif_is_initialized(current_netif)){
      fnet_poll();
      fnet_service_poll();
    }
    #ifdef STATS
    LoopedUSB++;
    #endif
    #ifdef HACKED
    cc++;
[COLOR="#FF0000"]    if ( cc > 2000 ) {
[/COLOR]      cc=1980;
      threads.yield();
    }
    #endif
  }
}
 
@vjmuzik - was up too late testing prior posts … then wondering what about delayed start - that is T4 starts with no USB connected ?

So with post #220 code::
>>The T4 powered down, USB unplugged to LAN adapter.
>> Power T4, see a couple 'looped' messages pass
>> Plug in USB LAN adapter at 912 MHZ - it connects and comes up running.

So there is something Early in the USB is seems - though this same process at 960 MHz still fails.

NOTE: to run over 816 MHz an uncooled T4 may not run. A copper heat sink is in use here and internal temp is 67°C {152.6 °F} at 912 MHz

ANOTHER ITEM of note::
> Restarting the 912 MHz T4 it did not come up right away with USB plugged in - even using above code.
>> Unplug USB {no LAN light blinks present}
>> Then plug USB and the LAN lights come to life.
 
Likely it’s getting caught up somewhere in the initialization phase when it has to send all the queue controls one after the other, if you turn on the USBHOST_PRINT_DEBUG in the USBHost_t36.h file you can see at what point it fails and that should give some insight. I don’t have any heat sinks or I would test at the higher speeds.
 
Likely it’s getting caught up somewhere in the initialization phase when it has to send all the queue controls one after the other, if you turn on the USBHOST_PRINT_DEBUG in the USBHost_t36.h file you can see at what point it fails and that should give some insight. I don’t have any heat sinks or I would test at the higher speeds.


Enabled debug print at F_CPU=960000000::
Code:
USB Host InputFunctions example
USB2 PLL running
 reset waited 6
USBHS_ASYNCLISTADDR = 0
USBHS_PERIODICLISTBASE = 2003B000
periodictable = 2003B000
USB Ready
port change: 10001803
    connect

 F_CPU=960000000	deg  C=62
Looped: 1  LoopedUSB: 0  LinkSpeed: 10BASE	deg  C=62
  begin reset
port change: 18001205
  port enabled
  end recovery
new_Device: 480 Mbit/sec
new_Pipe
enumeration:
enumeration:
enumeration:
Device Descriptor:
  12 01 00 02 FF FF 00 40 95 0B 2B 77 01 00 01 02 03 01 
    VendorID = 0B95, ProductID = 772B, Version = 0001
    Class/Subclass/Protocol = 255 / 255 / 0
    Number of Configurations = 1
enumeration:
enumeration:
Manufacturer: ASIX Elec. Corp.
enumeration:
Product: AX88772B
enumeration:
Serial Number: E225AB
enumeration:
Config data length = 39
enumeration:
Configuration Descriptor:
  09 02 27 00 01 01 04 A0 64 
    NumInterfaces = 1
    ConfigurationValue = 1
  09 04 00 00 03 FF FF 00 07 
    Interface = 0
    Number of endpoints = 3
    Class/Subclass/Protocol = 255 / 255 / 0
  07 05 81 03 08 00 0B 
    Endpoint = 1 IN
    Type = Interrupt
    Max Size = 8
    Polling Interval = 11
  07 05 82 02 00 02 00 
    Endpoint = 2 IN
    Type = Bulk
    Max Size = 512
    Polling Interval = 0
  07 05 03 02 00 02 00 
    Endpoint = 3 OUT
    Type = Bulk
    Max Size = 512
    Polling Interval = 0
enumeration:
USBHub memory usage = 960
USBHub claim_device this=20002E00
USBHub memory usage = 960
USBHub claim_device this=20002A20
Descriptor 4 = INTERFACE
ASIXEthernet claim this=200031E0
type=1
vid=B95, pid=772B, bDeviceClass = 255, bDeviceSubClass = 255, bDeviceProtocol = 0
numEndpoints=3
      interrupt_size = 8
      interrupt_ep = 129
      interrupt_interval = 11
      rx_size = 512
      rx_ep = 130
      rx_interval = 0
      tx_size = 512
      tx_ep = 3
      tx_interval = 0
new_Pipe
new_Pipe
new_Pipe
allocate_interrupt_pipe_bandwidth
  ep interval = 11
  interval = 256
 best_bandwidth = 3, at offset = 0
[COLOR="#FF0000"]Control - ASIX...
Descriptor 5 = ENDPOINT
Descriptor 5 = ENDPOINT
Descriptor 5 = ENDPOINT[/COLOR]
Looped: 6661980  LoopedUSB: 3660  LinkSpeed: 10BASE	deg  C=63
Looped: 12289359  LoopedUSB: 3507  LinkSpeed: 10BASE	deg  C=64
Looped: 12289361  LoopedUSB: 3507  LinkSpeed: 10BASE	deg  C=64
Looped: 12289409  LoopedUSB: 3486  LinkSpeed: 10BASE	deg  C=64
Looped: 12289368  LoopedUSB: 3507  LinkSpeed: 10BASE	deg  C=65
Looped: 12289361  LoopedUSB: 3507  LinkSpeed: 10BASE	deg  C=65
Looped: 12289273  LoopedUSB: 3486  LinkSpeed: 10BASE	deg  C=65
Looped: 12289363  LoopedUSB: 3507  LinkSpeed: 10BASE	deg  C=65
Looped: 12289245  LoopedUSB: 3507  LinkSpeed: 10BASE	deg  C=65
Looped: 12289392  LoopedUSB: 3486  LinkSpeed: 10BASE	deg  C=65
Looped: 12289253  LoopedUSB: 3507  LinkSpeed: 10BASE	deg  C=66
Looped: 12289357  LoopedUSB: 3507  LinkSpeed: 10BASE	deg  C=66

Moved to 912 MHz - and the HACKED change was no longer enough for connect - had to restore the delay(1000); in setup() and then I get this:
Code:
USB Host InputFunctions example
USB2 PLL running
 reset waited 6
USBHS_ASYNCLISTADDR = 0
USBHS_PERIODICLISTBASE = 2003B000
periodictable = 2003B000
USB Ready
port change: 10001803
    connect

 F_CPU=912000000	deg  C=57
  begin reset
port change: 18001205
  port enabled
  end recovery
new_Device: 480 Mbit/sec
new_Pipe
enumeration:
enumeration:
enumeration:
Device Descriptor:
  12 01 00 02 FF FF 00 40 95 0B 2B 77 01 00 01 02 03 01 
    VendorID = 0B95, ProductID = 772B, Version = 0001
    Class/Subclass/Protocol = 255 / 255 / 0
    Number of Configurations = 1
enumeration:
enumeration:
Manufacturer: ASIX Elec. Corp.
enumeration:
Product: AX88772B
enumeration:
Serial Number: E225AB
enumeration:
Config data length = 39
enumeration:
Configuration Descriptor:
  09 02 27 00 01 01 04 A0 64 
    NumInterfaces = 1
    ConfigurationValue = 1
  09 04 00 00 03 FF FF 00 07 
    Interface = 0
    Number of endpoints = 3
    Class/Subclass/Protocol = 255 / 255 / 0
  07 05 81 03 08 00 0B 
    Endpoint = 1 IN
    Type = Interrupt
    Max Size = 8
    Polling Interval = 11
  07 05 82 02 00 02 00 
    Endpoint = 2 IN
    Type = Bulk
    Max Size = 512
    Polling Interval = 0
  07 05 03 02 00 02 00 
    Endpoint = 3 OUT
    Type = Bulk
    Max Size = 512
    Polling Interval = 0
enumeration:
USBHub memory usage = 960
USBHub claim_device this=20002E00
USBHub memory usage = 960
USBHub claim_device this=20002A20
Descriptor 4 = INTERFACE
ASIXEthernet claim this=200031E0
type=1
vid=B95, pid=772B, bDeviceClass = 255, bDeviceSubClass = 255, bDeviceProtocol = 0
numEndpoints=3
      interrupt_size = 8
      interrupt_ep = 129
      interrupt_interval = 11
      rx_size = 512
      rx_ep = 130
      rx_interval = 0
      tx_size = 512
      tx_ep = 3
      tx_interval = 0
new_Pipe
new_Pipe
new_Pipe
allocate_interrupt_pipe_bandwidth
  ep interval = 11
  interval = 256
 best_bandwidth = 3, at offset = 0
[COLOR="#FF0000"]Control - ASIX...
Descriptor 5 = ENDPOINT
Descriptor 5 = ENDPOINT
Descriptor 5 = ENDPOINT[/COLOR]
control callback (asix) 1
Done
control callback (asix) 2
Done
control callback (asix) 3
nodeID: 00 50 B6 E2 25 AB 
control callback (asix) 4
Done
control callback (asix) 5
Done
control callback (asix) 6
Done
control callback (asix) 7
Done
control callback (asix) 8
Done
control callback (asix) 9
Done
control callback (asix) 10
Done
control callback (asix) 11
Done
control callback (asix) 12
Done
control callback (asix) 13
Done
control callback (asix) 14
Done
control callback (asix) 15
Done
control callback (asix) 16
Done
control callback (asix) 17
Done
control callback (asix) 18
Done
control callback (asix) 19
Done
control callback (asix) 20
Done
control callback (asix) 21
Done
control callback (asix) 22
Done
control callback (asix) 23
Done
control callback (asix) 24
Done
control callback (asix) 25
Done
control callback (asix) 26
Done
control callback (asix) 27
Done
control callback (asix) 28
Done
control callback (asix) 29
Done
control callback (asix) 30
Done
control callback (asix) 31
Done
control callback (asix) 32
Done
control callback (asix) 33
Done
control callback (asix) 34
Done
control callback (asix) 35
Done
control callback (asix) 36
Done
control callback (asix) 37
Done
control callback (asix) 38
Done
control callback (asix) 39
Done
control callback (asix) 40
Done
control callback (asix) 41
Done
control callback (asix) 42
Done
control callback (asix) 43
Done
control callback (asix) 44
Done
control callback (asix) 45
Done
control callback (asix) 46
Done
control callback (asix) 47
Done
control callback (asix) 255
Looped: 1  LoopedUSB: 7487  LinkSpeed: 10BASE	deg  C=58
Looped: 1  LoopedUSB: 0  LinkSpeed: 10BASE	deg  C=58
Looped: 5602844  LoopedUSB: 1680  LinkSpeed: 10BASE	deg  C=59
control callback (asix) 49
Done
control callback (asix) 50
Done
control callback (asix) 51
Done
control callback (asix) 52
Done
control callback (asix) 53
Done
control callback (asix) 54
Done
control callback (asix) 55
Done
control callback (asix) 56
Done
control callback (asix) 57
Done
control callback (asix) 58
Done
control callback (asix) 59
Done
control callback (asix) 60
Done
control callback (asix) 61
Done
control callback (asix) 62
Done
control callback (asix) 63
Done
control callback (asix) 64
Done
control callback (asix) 65
Done
control callback (asix) 254
Mutex initialized: 0
Mutex initialized: 1
TCP/IP stack initialization is done.

SetMACAddress: 0050B6BE8BB4
MulticastJoin: 333300000001
MulticastTable: 
0
0
10000000
0
0
0
0
0
MulticastJoin: 3333FFE225AB
MulticastTable: 
0
0
10000000
0
0
0
0
100000
netif Initialized
Initializing DHCP
DHCP initialization done!
IPAddress: 0.0.0.0
SubnetMask: 0.0.0.0
Gateway: 0.0.0.0
DHCPServer: 0.0.0.0
State: 2


control callback (asix) 254
control callback (asix) 254
IPAddress: 192.168.0.12
SubnetMask: 255.255.255.0
Gateway: 192.168.0.1
DHCPServer: 192.168.0.1
State: 5


Looped: 11404940  LoopedUSB: 3507  FNETMemFree: 64656  LinkSpeed: 100BASE	deg  C=60
Looped: 11224911  LoopedUSB: 3486  FNETMemFree: 64656  LinkSpeed: 100BASE	deg  C=59
Looped: 11223853  LoopedUSB: 3507  FNETMemFree: 64656  LinkSpeed: 100BASE	deg  C=60
Looped: 11223976  LoopedUSB: 3507  FNETMemFree: 64656  LinkSpeed: 100BASE	deg  C=60

EDIT RED where the text diverges
 
Last edited:
These are ones just received like the one in use: amazon.com/gp/product/B00637X42A

I re-ran 960 MHz with setup(){… delay(1000);} and no change.

Plug and unplug USB and - as above - stops after this as far as USB feeback:
Code:
 best_bandwidth = 3, at offset = 0
Control - ASIX...
Descriptor 5 = ENDPOINT
Descriptor 5 = ENDPOINT
Descriptor 5 = ENDPOINT
 
So it looks like the first queue control transfer doesn’t complete so it never goes anywhere, oddly enough the T3.6 would get stuck there sometimes as well when I first uploaded new code without a power cycle and I noticed the T4.0 never got stuck there when I switched to it. Seems like it still happens with the T4.0, but only at higher clock speeds.
 
Back
Top