Teensy with mini USB host shield (chineese)

Status
Not open for further replies.
R

Rafal_Typiak

Member
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

Beznazwy-1.png
 
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_Peripheral_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/2016081...tsathome.com/arduino_usb_host_shield_projects
and
https://web.archive.org/web/2015050...itsathome.com/chome_downloads/UHS_mini_10.pdf

It's not impossible somebody has sold a USB host shield with some other IC on the thing.
 
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 UT89srLXWRXXXagOFbX8.jpg
THE ORIGINAL uhm11_manual.jpg
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' :D

Cheers,
Rafał
 
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.com/en/ds/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.
 
but I’m encountering problems with them....No response from the controller....Maybe there’s something I did wrong with the wiring?
Click to expand...
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

DuinoFun UHS mini v2.0 Aug-16-2014 Mistake.png
 
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.

Rafal_Typiak said:
Hello,
View attachment 10292
Click to expand...


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 ;)
 
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.
 
Tnx, I'll check that this evening ...

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

MAX3421E Datasheet said:
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.
Click to expand...

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)
 
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.
 
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.
 
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.
 
KurtE said:
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.
Click to expand...

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.

IMG_20171115_204803.jpg

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;

ProMiniPinout.png


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:
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.
 
There's an attached image of my set-up in my post, but I'll add it here in case it doesn't show:

attachment.php



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.
 
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.
 
GremlinWrangler said:
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.
Click to expand...

The original board was made for the 3.3v Pro Mini, so the library should work just fine on 8MHz.

GremlinWrangler said:
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.
Click to expand...

I will verify all pin connections up to the MAX chip this evening (CET).
 
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.
 
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...
 
KurtE said:
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.
Click to expand...

I haven't tried the small shield with my UNO; will do that asap, as I have another unused small shield! Good idea!

KurtE said:
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
Click to expand...

Yes, I did, but that's with the original board instead of my cheap clone.

KurtE said:
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...
Click to expand...

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!
 
Ok, I tried three things tonight:

1. Hook up my spare shield to my UNO

pasted_045f.png


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 ...
 
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. :confused:
 
Spitko said:
MAX_RST is floating
Click to expand...

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.
 
Status
Not open for further replies.
Back
Top