Forum Rule: Always post complete source code & details to reproduce any issue!
Page 1 of 2 1 2 LastLast
Results 1 to 25 of 27

Thread: Teensy with mini USB host shield (chineese)

  1. #1

    Teensy with mini USB host shield (chineese)

    Hello,
    I'm using my Teensies 3.1 with USB Host shields from Sparkfun. I've found them to be a pain but still - they work. So that's that. The problem I have is that they're big and so I've set out to find a smaller factor USB host shield. And wouldn't you know it. I did. On a Chinese store. They seem to be a rip off of other USB boards for Arduino Pro mini. Iíve decided to give it a try but Iím encountering problems with them. The thing which I want to connect to teensy is a PS4 controller.
    Iíve replicated the connections from the Sparkfunís shield and when running USB Host shield Library 2.0 Iím getting
    ďPS4USB Wireless Receiver Library StartedĒ
    message on Serial and thatís it. No response from the controller. Iíve connected the external 5V power to the USB from Teensy (cut the Vbus track first) and still nothing. Maybe thereís something I did wrong with the wiring?
    I was wondering if someone smarter than me could take a look at it and maybe point me in the right direction.
    P.s.
    The controller works, as Iíve connected it to my older setup.
    Best regards,
    Rafał Typiak

    Click image for larger version. 

Name:	Beznazwy-1.png 
Views:	1570 
Size:	214.0 KB 
ID:	10292

  2. #2
    Senior Member
    Join Date
    Apr 2013
    Posts
    1,762
    A link to the library would be good. Assume the only 'docs' available from the ebay site is the picture there?


    Fault finding this will involve getting some basic familiarty with SPI
    first page or so of here would be the bits:
    https://en.wikipedia.org/wiki/Serial..._Interface_Bus
    First place would be to make sure all the power pins have the right voltages.
    Suggested next step is to look at what signals are supposed to be where. So sck is on pin 13, so the LED on the teensy should flash when it's talking either way.
    Chip select (SS) should be going low whenever SCK is active (use a scope, good meter or just add an LED)
    D11 and D12 (data in/data out) are a bit trickier but there should be data to the sheild, then data from it. In this case seeing if any data is coming from the board would be useful (responds to Teensy commands).
    The labeling of D11/D12 and PCB markings /MOSI/MISO do not look they conform to Arduino standard, so it may be a case they are swapped but proving that is a bit tricky.
    Reading the library would be required to know if the INT pin is supposed to do anything.

    This is of course the price to pay for buying cheap ofg ebay - you get to learn a lot more about how it works.

    You don't have a photo of the top of the board, have you done a basic trace to confirm the IC and PCB look at least something like the info at:
    https://web.archive.org/web/20160812...hield_projects
    and
    https://web.archive.org/web/20150503...HS_mini_10.pdf

    It's not impossible somebody has sold a USB host shield with some other IC on the thing.

  3. #3
    The library is located here:
    https://github.com/felis/USB_Host_Shield_2.0
    Your assumption is correct. That is the only source of info I have. Looking at it in comparison with the original board there are some differences.
    MY BOARD Click image for larger version. 

Name:	UT89srLXWRXXXagOFbX8.jpg 
Views:	1960 
Size:	76.7 KB 
ID:	10302
    THE ORIGINAL Click image for larger version. 

Name:	uhm11_manual.jpg 
Views:	738 
Size:	163.9 KB 
ID:	10303
    the biggest problem is with finding GND (I'm guessing it's in the same position as with the original)
    As for the pin alignment - I have yet to trace each pin though. At first I was thinking of doing a little trial and error configs but your tracing suggestions seems more 'appropriate'

    Cheers,
    Rafał

  4. #4
    Senior Member
    Join Date
    Apr 2013
    Posts
    1,762
    Re Gnd, should be on the shell of the USB socket as a starting point for what they have done here

    Looks like the boards are using the same core IC, and look to be wired in similar ways, so that's a good start.

    The data sheet for the IC is
    https://datasheets.maximintegrated.c...s/MAX3421E.pdf, page 10 shows the pinouts, unfortunately rotated 90 degrees from the PCBs, but looking at the reset pin, which seems to be the same place for both PCBs it looks like the traces that I can see are going sensible places (USB D+/D-, GPIO). Whats not clear is how those critical SPI pins are connected up. Chip select is visible, but MISO/MOISO are running under the board so harder to work with photos. Suggest wiring up up how the 'instructions' say and with power off try to measure resistance from Teensy Pin 11 (data out/MasterOutSlaveIn) to the IC pin 16 (left most of top row in the photo, two left of SS/chip select) then go pin 12 teesny (Din/MasterInSlaveOut) from pin 15 (second from left on top row).

    That gets you an end to end measure of the two most likely contenders for trouble, given there is different labels shown there.

  5. #5
    Junior Member
    Join Date
    Jul 2017
    Posts
    1
    but I’m encountering problems with them....No response from the controller....Maybe there’s something I did wrong with the wiring?
    i successfully connected this shield (DuinoFun UHS mini v2.0 Aug. 16,2014) to Teensy 3.2.

    The main problem with it is that they have been mistaken with MOSI<->CLK pins naming on backward board side

    connection:
    INT - pin9
    SS - pin10
    MOSI (BE AWAIRE! on backward side it named as "CLK") - pin11
    MISO - pin12
    SCK (BE AWAIRE! on backward side it named as "MOSI") - pin13

    Click image for larger version. 

Name:	DuinoFun UHS mini v2.0 Aug-16-2014 Mistake.png 
Views:	419 
Size:	240.5 KB 
ID:	10950

  6. #6
    Thank you both @GremlinWrangler and @SergeyM. Your input has helped me to get mine up and running! Yay!

    Cheers,
    Rafał

  7. #7
    Junior Member MrHaroldA's Avatar
    Join Date
    Nov 2017
    Posts
    10
    Hey Guys, I'm Harold and I'm new here

    I've spent the greater part of the evening trying to get my Chinese mini USB shield to talk with my Arduino Pro Mini 3.3v. I already swapped the misplaced pin 11 and 13, but I still don't get an answer from the shield.

    Rafal_Typiak's image suggests way more connections, but VCC and VBUS are connected on the board, MAX_RST should probably be attached the the Arduino's reset, and D7 is defined as D9 in the library.

    Quote Originally Posted by Rafal_Typiak View Post
    Hello,
    Click image for larger version. 

Name:	Beznazwy-1.png 
Views:	1570 
Size:	214.0 KB 
ID:	10292

    So, besides swapping pin 11 and 13, what actions should I undertake to get this shield running on my Arduino Pro Mini*?


    * Yes, I know it's not a Teensy, but this thread is the only one on this very topic

  8. #8
    Senior Member
    Join Date
    Apr 2013
    Posts
    1,762
    If you have a scope checking to clock, data in and data out would be an option. If you don't wiring a reasonably high value resistor with an LED (1k) will give you some activity markers. While doing that see above for my notes on tracing from the PCB pins to the actual chip pins which will sort out any other PCB marking issues.

    When all is good you should be seeing activity on chip select and clock at least. Bonus if MOSI to the PCB is working and even better if MISO back to the Mini is doing stuff. Also, might be worth plugging in something like a keyboard and seeing if the capslock etc LEDs flick up (or even better, toggle like the should) which would tell you something about what the USB side is up to.

  9. #9
    Junior Member MrHaroldA's Avatar
    Join Date
    Nov 2017
    Posts
    10
    Tnx, I'll check that this evening ...

    I also dug a little more into the reset pin and the MAX chip:

    Quote Originally Posted by MAX3421E Datasheet
    Drive RES low to put the MAX3421E into a chip reset. A
    chip reset sets all registers to their default states,
    except for PINCTL (R17), USBCTL (R15), and SPI logic.
    All FIFO contents are unknown during chip reset. Bring
    the MAX3421E out of chip reset by driving RES high.

    The RES pulse width can be as short as 200ns. See the
    Device Reset section for a description of the resets
    available on the MAX3421E.
    The MAX_RESET is now directly attached to the Arduino's reset pin, but is that pin always high (3.3v)? (I don't have access to my Arduino now)

  10. #10
    Senior Member
    Join Date
    Apr 2013
    Posts
    1,762
    The reset pin is probably not a really helpful place for it since that will be going high/low from the programing process. Check the board, quite possibly it's configured to pull it high itself and it can be left alone unless the library specifically needs to be able to reset it, which I was not finding in a sweep through the code just now. Also, are you bringing up the Arduino terminal window? The examples have code that halts until it's up, though I think that's not being done for the Mini.

  11. #11
    Junior Member MrHaroldA's Avatar
    Join Date
    Nov 2017
    Posts
    10
    I've got an UNO with USB shield working perfectly, and I did check the terminal output.

    The Mini halts in the initialization of the USB layer. It returns -1 and halts in the infinite while loop.

  12. #12
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    3,534
    As there is no Teensy involved here, you might want to look up on some other forums like Arduino or Sparkfun to see if anyone has suggestions.

    And in cases like this it always helps to give additional information, like a photo showing your wiring. Otherwise people are just guessing.

    Likewise as per forum rules (in red at top of every page), It would help to see what code you are running and likewise a link to what libraries you are using.

  13. #13
    Junior Member MrHaroldA's Avatar
    Join Date
    Nov 2017
    Posts
    10
    Quote Originally Posted by KurtE View Post
    As there is no Teensy involved here, you might want to look up on some other forums like Arduino or Sparkfun to see if anyone has suggestions.

    And in cases like this it always helps to give additional information, like a photo showing your wiring. Otherwise people are just guessing.

    Likewise as per forum rules (in red at top of every page), It would help to see what code you are running and likewise a link to what libraries you are using.
    You are absolutely right, my apologies.

    I just wrote and released a library to connect with a Boss MS-3 multi-effects processor for guitar and bass. That library depends on the USB Host Shield 2.0 library and extends the USBH_MIDI class.

    I have a fully working set-up with an Arduino UNO and full-sized USB shield, but I want to downsize my set-up to implement it in a small foot controller. So I bought an Arduino Pro Mini running on 3.3v and an USB shield that should be compatible with the Pro Mini. Both cheap Chinese clones. I want to get my library running on a Teensy too, but I haven't ventured into that world yet.

    Anyway, when I start the Usb layer I never get passed Usb.Init().

    Code:
    if (Usb.Init() == -1) {
        MS3_DEBUGLN(F("*** USB Init error"));
        while (true);
    }
    I Googled into this thread where it was pointed out that the MOSI and CLK were swapped on the board, so I swapped the pins on my shield too by pulling the pins from the header and added external jumper wires.

    Click image for larger version. 

Name:	IMG_20171115_204803.jpg 
Views:	1406 
Size:	109.2 KB 
ID:	12064

    There are no off-board components connected, except for the USB/FTDI interface to my PC.


    I then verified that the INT and SS pins are correctly set in the USB Shield library / UsbCore.h:

    Code:
    /* shield pins. First parameter - SS pin, second parameter - INT pin */
    typedef MAX3421e<P10, P9> MAX3421E;


    So my best guess is that INT, SS, MISO, MOSI and CLK are correctly connected and configured, but still the shield won't init. MAX_RST is also HIGH.


    Now, I understand that this isn't a Teensy, but I hoped your experience would give me that little pointer to get me coding again. I do apologise that I broke the rules.
    Last edited by MrHaroldA; 11-15-2017 at 08:44 PM.

  14. #14
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    3,534
    Hopefully someone can help: I do not have any of this hardware... May have a pro mini around here somewhere.

    But wonder you say it is the 3.3v version, If I am not mistaken this runs at 8mhz vs the UNO at 16mhz. Wonder if there is an issue running at 8mhz?
    Again as no picture of setup, make sure you have common ground.

  15. #15
    Junior Member MrHaroldA's Avatar
    Join Date
    Nov 2017
    Posts
    10
    There's an attached image of my set-up in my post, but I'll add it here in case it doesn't show:




    The 3.3v version is the only one supported, as all i/o should be on 3.3v and not 5. The shield for the UNO utilizes 74HC125D chips for the conversion from 5v to 3.3v, IIUC.

  16. #16
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    17,624
    Just curious, did you try asking the vendor who sold this shield for assistance?

  17. #17
    Junior Member MrHaroldA's Avatar
    Join Date
    Nov 2017
    Posts
    10
    Quote Originally Posted by PaulStoffregen View Post
    Just curious, did you try asking the vendor who sold this shield for assistance?
    I bought them here:
    Arduino Pro Mini: https://www.ebay.com/itm/272747908727
    USB Shield: https://www.ebay.com/itm/282471233037

    As you can see, this is a "dumb" reseller, of which I don't expect any assistance ... but I'll try anyway!

  18. #18
    Senior Member
    Join Date
    Apr 2013
    Posts
    1,762
    The lower clock speed could be making a number of differences, possibly as simple as timeouts being too short and needing a bump up or as complex as just plain not keeping up with the host board CPU, noting the Teensy work above was at much higher clock speeds. Would also still strongly suggest comparing the IC to arduino pinout since I don't think you actually confirmed the cross over of MOSI and clock on your PCB, remembering that multiple versions of this PCB have been cloned of each other and at least one of them must have got it right. A possible check is to run the classic blink on both this and your Uno and see if a multi meter shows pulsing 3.3V on pin 13 of the USB board chip on both cases (being able to compare makes a lot of things simpler). Fortunatly MOSI and clock are both inputs to the USB board so should not have done any harm.

  19. #19
    Junior Member MrHaroldA's Avatar
    Join Date
    Nov 2017
    Posts
    10
    Quote Originally Posted by GremlinWrangler View Post
    The lower clock speed could be making a number of differences, possibly as simple as timeouts being too short and needing a bump up or as complex as just plain not keeping up with the host board CPU, noting the Teensy work above was at much higher clock speeds.
    The original board was made for the 3.3v Pro Mini, so the library should work just fine on 8MHz.

    Quote Originally Posted by GremlinWrangler View Post
    Would also still strongly suggest comparing the IC to arduino pinout since I don't think you actually confirmed the cross over of MOSI and clock on your PCB, remembering that multiple versions of this PCB have been cloned of each other and at least one of them must have got it right. A possible check is to run the classic blink on both this and your Uno and see if a multi meter shows pulsing 3.3V on pin 13 of the USB board chip on both cases (being able to compare makes a lot of things simpler). Fortunatly MOSI and clock are both inputs to the USB board so should not have done any harm.
    I will verify all pin connections up to the MAX chip this evening (CET).

  20. #20
    Senior Member
    Join Date
    Apr 2013
    Posts
    1,762
    Will point out my yield for dud parts from Ebay sellers is between 5 and 10% so quite possible there is just something outright broken with this before you got it. My general advice is to make sure item one of whatever you get comes from someone who tests before shipping (actual electronic places) and only buy from the bottom of ebay stuff you can QC yourself such as against a known good unit (also means you can send a photo to seller of working and non working parts, which shortens the refund procrastination nicely). Still verifiying the pin connections will help, as will seeing if anything at all happens on the MISO line, noting the library times out. If the USB board doesn't respond in anyway to SPI traffic than it's dead in someway.

  21. #21
    Senior Member+ KurtE's Avatar
    Join Date
    Jan 2014
    Posts
    3,534
    I am not sure if you said you tried this board out with the UNO? Or only the larger USB adapter with the UNO. If it works with the UNO, you can then I believe configure the UNO to run at 8mhz and see if it still works. That would mostly remove the 8mhz issue from the equation.

    I don't know if you saw this writeup about using a Teensy 2.0 with the small USB adapter? https://www.pjrc.com/teensy/td_libs_USBHostShield.html

    In that write up they mentioned that the VR that outputs the 3.3v may not be enough for the USB... And they added a larger CAP near the USB...

  22. #22
    Junior Member MrHaroldA's Avatar
    Join Date
    Nov 2017
    Posts
    10
    Quote Originally Posted by KurtE View Post
    I am not sure if you said you tried this board out with the UNO? Or only the larger USB adapter with the UNO. If it works with the UNO, you can then I believe configure the UNO to run at 8mhz and see if it still works. That would mostly remove the 8mhz issue from the equation.
    I haven't tried the small shield with my UNO; will do that asap, as I have another unused small shield! Good idea!

    Quote Originally Posted by KurtE View Post
    I don't know if you saw this writeup about using a Teensy 2.0 with the small USB adapter? https://www.pjrc.com/teensy/td_libs_USBHostShield.html
    Yes, I did, but that's with the original board instead of my cheap clone.

    Quote Originally Posted by KurtE View Post
    In that write up they mentioned that the VR that outputs the 3.3v may not be enough for the USB... And they added a larger CAP near the USB...
    I did not plug anything into the USB HOST connector yet; I'll add sufficient filtering on the power supply anyway, tnx for the reminder!

  23. #23
    Junior Member MrHaroldA's Avatar
    Join Date
    Nov 2017
    Posts
    10
    Ok, I tried three things tonight:

    1. Hook up my spare shield to my UNO



    Result: the same usb init error.


    2. Trace the pins from the MAX3421E to the headers:

    1 - 14 SS
    2 - 16 MOSI
    3 - 15 MISO
    4 - 13 SCLK
    24 - 18 INT

    Wait, what?!? That's the same SPI pinout as my Arduino Pro Mini! So the pins line up, but the silkscreen is wrong ... and it also doesn't work like that


    3. Hook up the UNO again and use the traced wire positions: nothing.


    I'm calling it quits for tonight. I'm going to think this one over and maybe give it another try this weekend ...

  24. #24
    Junior Member
    Join Date
    Mar 2018
    Posts
    3
    Grabbed one of these a few days ago, and I've been bashing my head against the wall all night.

    I've got everything hooked up correctly (I think), but the QC check always gives
    Code:
    Circuits At Home 2011
    USB Host Shield Quality Control Routine
    Reading REVISION register... Die revision 03
    SPI long test. Transfers 1MB of data. Each dot is 64K
    Test failed.  Value written: 01 read: 00
    Unrecoverable error - test halted!!
    0x55 pattern is transmitted via SPI
    Press RESET to restart test
    What's weird is that I DO seem to be getting the correct Die revision, but the SPI test always pukes with 0s. I notice that the INT pin doesn't seem to actually matter to the failure state here (though touching MOSI, MISO, SCK, or SS will result in an invalid die revision).

    Is this thing toast, or am I missing something obvious?

    Teensy 3.2,
    INT: p9
    SS: p10
    MOSI: p11
    MISO: p12
    CLK: p13

    Also connected:
    +3v3, GND, VBUS (though disconnecting VBUS doesn't seem to make a difference)

    MAX_RST is floating, though connecting it to HIGH seems to cause the test to hang trying to get die revision. LOW or floating seem to have no effect.

    I also checked each pin with a scope.
    None are floating, and all appear to have data being sent across them. I can see SS asserts happening like one would expect, and CLK looks to be making clean looking bursts that line up with the MOSI spikes. On MISO I can capture a small packet that's likely our 03, and MOSI is full of data. I can't dig deeper into what the lib is doing since I lack a logic analyzer, but nothing looks horrifyingly incorrect. The only pin which doesn't do anything is INT, which is expected I think?

    It seems like this should work, but it doesn't.

  25. #25
    Junior Member MrHaroldA's Avatar
    Join Date
    Nov 2017
    Posts
    10
    Quote Originally Posted by Spitko View Post
    MAX_RST is floating
    Mine is connected to RST on my Arduino Pro Micro 3v3.

    And a update to my post above: I bought a new mini USB shield, and that one works out-of-the-box without any pin rewiring! On closer inspection, the 12MHz crystal looks damaged, so that might be the issue with the first shield.

Posting Permissions

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