USB Host Shield 2 library ACM terminal example with Arduino DUE

Official Hardware Mega Due
1

We would like to use Arduino Due as a host for a ACM CDC device, we have purchased the USB Host Shield and are using the USB Host Shield 2.0 Library.

We are trying to run the example "acm_terminal" to send and receive Serial commands from the DUE. The example worked with arduino UNO without any problems, but when we change it to arduino DUE it no longer works. The board_qc example is working for both the UNO and DUE.

We believe that the Acm.isReady is never changing to True.

We have looked at some other posts with similar problems (https://github.com/felis/USB_Host_Shield_2.0/issues/295) and have tried commenting lines 159 and 160 of cdcacm.cpp as well as changing lines 134 to 142 in the same file, to change the protocol number to 0.

Additionally we have tried using GetLinesCoding in the setup of the acm terminal as mentioned in another post (https://forum.arduino.cc/t/usb-host-shield-cannot-receive-data-from-cdc-acm-device/1152002)

2

In general, 5V shields like the USB host shield cannot be used on boards with 3.3V logic levels such as Due. Due is not 5V tolerant.

Have you considered newer boards that work with the Arduino IDE?

PJRC Teensy 4.1 has built-in USB host and its own USB host library.

Adafruit makes small MAX3421E (the brains of the UHS) boards for their feather series of boards.

3

Since we have been able to use the board_qc example succesfully with the DUE we do not believe that this is the problem. The manual for our sheild also indicates that it is compatible with the DUE and other 3.3v logic boards.

4

Since we have been able to use the board_qc example succesfully with the DUE we do not believe that this is the problem.

Wrong voltage may work for a while. It is a different problem from the CDC ACM failure.

The manual for our sheild also indicates that it is compatible with the DUE and other 3.3v logic boards.

I think this is only true by removing the 3.3V to 5V level shifter. I have never seen the 3.3V variant for sale.

5

In the documentation for the Library (https://github.com/felis/USB_Host_Shield_2.0), under "Boards" it is mentioned that the Arduino Due is a supported board. Also, in the Hardware Manual (http://tet.pub.ro/Documente/Proiect%20final/Documentatie/Shield%20USB%20Host/USB%20Host%20Shield%20Hardware%20Manual%20%C2%AB%20Circuits@Home.pdf), it is mentioned that "The standard shield works with 3.3V only arduino boards just fine".
Besides the board_qc example, we have also attempted the USB_desc example, and it also worked, so it seems like the issue is related to the acm example. Is it possible that the code for cdcacm.cpp is compatible with UNO and would require some alteration for it to work with DUE?

6

You cna choose to believe your doc or use a multimeter to measure 5V going into Due pins. Or take a look at the board schem.

As for the CDC ACM problem I have no idea. The UHS lib is very complex so when something goes wrong it takes too much time to debug. I usually side step problems like this by switching to a different USB host solution like Teensy 4.1 or raspberry pi.

You could search the UHS github issues (all issues, not just open) to see someone has run into the same problem.

7

I see you liked my username.

USB host functionality, as I found out in the post you linked, is not trivial to implement. The Arduino USB host library should really not be expected to work with anything other than the few supported devices listed. (Just read through the comments in the Usb.cpp source file in the library) It is a great starting point for making your own drivers for unsupported USB devices, but is not complete enough to be plug and play with any random device.

If you really want it to work on the DUE, it looks like you are, as I was, on your own. You have the time digital converter to test with, we don't, which makes debugging from our end tough.

All I can suggest is the path I took, which was adding a bunch of debug print statements in the USB host library, and a logic analyzer to see what is happening on the actual USB bus.

Since you have it working on the UNO, comparing logic analyzer traces from the working system to the non-working traces from the DUE should give you good direction towards the problem. If the traces are different, you can focus on finding the reason for the discrepancy. I found it impossible to debug without actually being able to see what was happening on the physical USB interface.

There is a lot of enumeration happening before ACM.isReady becomes true. All of this happens in the library and not in the example sketches. I tried using the solution I found in the thread you linked on another logger of exactly the same model, and it didn't work. Hooking the logic analyzer back up showed that this logger was only sending a few bytes of its USB descriptor when requested by the USB host library, causing the enumeration to fail. This turned out to be a bug in the firmware of that specific logger, causing it to only send a portion of its descriptor when set to USB address 0. I just hardcoded the descriptor into my code since the device was to be permanently connected to the logger. My point being, I never would have figured out the issue without being able to see the actual packets on the USB bus.

8

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.