Forum Rule: Always post complete source code & details to reproduce any issue!
Page 3 of 3 FirstFirst 1 2 3
Results 51 to 65 of 65

Thread: Teensy 3.6 USB Host support

  1. #51
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    19,005
    On the zero length max packet size, maybe this in UHS_address.h could be an issue:

    Code:
    struct UHS_EpInfo {
            uint8_t epAddr; // Endpoint address
            uint8_t bIface;
            uint8_t maxPktSize; // Maximum packet size
    At 12 Mbit/sec, only isochronous is allowed to be more than 64 bytes, so uint8_t is plenty for the endpoint's maximum size.

    But at 480 Mbit/sec, bulk endpoints can have max size up to 512 bytes. Most USB mass storage devices do use 512. This probably need to be a uint16_t to support usage of bulk endpoints at 480 Mbit/sec.

  2. #52
    Senior Member xxxajk's Avatar
    Join Date
    Nov 2013
    Location
    Buffalo, NY USA
    Posts
    489
    After I figure out why the PID sequence is wrong for every packet, this will work.

  3. #53
    Senior Member xxxajk's Avatar
    Join Date
    Nov 2013
    Location
    Buffalo, NY USA
    Posts
    489
    Actually, I see you fixed that. Awesome

  4. #54
    Senior Member xxxajk's Avatar
    Join Date
    Nov 2013
    Location
    Buffalo, NY USA
    Posts
    489
    @PaulStoffregen SUCCESS!!!

    After a few things fixed...

    Code:
    USB HOST READY.
    No media. Waiting to mount /
    / mounted.
    Removing '/HeLlO.tXt' file... completed with 4
    
    Starting Write test...
    File opened OK, fd = 1
    Wrote 19 bytes, File closed result = 0.
    
    Starting Read test...
    File opened OK, fd = 1, displaying contents...
    ]-[ello \/\/orld!
    
    Read completed, last read result = -1 (20), file close result = 0.
    Testing rename
    file rename result = 0.
    
    Removing '/1MB.bin' file... completed with 0
    1MB write timing test  2048 writes, (0), (0),  774 ms (1 sec)
    completed with 0
    1MB read timing test 2048 reads, (20),  770 ms (1 sec)
    completed with 0
    Directory of '/'
    -rw--a      1048576 2019-01-14 04:18:58 1MB.bin
    -rw--a           19 2019-01-14 04:18:58 newtest.txt
    1039613952 bytes available on disk.
    
    Flushing caches...
    Remove and insert media...
    Thanks so much! There are a few things to do now to optimize it.

    But first, fix up the nasty hub problems.

  5. #55
    Senior Member xxxajk's Avatar
    Join Date
    Nov 2013
    Location
    Buffalo, NY USA
    Posts
    489
    Quote Originally Posted by PaulStoffregen View Post
    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!
    Fixed. This was a holdover from UHS2.
    Quote Originally Posted by PaulStoffregen View Post
    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.
    NYET as a NAK is OK. This is how you would provide a timeout.

    After NAK counts (NYET in this case) you bail out with NAK error status, and the drivers know what to do.
    That is what the bmNakPower field is for. It is a power of 2.

    Code:
    /* NAK powers. To save space in endpoint data structure, amount of retries before giving up and returning 0x4 is stored in */
    /* bmNakPower as a power of 2. The actual nak_limit is then calculated as nak_limit = ( 2^bmNakPower - 1) */
    #define UHS_USB_NAK_MAX_POWER               15      // NAK binary order maximum value
    #define UHS_USB_NAK_DEFAULT                 14      // default 32K-1 NAKs before giving up
    #define UHS_USB_NAK_NOWAIT                  1       // Single NAK stops transfer
    #define UHS_USB_NAK_NONAK                   0       // Do not count NAKs, stop retrying after USB Timeout. Try not to use this.
    If USB Timeout isn't supported, just use UHS_USB_NAK_MAX_POWER.

  6. #56
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    19,005
    Glad it's starting to work now.

    On an unrelated matter... I hope at some point you'll consider adding library.properties files and migrate to a structure that can be used by Arduino's library manager. Requiring manual installation of the libraries, especially with such an unusual arrangement of files & folders, really limits growing your user base.

  7. #57
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    19,005
    On NYET, my understanding it is means the same as ACK, but then on the next OUT transfer you're supposed to do the PING protocol until you get an ACK.

    But maybe treating NYET as ACK (as the code is doing now) can work with most devices? I only tested with 1 memory stick, and I only looked at a small part of the packet capture on my protocol analyzer. It seemed like the delay of doing other stuff was plenty. The (admittedly idle) question I have is whether there are USB devices that would do something "bad" if you send another OUT packet when they're in the ping state and not yet ready for more data. I would hope they would send NAK. But there's a discussion in the USB2 spec about ways to design devices that *never* NAK on OUT due to the ping protocol. The spec seems very clear that hosts must send PING after hearing NYET, and the normal (or "bloated") way of using EHCI always does this automatically (the needed state is retained in the QH struct for each endpoint's pipe)... so it seems plausible there could be USB2 devices that behave badly upon receiving another OUT when the host was supposed to send PING.

  8. #58
    Senior Member xxxajk's Avatar
    Join Date
    Nov 2013
    Location
    Buffalo, NY USA
    Posts
    489
    Can we just issue a ping packet if NYET is set?
    Wouldn't that fulfill the requirement? Or could it cause a stall?
    I'll see if there is a compact way to implement some state data in the epInfo structure if all else is doomed.
    Low/full speed drivers don't need to track, so I could perhaps put in a conditional to save space for those.

  9. #59
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    19,005
    I'd just make a point to test with more devices. Who knows, maybe most or all real USB devices will be able to handle getting another OUT when you should have used PING? Or maybe all the extra software overhead of turning the async schedule on/off and rewriting the QH & qTD structs will be enough delay in most cases?

  10. #60
    Senior Member xxxajk's Avatar
    Join Date
    Nov 2013
    Location
    Buffalo, NY USA
    Posts
    489
    Got an idea... shrink nak by 1 bit, give you a flag. MAX NAK getting hit usually indicates some other issue anyway.
    That way, you can check the flag, ping proto (perhaps use nak max as wait) and then dispatch.
    I'll push this in a few minutes.

  11. #61
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    19,005
    But if you do find a device that misbehaves (something other than NAK) when it's in the ping state you send another OUT, then you'll need to add a way to store whether each endpoint is in the ping state. Maybe a uint16_t bitmask in the UHS_KINETIS_EHCI class could do it, if you want to avoid burdening the rest of your USB stack with this detail that only applies at 480 Mbit/sec. You maybe you'd prefer it as a boolean in the UHS_EpInfo?

    However you decide, just ping me (ok, bad pun) when you've added the way to store this state and I'll make a patch for SetAddress() to init the QH struct so the EHCI hardware does the rest.

  12. #62
    Senior Member xxxajk's Avatar
    Join Date
    Nov 2013
    Location
    Buffalo, NY USA
    Posts
    489
    Pushed.
    pep->bmNeedPing can be used. It defaults to 0 (no)

  13. #63
    Senior Member xxxajk's Avatar
    Join Date
    Nov 2013
    Location
    Buffalo, NY USA
    Posts
    489
    On the semi-related note, library.properties might make things a bit more difficult, because it is a collection of libraries... unless it can support dependencies, of course...
    I'll look into it.

  14. #64
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    19,005
    I've sent another pull request to add the ping protocol.

    https://github.com/felis/UHS30/pull/42

    Need to return my attention to the T4 beta now. Hopefully this puts UHS3 in pretty good shape for EHCI support.

  15. #65
    Senior Member xxxajk's Avatar
    Join Date
    Nov 2013
    Location
    Buffalo, NY USA
    Posts
    489
    Should! Glad you found my intentional compiler error to give you a hint.
    I'll go through and should be able to clean up the remaining items later tonight.
    Thank you very much for taking some time out from your busy schedule.
    As always, you rock!
    Yes, I tell others how awesome your support is, and always recommend your products.
    Yet another testament to you supporting "your own dog food", unlike so many other large greedy companies.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •