Flashing problem on Ubuntu (SOLVED)

systemctl status ModemManager should help figuring this out, I think.

Hm. This sounds different than the usual issues caused by ModemManager. Do you have the right board & port selected in the IDE? Perhaps the output of sudo dmesg | grep -i ttyACM -A 2 -B2 could provide a hint about where things go wrong.

Apologies for the bad formatting -

richard@richard:~$ systemctl status ModemManager
● ModemManager.service - Modem Manager
Loaded: loaded (/lib/systemd/system/ModemManager.service; enabled; vendor preset: enabled)
Active: active (running) since Tue 2017-10-31 11:43:04 GMT; 31min ago
Main PID: 1001 (ModemManager)
Tasks: 3 (limit: 4915)
CGroup: /system.slice/ModemManager.service
└─1001 /usr/sbin/ModemManager

Oct 31 11:43:04 richard systemd[1]: Starting Modem Manager…
Oct 31 11:43:04 richard ModemManager[1001]: ModemManager (version 1.6.4) starting in system bus…
Oct 31 11:43:04 richard systemd[1]: Started Modem Manager.
Oct 31 11:43:07 richard ModemManager[1001]: Couldn’t check support for device at ‘/sys/devices/pci0000:00/0000:00:1c.1/0000:02:00.0’: not
Oct 31 11:43:07 richard ModemManager[1001]: Couldn’t check support for device at ‘/sys/devices/pci0000:00/0000:00:1c.5/0000:04:00.0’: not

With the keyboard plugged in:

> richard@richard:~$ dmesg | grep -i ttyACM -A 2 -B2
> [  172.527970] usb 2-1.1: Manufacturer: Keyboardio 
> [  172.527973] usb 2-1.1: SerialNumber: kbio01
> [  173.086136] cdc_acm 2-1.1:1.0: ttyACM0: USB ACM device
> [  173.087862] usbcore: registered new interface driver cdc_acm
> [  173.087863] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters
> --
> [  236.467327] usb 2-1.1: Manufacturer: Keyboardio 
> [  236.467330] usb 2-1.1: SerialNumber: kbio01
> [  236.468822] cdc_acm 2-1.1:1.0: ttyACM0: USB ACM device
> [  243.948330] usb 2-1.1: USB disconnect, device number 4

With the keyboard plugged in, and Prog lit:

> richard@richard:~$ dmesg | grep -i ttyACM -A 2 -B2
> [  172.527970] usb 2-1.1: Manufacturer: Keyboardio 
> [  172.527973] usb 2-1.1: SerialNumber: kbio01
> [  173.086136] cdc_acm 2-1.1:1.0: ttyACM0: USB ACM device
> [  173.087862] usbcore: registered new interface driver cdc_acm
> [  173.087863] cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters
> --
> [  236.467327] usb 2-1.1: Manufacturer: Keyboardio 
> [  236.467330] usb 2-1.1: SerialNumber: kbio01
> [  236.468822] cdc_acm 2-1.1:1.0: ttyACM0: USB ACM device
> [  243.948330] usb 2-1.1: USB disconnect, device number 4
> [ 2332.436229] usb 2-1.1: new full-speed USB device number 5 using ehci-pci
> --
> [ 2332.553277] usb 2-1.1: Manufacturer: Keyboardio 
> [ 2332.553280] usb 2-1.1: SerialNumber: kbio01
> [ 2332.554595] cdc_acm 2-1.1:1.0: ttyACM0: USB ACM device

I have been using the USB cable supplied with the keyboardio. I have just tried it with a different USB cable and the error is the same.

Stupid question yes, but did you select the right port in Tools->Port in the Arduino IDE? That can cause this error message.

Edit: I see @algernon already asked this above

It’s a fair question — yes, in Tools ->Port it is initially is grayed out. I have to replug-in with the Prog key pressed before it recognizes the Port /dev/ttyACM0

After trying to flash I get the error message, Couldn’t find a Board on the selected port […]

And the port is grayed out again in the IDE.

Here’s my USB connector:

Does this appear faulty? I can’t tell.

Any ideas what I can try next to flash the board?

I’ve found if I leave my hand on the prog key from plugging the keyboard in to uploading, I get a new error:

> Sketch uses 18148 bytes (63%) of program storage space. Maximum is 28672 bytes.
> Global variables use 1659 bytes (64%) of dynamic memory, leaving 901 bytes for local variables. Maximum is 2560 bytes.
> Forcing reset using 1200bps open/close on port /dev/ttyACM0
> processing.app.debug.RunnerException
> 	at cc.arduino.packages.uploaders.SerialUploader.uploadUsingPreferences(SerialUploader.java:160)
> 	at cc.arduino.UploaderUtils.upload(UploaderUtils.java:78)
> 	at processing.app.SketchController.upload(SketchController.java:713)
> 	at processing.app.SketchController.exportApplet(SketchController.java:686)
> 	at processing.app.Editor$DefaultExportHandler.run(Editor.java:2168)
> 	at java.lang.Thread.run(Thread.java:748)
> Caused by: processing.app.SerialException: Error touching serial port '/dev/ttyACM0'.
> 	at processing.app.Serial.touchForCDCReset(Serial.java:107)
> 	at cc.arduino.packages.uploaders.SerialUploader.uploadUsingPreferences(SerialUploader.java:144)
> 	... 5 more
> Caused by: jssc.SerialPortException: Port name - /dev/ttyACM0; Method name - openPort(); Exception type - Port not found.
> 	at jssc.SerialPort.openPort(SerialPort.java:167)
> 	at processing.app.Serial.touchForCDCReset(Serial.java:101)
> 	... 6 more

No, that looks great.

As I’ve not made any progress with my Ubuntu, and I have an old iMac I tried flashing with that. I installed Arduino 1.6.10, but when flashing I got the following error:

"Couldn't find a Board on the selected port. Check that you have the correct port selected. If it is correct, try pressing the board's reset button after initiating the upload."

The only thing that works on my Keyboardio is the Prog key. No other keys register. I’m out of ideas. Any suggestions that I can try?

@richard.east It sounds like what happened was that the sketch you flashed onto the keyboard was, in some way, buggy and is crashing once you get out of the bootloader.

The fact that holding down Prog gets you into the bootloader is a very good sign.

If you’re comfortable at the command line, I think the next thing to try is to try to get you back to the shipping firmware.

Once that’s done, and you have a reliable way to do it again, it’ll make experimentation much, much easier.

This procedure is a little bit ‘off the cuff’, as I’m out and don’t have hardware in front of me. I may mess up the exact commandline invocation, but nothing we do will hurt your keyboard. (It’ll just embarrass me for getting it wrong.)

I’m assuming you’re doing this on your linux box and that you have another (working) keyboard handy.

You’ll either need to have added yourself to the ‘dialout’ group to access the serial ports and then logged out and back in or execute the ‘avrdude’ command as root.

First, grab a copy of https://raw.githubusercontent.com/keyboardio/Model01-Firmware-Builds/master/v1.13-MP1-BUILD/atmega32u4_firmware.hex

That’s the regular firmware shipped on your keyboard.

Then, starting with your keyboard unplugged, type the command ls /dev/ttyACM*

If there are entries there, it means you’ve got something else acting as a serial port that may throw off some of our autodetection logic. If you do, stop there and tell me that. If you don’t, continue on to the next step.

While holding down Prog, plug in your Model 01. Prog should light up red.
type ls -al /dev/ttyACM*

You should see a single entry. That’s the serial port for the Model 01’s bootloader.

After about 8 seconds, the keyboard will give up waiting, try to run your program and (presumably) crash.

The next thing to do is to use the avrdude commandline tool to flash an updated firmware onto your keyboard.

The command, if I have it right is:

avrdude -patmega32u4 -cavr109 -D -P /dev/ttyACM0 -b57600 -Uflash:w:atmega32u4_firmware.hex:i

If you got a different port number in response to your ls, you’ll want to change ttyACM0 to that.

Before you execute this command, unplug your Model 01, and reconnect it, holding in the Prog key. When the Prog key turns red, run the command. You should see a bunch of debugging output, maybe a text progress bar and then the “LED” key should glow blue.

If that doesn’t work, paste the results of running avrdude in here and we’ll keep going from there.

1 Like

@jessie Thank you for your support

TLDR; Factory restore successful! (Thank you)

Actions taken, for your information or for anyone that faces the same problem:-

  • grabbed the hex file.

  • I am a member of ‘dialout’

  • Without keyboardio plugged in:
    $ ls /dev/ttyACM*
    ls: cannot access ‘/dev/ttyACM*’: No such file or directory

  • With keyboardio plugged in:
    $ ls -al /dev/ttyACM*
    crw-rw---- 1 root dialout 166, 0 Nov 2 12:05 /dev/ttyACM0

  • After 8 seconds, out of curiosity:
    $ ls -al /dev/ttyACM*
    ls: cannot access ‘/dev/ttyACM*’: No such file or directory

  • Therefore safe to proceed.

The program ‘avrdude’ is currently not installed.
$ sudo apt install avrdude

Setting up avrdude (6.3-2)

$ avrdude -patmega32u4 -cavr109 -D -P /dev/ttyACM0 -b57600 -Uflash:w:atmega32u4_firmware.hex:i

Connecting to programmer: .
Found programmer: Id = “CATERIN”; type = S
Software Version = 1.0; No Hardware Version given.
Programmer supports auto addr increment.
Programmer supports buffered memory access with buffersize=128 bytes.

Programmer supports the following devices:
Device code: 0x44

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e9587 (probably m32u4)
avrdude: reading input file "atmega32u4_firmware.hex"
avrdude: writing flash (18726 bytes):

Writing | ################################################## | 100% 2.43s

avrdude: 18726 bytes of flash written
avrdude: verifying flash memory against atmega32u4_firmware.hex:
avrdude: load data flash data from input file atmega32u4_firmware.hex:
avrdude: input file atmega32u4_firmware.hex contains 18726 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 1.17s

avrdude: verifying …
avrdude: 18726 bytes of flash verified

avrdude: safemode: Fuses OK (E:FB, H:D8, L:FF)

avrdude done. Thank you.

  • and now I’m typing this on the keyboardio!
  • unplugged it and tried it again. Still works.
  • rebooted. Still works.
  • I will flash again later with the https://github.com/keyboardio/Model01-Firmware, but without changing the Model01-Firmware.ino
  • if that’s good I’ll try editing again. I will report back on this thread.
  • Thank you for your help
2 Likes

I tried flashing from the terminal, using https://github.com/keyboardio/Model01-Firmware.
I have NOT edited the Model01-Firmware.ino file or any other file.

$ make flash
BOARD_HARDWARE_PATH="/home/richard/Arduino/hardware" /home/richard/Arduino/hardware/keyboardio/avr/libraries/Kaleidoscope/bin//kaleidoscope-builder flash
Building output/Model01-Firmware/Model01-Firmware (0.0.0-gv1.13-60-g8f58) ...
Press ENTER when ready...

avrdude: ser_open(): can't open device "/dev/ttyACM0": Input/output error
Connecting to programmer: .
Found programmer: Id = "CATERIN"; type = S
    Software Version = 1.0; No Hardware Version given.
Programmer supports auto addr increment.
Programmer supports buffered memory access with buffersize=128 bytes.

Programmer supports the following devices:
    Device code: 0x44

This time the keyboardio does not break and I can still use it, but it looks like the flash failed as it can’t open /dev/ttyACM0

Our reporting could be better, but what I think is happening there is that on the first try, it can’t connect to your keyboard’s bootloader. But then we wait a second and try again, in case there was a timing issue.

The rest of the message shows it working successfully. If you saw red lights running across your left hand keyboard, then everything did, in the end, work ok.

If you happen to have a github account and a free moment, would you mind opening an issue at github.com/keyboardio/Kaleidoscope/issues saying that the error reporting around flashing could use a bit of work and reference this discussion? If not, no worries.

@jesse - Issue raised Improve Error reporting around flashing #233

I’m pretty sure I did NOT see saw red lights running across the left hand keyboard. (When I did the factory reset earlier, I did see lights.)

I’ll try again tomorrow with the default Model01-Firmware.ino and an altered one to confirm for sure what’s happening. Happy to be a guinea pig for any further tests you need.

Much appreciated!

One thing to try if the flashing doesn’t work, is to try the “factory reset” procedure, but with your new firmware’s hex file.

Another thing to try, (but only if the phrase “switching the git checkout on a submodule” makes sense to you) is to try replacing the Kaleidoscope checkout with this branch: https://github.com/keyboardio/Kaleidoscope/tree/f/builder-cleanup.

That’s my WIP serial port detection logic that should be more reliable, but as I’ve only tested it on one laptop, late at night, uh, well, maybe it isn’t :wink:

Quick update… I flashed as before with the original Model01-Firmware.ino and it DID light up. I must have been wrong earlier. It does show the error message — can’t open device “/dev/ttyACM0”: Input/output error

I also tried flashing with the Dvorak layout. It lit up too and the layout successfully changed. It too shows the error message — can’t open device “/dev/ttyACM0”: Input/output error — can’t open device “/dev/ttyACM0”: Input/output error

I’ve updated my issue Kaleidoscope issue to show it successfully flashes.

Doesn’t mean anything to me yet, but I’ll give it a go this evening, when I hope I’ll have more time.

Alas, I’m still not clear on the phrase “switching the git checkout on a submodule”
However, I tried flashing from the f/builder-cleanup branch and got the following:

$ git checkout f/builder-cleanup
Branch f/builder-cleanup set up to track remote branch f/builder-cleanup from origin.
Switched to a new branch 'f/builder-cleanup'

$ make flash
BOARD_HARDWARE_PATH="/home/richard/Arduino/hardware" /home/richard/Arduino/hardware/keyboardio/avr/libraries/Kaleidoscope/bin//kaleidoscope-builder flash
Building output/Kaleidoscope/Kaleidoscope (0.0.1-g3713) ...
Press ENTER when ready...

avrdude: ser_open(): can't open device "/dev/ttyACM0": Input/output error
Connecting to programmer: .
Found programmer: Id = "CATERIN"; type = S
    Software Version = 1.0; No Hardware Version given.
Programmer supports auto addr increment.
Programmer supports buffered memory access with buffersize=128 bytes.

Programmer supports the following devices:
    Device code: 0x44

It still reports the Input/output error, but successfully flashes. I hope that is useful.

Thanks for the report.

What you’re seeing is a successful flash. The first attempt fails, probably due to a timing issue. But the retry works.

We should start capturing that error output and only showing it if the second attempt (which succeeds for you) doesn’t succeed.

1 Like

Thanks for explaining that. For most cases only showing the error on a second failed attempt makes sense as its current state suggests failure to a new user. Would it be possible to have a verbose option on the output, to show the first failed attempt for users that need to report or debug errors? I’d be interested to know why it always fails on the first attempt.

it’s a timing issue. you are 100% correct about the better user experience. This is very much a case of “haven’t gotten there yet”

we’re also putting some effort into a much simpler cross platform upload GUI that doesn’t call out to avrdude. That would give us much better control.