Male Mini ttyACM problem

I’m using a Maple Mini clone from AliExpress and I’m having trouble with ttyACM connection:

First time I tested it it was not working until one day magically appeared.

Then, my hard disk died and now, after reintalling, I have no ttyACM again.

My system is Gentoo Linux (systemd, amd64 and true multilib), and different reports:

LSUSB ust after connecting (bootloader mode):

Bus 002 Device 004: ID 0489:d612 Foxconn / Hon Hai
Bus 002 Device 003: ID 054c:06e7 Sony Corp.
Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 006: ID 8087:07da Intel Corp.
Bus 001 Device 005: ID 26e1:c1a0
Bus 001 Device 004: ID 054c:06c2 Sony Corp.
Bus 001 Device 003: ID 1b96:0f00 N-Trig
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 003 Device 005: ID 15a2:0065 Freescale Semiconductor, Inc.
Bus 003 Device 004: ID 0489:d611 Foxconn / Hon Hai
[b]Bus 003 Device 013: ID 1eaf:0003 [/b] Bus 003 Device 002: ID 046d:c526 Logitech, Inc. Nano Receiver
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

I believe Roger is working on enhancing Linux support at the moment, meantime you might like to read this…

https://github.com/rogerclarkmelbourne/ … bootloader

.. as it may cast some light on your issue.

Thanks!

I’ve already checked all documentation, and I’m able to program my Maple. Everything is fine except for the ttyACM device.

The problem is here:

3) upload_router then waits while linux re-enumerated the device. /dev/ttyACM0 or /dev/ttyACM{whatever} automagically appears and if we look in lsusb, the device has changed from something like…

Bus 001 Device 114: ID 1eaf:0003

.. to ..

Bus 001 Device 115: ID 1eaf:0004

My maple doesn’t get enumerated after bootloader, no 1eaf:0004 device is shown.

I tested the environment ‘as is’ and it worked, now I changed upload_router and so on, perfect for uploading in all cases, but no ttyACM device in any case.

It’s driving me crazy, it’s the first time I face something similat after 20 years using Linux, 15 using Gentoo….

Well, ASAP I’ll try on my desktop PC, with same configuration, to see if it works there… Maybe an USB issue…

Have you tried to bring the mini into perpetual bootloader?
press reset while holding button, release reset and hold button about a few seconds, so the led stays blinking constantly.
http://leaflabs.com/docs/troubleshooting.html
This is not the perfect solution, but you can use it as first step for troubleshooting.

Also it’s a good point to insert a “Serial.begin(xxx)” into the test sketch, this was a workaround on mac (with the new bootloader I don’t have this problem anymore)
Further idea: Try out an USB hub.
Edit 3: OK, now I checked you problem (so I think): You can program the mini, but it doesn’t setup the serial connection. hmmm, ok:
(setup)
delay (2000);
Serial.begin(9600);
Maybe this helps for troubleshooting

edit 4 a complete test sketch:
byte x;
begin()
{
delay (2000);
Serial.begin(9600);
Serial.println(“Test”);
}
loop() {
x++;
Serial.print(“Value x: “);
Serial.println(x);
delay(200);
}

No luck. I added the delay to my old setup but still not shown:

void setup() {
delay (2000);
Serial.begin(9600);
while (Serial.available() < 1 )
{
Serial.write('a');
delay (1000);
}
Serial.println("Serial OK");
}


ok, then try it, as you said, on another PC, For further help, I think ahull is the linux “master” in this forum.

Hello again!

Seems to be my Intel ultrabook problem. Tested with same environment (copied viua SFTP) and works perfectly on Kavery (AMD) desktop:

[ 1998.970211] usb 7-4: USB disconnect, device number 3
[ 1999.532261] usb 7-4: new full-speed USB device number 4 using ohci-pci
[ 1999.683472] usb 7-4: New USB device found, idVendor=1eaf, idProduct=0003
[ 1999.683480] usb 7-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 1999.683484] usb 7-4: Product: Maple 003
[ 1999.683488] usb 7-4: Manufacturer: LeafLabs
[ 1999.683490] usb 7-4: SerialNumber: LLM 003
[ 2001.965794] usb 7-4: USB disconnect, device number 4
[ 2002.404511] usb 7-4: new full-speed USB device number 5 using ohci-pci
[ 2002.558625] usb 7-4: New USB device found, idVendor=1eaf, idProduct=0004
[ 2002.558634] usb 7-4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 2002.558638] usb 7-4: Product: Maple
[ 2002.558641] usb 7-4: Manufacturer: LeafLabs
[ 2002.603864] cdc_acm 7-4:1.0: ttyACM0: USB ACM device
[ 2002.604623] usbcore: registered new interface driver cdc_acm
[ 2002.604629] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters
[email protected] ~ $

From line “[ 2002.404511] usb 7-4: new full-speed USB device number 5 using ohci-pci” (included) is missing on my Intel. Maybe any issue with USB3 and USB1.1 hub (both cases, directly on USB3 and using 1.1 hub to ‘lower’ USB version).

Thanks again!

WTF!!!

Just tested in Intel after disconnecting all USB (well, only the mouse…) and started working!

[66010.953405] usb 3-2: new full-speed USB device number 28 using xhci_hcd
[66011.118299] usb 3-2: New USB device found, idVendor=1eaf, idProduct=0003
[66011.118307] usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[66011.118310] usb 3-2: Product: Maple 003
[66011.118314] usb 3-2: Manufacturer: LeafLabs
[66011.118317] usb 3-2: SerialNumber: LLM 003
[66013.565481] usb 3-2: USB disconnect, device number 28
[66013.848740] usb 3-2: new full-speed USB device number 29 using xhci_hcd
[66014.013987] usb 3-2: New USB device found, idVendor=1eaf, idProduct=0004
[66014.013992] usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[66014.013994] usb 3-2: Product: Maple
[66014.013996] usb 3-2: Manufacturer: LeafLabs
[66014.014138] usb 3-2: ep 0x82 – rounding interval to 1024 microframes, ep desc says 2040 microframes
[66014.014484] cdc_acm 3-2:1.0: ttyACM0: USB ACM device
VAIO naguissa #

THE X FILES…..

So you can(‘t) comprehend the failue/error in any way? Maybe this would help other Linux users….

Guys

As compiling Linux binaries on my Lubuntu 32 bit machine , also worked on another different machine running Mint 64 bit. I may as well build and include the latest DFU util

Well unless it needs system libs to be installed.

My Mint 64 bit doesn’t have DFU util on it at the moment, so it would be a good test.

The only issue I have on Linux is permissions on the USB devices.

I did try the stuff about adding my user to the dialout group, but that didn’t work on its own.

So I think its easier just to use. sudo chown 777 On whatever device you need to access
Albeit this is possibly a security issue, but if you are worried about people sending data to your USB port without you knowing, I think you need to wear a tin foil hat for extra protection

Edit.

Sorry.
I thought this was an upload issue, but it sounds like a USB serial issue

I think what people don’t realise is that the USB serial code is in the sketch

So if there is an issue with the sketch or the upload of the sketch etc

You don’t see the USB serial device at all

The easiest way I have found to get things working again, is to put the board into perpetual bootloader mode, upload an empty sketch and then manually reset the maple mini

Normally the USB serial device should then appear.

Just a thought about the permissions on the /dev/ttyACM* devices. If you look at the current permissions with ls -l that will give you a clue which group you need to add your user to.

ls -l /dev/ttyA*
crw-rw—- 1 root dialout 166, 0 Apr 30 19:08 /dev/ttyACM0
crw-rw—- 1 root dialout 166, 1 Apr 30 19:08 /dev/ttyACM1
crw-rw—- 1 root dialout 166, 2 Apr 30 19:08 /dev/ttyACM2

In my case they are read/writeable by users in the dialout group, but for some distributions and with some udev rules, this may be different.

@ahull,

I think that was the situation for me, but adding myself to the dialout group still didn’t

I’ll need to double check to see quite whats going on

I also noticed that if I leave the serial monitor open and connected to /dev/ttyACM1 while flashing the board re-appears as /dev/ttyACM2
Have a look in dmesg and/or syslog to see if there are any mode clues.

I’m not sure thats the issue, but I will double check

@RogerClark, when you’ve added yourself to dialout group, did you logout/login ?
because current shell doesn’t inherit the newly added permissions …

I found it!

On laptop I was uploading a test from RTC Library using I²C

On Desktop I uploaded a simple example (AnalogRead).

The problem was caused by Wire library. Uploading simple example on laptop ttyACM appears.

BTW, I’ll open another thread for I²C isues….

ahull wrote:I also noticed that if I leave the serial monitor open and connected to /dev/ttyACM1 while flashing the board re-appears as /dev/ttyACM2
Have a look in dmesg and/or syslog to see if there are any mode clues.

naguissa: are you sure, that the code with the RTC library even started?
My guess is, that it crashed before coming up to any USB-serial stuff and the board didn’t shown up on you PC.

madias wrote:naguissa: are you sure, that the code with the RTC library even started?
My guess is, that it crashed before coming up to any USB-serial stuff and the board didn’t shown up on you PC.

my reply is in the new thread viewtopic.php?f=27&t=71