AStar Micro and USB

Is there something about the AStar Micro’s USB port that would be worth knowing? I seem to be able to get it only partially working. Here is my situation:

I’ve written code so that my Android device can talk to an Arduino (or compatible) device over USB.

It works 100% for several boards I have including Arduino Uno, OSEPP Nano, and Node MCU. I can read and write to the device. I am using the following library: https://github.com/mik3y/usb-serial-for-android and I have the AStar configured to use the CdcAcmSerialDriver

Now with the AStar, I am able to read incoming messages (I know because it responds to commands I pass it such as turn LED on/off, etc.) but when I try to write data to its port, I never seem to receive anything at the Android. Whats even weirder is that it also seems to prefer only specific cables. One cable that I’ve used on all the other boards (and again seems to be working 100% with them) does not work at all with the AStar. Neither send nor receive nor even detect that its plugged in. But when I use a different cable I do get affirmative detection and I do get data travelling in one direction.

And yes I am using OTG adapters and specialized OTG USB cables.

Any ideas what I might do to get the AStar to work?
Maybe it’s not fully compliant with the CdcAcmSerialDriver? What driver would it be compliant with? Is there a white paper on the specifications of the AStar’s port?

Some other info:
I don’t have any problems at all using the AStar with the Arduino SDK. It sends and receives all data packets as expected.

Hello.

When you load a sketch onto the A-Star 32U4 and run it, the sketch is in charge of the USB interface, so the USB interface will behave according to the code in that sketch. A-Star 32U4 users typically use the Arduino IDE to generate their sketches, and the Arduino IDE uses the USB code shown here:

The files most relevant to the USB interface are USBCore.cpp, USBCore.h, CDC.cpp, and CDC.h.

If you are sending data from the A-Star to the USB host using functions on the Serial object like Serial.println, one thing to note is that those functions only send data to the host if the host has asserted the DTR or RTS control signals. You can see how this is implemented by looking at Serial_::write in CDC.cpp.

If you have not yet added code to your Android app to assert DTR or RTS, I recommend doing that.

One way to tell whether those signals were asserted correctly from the A-Star’s perspective is to convert the Serial object to a bool with some code like this:

if (Serial)
{
  // Virtual serial port is considered to be open.
}

The code for that conversion can be found in CDC.cpp, in the Serial_::operator bool() function.

I am not sure why the A-Star would not work with one of your cables, but it sounds like you were able to find another cable that works.

–David

Ah yes, Setting DTR was the trick. Now the AStar is sending me data! I’ve never had to worry about setting that before. Thanks.

As far as the cable that didn’t work, it was a power issue. It seems I can’t power the board thru that USB cable, but if I supply a voltage to it, I’m good to go. I just added a regulator into the design. Still not clear on why that would be so, though? The other cable I have supplies voltage to it. And this cable is able to supply enough voltage to the NodeMCU board. Oh well, I have a solution to both problems, now. Thanks for the assistance.

I am glad you were able to get things working. If you want to look into why that USB cable cannot power the A-Star 32U4 Micro, you might try disconnecting the A-Star from everything except USB and then measuring the voltage on the A-Star’s VBUS node with respect to the A-Star’s GND. The easiest way to probe VBUS would be to find the large green component (resettable PTC fuse) on the top side of the board near the USB connector, and then probe the end of the component closer to the USB connector.

–David