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
https://github.com/rogerclarkmelbourne/ … bootloader
.. as it may cast some light on your issue.
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…
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);
}
void setup() {
delay (2000);
Serial.begin(9600);
while (Serial.available() < 1 )
{
Serial.write('a');
delay (1000);
}
Serial.println("Serial OK");
}
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!
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…..
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.
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.
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
Have a look in dmesg and/or syslog to see if there are any mode clues.
because current shell doesn’t inherit the newly added permissions …
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….
Have a look in dmesg and/or syslog to see if there are any mode clues.
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 guess is, that it crashed before coming up to any USB-serial stuff and the board didn’t shown up on you PC.