Has the Teensy 4.x been tested with USB Hubs? (ERR050101)

Status
Not open for further replies.

tarasjg

New member
Hello all!

Has the Teensy 4.x been tested with USB Hubs? I'm developing the second version of an interface board for a project that uses Teensies that are always connected to a central hub.

Here's a pic of the first version for reference:
board pics.PNG

In the second version, I'm gunning for a fully embedded solution - this time with the iMXRT1062 for more horsepower at the edge (processing LiDAR data). This means no more daughterboards, so I'm really looking forward to the release of the chip only offering from pjrc for the 4.x series.

I was checking out the errdata for the chip just to verify that there won't be any show stoppers, and saw ERR050101. This states that there are endpoint conflict problems when in device mode w/ isochronous comm. We use isochronous since we're streaming live LiDAR data. At least, I think we do - I didn't write the ROS driver & firmware. What mode does teensy use default?

Here is the err from NXP for convenience:
err.PNG

Does anyone have any insight on this?

Thanks so much
 
Several users have been seeing problems with the T4x uploading and getting data from the serial monitor. However, when the board is on it's own, it seems to be OK. I just tried my T4.1 running the sonar project through a USB3.1 hub into a Win10 laptop and see no problems in addition to my normal headaches. Just for kicks, I lowered the baud from 115200 to 19200 and it now seems OK on the Win10 laptop and a Win7 desktop. I'm wondering now if there's a slight mismatch between the actual baud freq of the T4x and what the Win boxes can tolerate. I found earlier that lowering the T4x clock to 396MHz almost eliminated the problems but my project needs at least 450MHz. I had no problem with the T3x boards with baud values up to 4Mbps. This was a link between a T3.6 through an FTDI serial/usb2 adapter to a Win7 laptop. The receiving program was written in Lazarus Pascal.
 
The same Win7 box worked with a T3.6 several years ago at 4Mbps through an FTDI adapter. As long as I can get things to work at 19200 during development then I'm OK for now. When the Win7 box goes to Mint Linux then things will change, and hopefully for the better.
 
FWIW, the Teensy 4.x uses a USB-2 speed interface (480 megabits/second). Teensy 3.x/LC uses a USB-1 speed interface (12 megabytes/second). I could imagine some ancient hubs and USB adapters might have problems with it.
 
After reading more into the topic in Chapter 42 of the RT106x Ref Manual, I guess my question has more to do with how 'Serial' is implemented. If interrupt transfer streams are used rather than isochronous - then this silicon error will never exhibit itself. If the general consensus is that things seem to work on hubs, I suppose it's a safe bet to assume things will be fine.

Is USB Hi-Speed accessible in the newest teensyduino version? I checked out the USB Serial page on the pjrc site but it seems out of date, or perhaps more likely I'm looking in the wrong place. If anyone knows where to find more literature on the topic or could offer more insight to how Serial substantiates itself on the new t4.x - I'd greatly appreciate it.

Thanks for the responses so far.
 
Hello all!


I was checking out the errdata for the chip just to verify that there won't be any show stoppers, and saw
ERR050101. This states that there are endpoint conflict problems when in device mode w/ isochronous comm. We use isochronous since we're streaming live LiDAR data.
...

Does anyone have any insight on this?

Thanks so much

Hi there,
I've been developing with the MIMXRT10xx, and can say with confidence that ERR050101 is an egregious bug in the chip. It's a problem specifically with the 1062 rev A silicon, and ALL 105x chips, and many others in the family. The 1011 and 1015, and 1062B I think are the only ones that don't suffer from it.

Basically, if you're using the chips as an Isochronous IN endpoint, you'll run into this problem. So, this applies to things like: audio record, video record, etc. If you're using bulk or interrupt endpoints only, I think you're fine, even through a hub. If you need to use an Isochronous IN endpoint, then you need to control your whole system so that no hubs are used between the 1062 and the computer. OR.. if you know for a fact what endpoints are used in your system, and you can work around using those on the Isochronous in endpoints, then you can use a hub.

In your board, you have 2 devices, which if they're using isoc IN endpoints, you might be out of luck.

All the Teensy's I've personally see are rev A silicon, and so have the bug.

-Caleb
 
Errata ERR050101 applies only if an isochronous IN endpoint is configured. Using Teensyduino, this only happens if Tools > USB Type is set to one of the options with Audio. None of USB Type choices which lack Audio use isochronous endpoints. If you are using the default Serial setting, which uses only bulk and interrupt endpoints, you can not be affected by ERR050101. Likewise, the HID-based settings using only interrupt endpoints. MIDI uses only bulk endpoints.

I can't speak for how non-PJRC code like ROS, Circuit Python, or various projects using NXP's SDK uses the USB endpoints.

Teensy 4.1 switched from the rev A to rev B chips around June 2021.

Teensy 4.0 is still today using rev A. The rev B chips are in the production pipeline. The switch to rev B on Teensy 4.0 is expected around December 2021.

Major distributors with substantial inventory may have boards with the rev A for some time after PJRC switches to rev B. But eventually old stock is replaced by new. By now, virtually all new Teensy 4.1 boards should have the rev B chip.

When viewing the chip, on the middle line, rev A chips will read "0N00X". Rev B chips will read "1N00X". The part number in the first line should also end with "A" or "B".

ERR050101 mentions the bug is triggered by reception of a token meant for another USB device, which typically happens when downstream from a USB hub, because hubs broadcast tokens they receive from the USB host to all their downstream devices. USB hubs don't have anything like the mac address tables maintained by layer 2 enternet switches.

USB audio currently uses endpoint numbers 3 and 4.

Code:
  #define AUDIO_TX_ENDPOINT     3
  #define AUDIO_TX_SIZE         180
  #define AUDIO_RX_ENDPOINT     3
  #define AUDIO_RX_SIZE         180
  #define AUDIO_SYNC_ENDPOINT   4

Most USB devices assign non-control endpoint numbers sequentially starting at 1. Perhaps for a future Teensyduino version, we should change the USB audio endpoints to 6 & 7, so if we are connected to the same hub as other devices, we would minimize the odds of problems in the common case where they use only endpoints 1, 2, and maybe 3 or 4.

For the case mentioned in msg #1, where 2 Teensy 4.1 are downstream from the same hub, if isochronous endpoints are used, any sort of conflict could probably be avoided by carefully editing the USB code used for each (eg, maybe 2 copies of Arduino+Teensyduino) so neither uses the same endpoint numbers the other is using for isochronous IN.

But first, check the markings on the chips. No Teensy 4.1 boards have been made with the rev A chips for some time, so if the boards are newer they should be rev B without errata issue ERR050101.
 
Status
Not open for further replies.
Back
Top