Teensy 3.6 USB Host support

The debug output does not show VID/PID so the mouse never even enumerates. Make sure the mouse works on a computer. Or try a powered USB hub.
 
Hi all,
As I said previously, the 3.6 USB host port is running fine with Buydisplay touchscreen. 10.1"
Using a Techtoy HDMI board and the Techtoy shield adaptor for 3.6.
 
Hi all.
I have to ask everyone's excuses because my problem is wire connections.
Everything works correctly, hub, keyboard and mouse.
I thank you for the collaboration received and I hope it does not happen again.
Thank you very much to all.
 
Host to host?

Would it be possible to connect another host device to the teensy via Host port and the USBHost_t36 library?

Example - Let's say I have a Raspberry Pi that sends out USBmidi and I wanted to get that into my mac using the teensy 3.6 as a translator.
 
Would it be possible to connect another host device to the teensy via Host port and the USBHost_t36 library?

Nope, sorry, that can't work. USBHost_t36 only communicates with USB devices and hubs. It can't talk to other USB hosts.

Example - Let's say I have a Raspberry Pi that sends out USBmidi and I wanted to get that into my mac using the teensy 3.6 as a translator.

You could accomplish this using a pair of Teensy 3.x or even Teensy LC, with hardware serial lines between them. Each board listens on its USB port and forwards any messages to the other board, and also listens for any incoming messages from the other board and transmits them over USB.

If you want it to run fast, use at least Teensy 3.2, where the serial ports have FIFOs and RTS/CTS handshaking to work effectively at fast baud rates. A pair of Teensy LC boards could do it, but getting the serial link to run in the Mbps range is unlikely with the less powerful LC hardware.
 
I have a USB mini host shield 2.0 on a Teensy 3.6. Turned it on today, seemed good, my bluetooth dongle plugged into it was blinking.

I just set up a new computer, got all the latest libraries and sent my code to Teensy and then the host shield wouldn't initialize. When I run the test program, This is the entire output:

USB Host Testing - Serial

What could be the source of this problem?
 
I still find it unfortunate that this chip has EHCI. It is not by any means an MCU friendly hardware design.

While it MIGHT make sense if using an RTOS, it is still a horrid USB implementation, never liked [eox]HCI controllers, here's why.
1. Too much work on the processor side.
2. Takes a huge amount of code to actually do anything, code bloat.
3. You can't just send a packet.
4. Memory eating pipes.
5. Manual timing (WTAF???). Reminds me of those dumb total junk win-printers.
...and much more.

At least Microchip has gotten this right on their MIPS32 platform. Would be nice to see NXP do the same.

@PaulStoffregen
So, I glazed over all the huge amounts of code of the t36 USB lib, and well, too bad you have to maintain a pipe. If that wasn't required, it could have fit better into UHS3. If there is an actual way to not require the whole pipe stuff, I'd really like to know how to do that. Perhaps I am misunderstanding the relationship too. UHS3 only needs to maintain some simple endpoint data, is this the same thing as these pipes?
 
EHCI is indeed complicated. Whether you consider that good or bad is a matter of perspective. If you value high performance for multiple devices running simultaneously or you want to write software with non-blocking APIs, EHCI has a lot to like.

For a simple synchronous & blocking design like UHS3, indeed EHCI is frustrating.

Is that code I submitted about a year ago still in UHS3? I believe it was pretty close. It did work for the tests I ran at the time. Maybe it can be made to work in all cases with some simple changes, like fully disabling the asynchronous schedule between operations?
 
EHCI is indeed complicated. Whether you consider that good or bad is a matter of perspective. If you value high performance for multiple devices running simultaneously or you want to write software with non-blocking APIs, EHCI has a lot to like.

For a simple synchronous & blocking design like UHS3, indeed EHCI is frustrating.

Right, Most bare-metal/non-RTOS stuff won't care if it blocks, because you are not typically running multiple threads of execution.

Is that code I submitted about a year ago still in UHS3? I believe it was pretty close. It did work for the tests I ran at the time. Maybe it can be made to work in all cases with some simple changes, like fully disabling the asynchronous schedule between operations?

Have not had the chance to check on it to be honest. There have been a ton of improvements since last year too. I'll have to revisit this again, and try to wrap my head around what I'm not understanding with the whole need to track pipes v.s. just popping arbitrary packets onto the serial interface engine one at a time.
 
@PaulStoffregen I revisited the code, and added some notes, mostly where you misunderstood some things.
Pull the source, update the submodule, take a look at it when you get the chance.
As far as hub support, I will tackle that later, as it involved handling TT's.
 
@PaulStoffregen Here is how close it is to working.

Code:
ISRbottom, usb_task_state: 0x3
PCI Vbus state changed to 2
USB host speed now 2
ISRbottom, usb_task_state: 0x3
ISRbottom, usb_task_state: 0x5
ISRbottom, usb_task_state: 0xC
ISRbottom, UHS_USB_HOST_STATE_CONFIGURING



Configuring: parent = 0, port = 1, speed = 2


Configuring PktSize 0x40,  rcode: 0x00, retries 0,
ctrlReqOpen
SetAddress, addr=0, ep=0
ep entry for interface 0 ep 0 max packet size = 64
SetAddress, speed=2, maxlen=64
SetAddress, parent=0, parent_port=1
ctrlReq2: left: 64, read:64, nbytes 64
ctrlReqRead left: 64, nbytes: 64, dataptr: 2002fe78
InTransfer 64
ctrlReq3: acceptBuffer sz 18 nbytes 64 left 46
PCI Vbus state changed to 2
USB host speed now 2
ctrlReqOpen
SetAddress, addr=0, ep=0
ep entry for interface 0 ep 0 max packet size = 64
SetAddress, speed=2, maxlen=64
SetAddress, parent=0, parent_port=1
0 retries.
DevDescr 2nd poll, bMaxPacketSize0:64
ctrlReqOpen
SetAddress, addr=1, ep=0
ep entry for interface 0 ep 0 max packet size = 64
SetAddress, speed=2, maxlen=64
SetAddress, parent=0, parent_port=1
ctrlReq2: left: 18, read:18, nbytes 18
ctrlReqRead left: 18, nbytes: 18, dataptr: 2002fe78
InTransfer 18
PCI Vbus state changed to 2
USB host speed now 2
ctrlReqOpen
SetAddress, addr=0, ep=0
ep entry for interface 0 ep 0 max packet size = 64
SetAddress, speed=2, maxlen=64
SetAddress, parent=0, parent_port=1
0 retries.
configs: 1
Good... one config on the device.
Code:
ctrlReqOpen
SetAddress, addr=1, ep=0
ep entry for interface 0 ep 0 max packet size = 64
SetAddress, speed=2, maxlen=64
SetAddress, parent=0, parent_port=1
ctrlReq2: left: 9, read:9, nbytes 9
ctrlReqRead left: 9, nbytes: 9, dataptr: 2002feb8
InTransfer 9
CONFIGURATION: 0, bNumInterfaces 1, wTotalLength 39
ctrlReqOpen
SetAddress, addr=1, ep=0
ep entry for interface 0 ep 0 max packet size = 64
SetAddress, speed=2, maxlen=64
SetAddress, parent=0, parent_port=1
ctrlReqRead left: 39, nbytes: 39, dataptr: 2002fdf0
InTransfer 39
bLength: 9 bDescriptorType: 02
eating 8
bLength: 9 bDescriptorType: 04
INTERFACE DESCRIPTOR FOUND
Getting 3 endpoints
bLength: 7 bDescriptorType: 05
ENDPOINT DESCRIPTOR: 0
ENDPOINT DESCRIPTOR OK
eating 0
bLength: 7 bDescriptorType: 05
ENDPOINT DESCRIPTOR: 1
ENDPOINT DESCRIPTOR OK
eating 0
bLength: 7 bDescriptorType: 05
ENDPOINT DESCRIPTOR: 2
ENDPOINT DESCRIPTOR OK
eating 0
eating 1
ENDPOINT DESCRIPTORS FILLED
Good, correctly filled endpts
Code:
TestInterface VID:0718 PID:0065 Class:00 Subclass:00 Protocol 00
Interface data: Class:08 Subclass:06 Protocol 06, number of endpoints 3
Parent: 00, bAddress: 01
Driver 1 supports this interface
Driver 1 can be used for this interface
USB_INTERFACE END OF STREAM
ctrlReqOpen
SetAddress, addr=1, ep=0
ep entry for interface 0 ep 0 max packet size = 64
SetAddress, speed=2, maxlen=64
SetAddress, parent=0, parent_port=1
ctrlReq2: left: 9, read:9, nbytes 9
ctrlReqRead left: 9, nbytes: 9, dataptr: 2002feb8
InTransfer 9
CONFIGURATION: 1, bNumInterfaces 1, wTotalLength 39
Best configuration is 1, enumerating interfaces.
ctrlReqOpen
SetAddress, addr=1, ep=0
ep entry for interface 0 ep 0 max packet size = 64
SetAddress, speed=2, maxlen=64
SetAddress, parent=0, parent_port=1
ctrlReqRead left: 39, nbytes: 39, dataptr: 2002fdf0
InTransfer 39
bLength: 9 bDescriptorType: 02
eating 8
bLength: 9 bDescriptorType: 04
INTERFACE DESCRIPTOR FOUND
Getting 3 endpoints
bLength: 7 bDescriptorType: 05
ENDPOINT DESCRIPTOR: 0
ENDPOINT DESCRIPTOR OK
eating 0
bLength: 7 bDescriptorType: 05
ENDPOINT DESCRIPTOR: 1
ENDPOINT DESCRIPTOR OK
eating 0
bLength: 7 bDescriptorType: 05
ENDPOINT DESCRIPTOR: 2
ENDPOINT DESCRIPTOR OK
eating 0
eating 1
ENDPOINT DESCRIPTORS FILLED
AttemptConfig: parent = 0, port = 1
Driver 1 supports this interface
Interface Configured
Good, correctly associated driver!!
Code:
ctrlReqOpen
SetAddress, addr=1, ep=0
ep entry for interface 0 ep 0 max packet size = 64
SetAddress, speed=2, maxlen=64
SetAddress, parent=0, parent_port=1
Driver 0 @ 00 Skipped
Driver 1 @ 01 Initialize
ctrlReqOpen
SetAddress, addr=1, ep=0
ep entry for interface 5 ep 0 max packet size = 64
SetAddress, speed=2, maxlen=64
SetAddress, parent=0, parent_port=1
ctrlReq2: left: 1, read:1, nbytes 1
ctrlReqRead left: 1, nbytes: 1, dataptr: 1fff25e4
InTransfer 1
outTransfer: addr: 0x01 ep: 0x02 nbytes: 0x001f data: 0x0x2002fd88
SetAddress, addr=1, ep=2
Ok, now this is where it falls apart.
Code:
ep entry for interface 42 ep 2 max packet size = 0    [B]pep->bIface corrupted[/B]
SetAddress, speed=2, maxlen=0
SetAddress, parent=0, parent_port=1
outTransfer: SetAddress 0x00
SetAddress, addr=1, ep=1
ep entry for interface 208 ep 1 max packet size = 0     [B]pep->bIface corrupted[/B]
SetAddress, speed=2, maxlen=0
SetAddress, parent=0, parent_port=1
InTransfer 13
--- frozen, until I unplug thumb drive, because it failed to init :)
 
Do you want me to try to write the OutTransfer() function?

From "Class:08 Subclass:06 Protocol 06", I'm guessing you're testing with a USB flash drive or hard drive? I have several random ones here. Just use any? Can you can give me the .ino example file, so I'm testing with the same code?
 
I'll be pushing the example soon.
It will be in
Code:
libraries/UHS_FS/examples/UHS_KINETIS_EHCI/UHS_FS_NEW_DEMO
Right now I am fixing address creation, as it has always been broken.
Once fixed you will be able to determine hub parent and port # properly just from the destination address.
 
If you want to write OutTransfer, I believe the code should look very similar to InTransfer, except you would use 0 instead of 1 in the 3rd input to init_qTD().

in other words, change this:

Code:
        init_qTD(data, *nbytesptr, 1, pep->bmRcvToggle, false);

to perhaps something like this:

Code:
        init_qTD(data, nbytes, 0, pep->bmRcvToggle, false);

and delete the (probably buggy anyway) line which tries to read the number of bytes actually sent from the status register.
 
So this would be my first guess...

Code:
uint8_t UHS_NI UHS_KINETIS_EHCI::OutTransfer(UHS_EpInfo *pep, uint16_t nak_limit, uint16_t nbytes, uint8_t *data) {
        HOST_DUBUG("OutTransfer %d\n", nbytes);
        init_qTD(data, nbytes, 0, pep->bmRcvToggle, false);
        uint8_t rcode = dispatchPkt(0, 0, nak_limit);
        uint32_t status = qTD.transferResults;
        pep->bmRcvToggle = status >> 31;
        return rcode;
}
 
I'm looking at this now. Seems there are 2 issues.

1: Somehow the endpoint's maxPktSize field is zero. Obviously we can't send an OUT packet if we're not allowed to have any bytes in the packet!

2: OUT transfers at 480 Mbit/sec use a special ping protocol. At 12 & 1.5 Mbit/sec, when a device isn't ready it answers NAK. But at high speed, the protocol is more complex. So far, dispatchPkt() does not know how to handle the case where the device responds with a NYET token, and treats it like an error.

I'll try to do something with #2.

On #1, for now I've got a horrible hack that just guesses how many bytes we're allowed if maxPktSize is zero.
 
Back
Top