Endless spinner when connecting to or flashing Atreus from macOS

[brow]

Describe the bug

I have an Atreus with an A-star controller that is flashed with QMK firmware. When I run Chrysalis on my Mac, it sees the Atreus. But trying to "connect" or "update" the Atreus leads to a spinner that goes on indefinitely.

To Reproduce Steps to reproduce the behavior:

1. Connect keyboard directly to MacBook Pro's USB port.
2. (Optional) Reset the keyboard using the key combo assigned for that purpose. The following behavior is the same either way.
3. Open Chrysalis.
4. Click Connect

Expected behavior I'm not sure! This is my first time using Chrysalis.

Screenshots

Nothing appears to be printed in the console: -1570747066670.log

Desktop (please complete the following information):

• OS: macOS Mojave 10.14.6 (18G95)
• Chrysalis Version: 0.6.2

[obra]

@algernon - You have some experience with the Atreus 1. Any idea on this front? ᐧ

On Thu, Oct 10, 2019 at 3:38 PM Tom Brow [email protected] wrote:

Describe the bug

I have an Atreus with an A-star controller that is flashed with QMK firmware. When I run Chrysalis on my Mac, it sees the Atreus. But trying to "connect" or "update" the Atreus leads to a spinner that goes on indefinitely.

To Reproduce Steps to reproduce the behavior:

1. Connect keyboard directly to MacBook Pro's USB port.
2. (Optional) Reset the keyboard using the key combo assigned for that purpose. The following behavior is the same either way.
3. Open Chrysalis.
4. Click Connect

Expected behavior I'm not sure! This is my first time using Chrysalis.

Screenshots [image: image] https://user-images.githubusercontent.com/238331/66611429-1f02d300-eb84-11e9-8829-81bcc7e54dbb.png [image: image] https://user-images.githubusercontent.com/238331/66611445-2f1ab280-eb84-11e9-99b5-6bae150c0936.png

Nothing appears to be printed in the console: -1570747066670.log https://github.com/keyboardio/Chrysalis/files/3714885/-1570747066670.log

Desktop (please complete the following information):

• OS: macOS Mojave 10.14.6 (18G95)
• Chrysalis Version: 0.6.2

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/keyboardio/Chrysalis/issues/432?email_source=notifications&email_token=AAALC2FLUHEYF57AWELRIDLQN6VH7A5CNFSM4I7S27C2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HRCAP5A, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAALC2FEBREPBA6SBID4HXTQN6VH7ANCNFSM4I7S27CQ .

[dsummersl]

I'm seeing this too - I just bought this one and assembled it so I'm hoping its the right version of the Atreus 🤞 !

[algernon]

Oof, sorry for the late reply, this fell through my radar, even with the ping. Apologies!

The reason it is stuck spinning, is because it is waiting for the keyboard to enter bootloader/programmable mode. You need to press whatever key combination your QMK layout has for reset (Raise + ESC, b on the default layout), or poke the reset button with a paperclip. That should put the keyboard into programmable mode, and Chrysalis can proceed.

I'll need to add these instructions onto the upgrade/flashing screen at some point...

[brow]

Thanks for looking into this, @algernon! Note in my report that the issue occurred for me regardless of whether the Atreus was in programmable mode or not.

[algernon]

Oh, I missed that part. Hm. I'll see if I can add some debugging to the flasher, that'll help us figure out what's up.

(FWIW, I have an Atreus1 with A*, from FalbaTech, and update via Chrysalis seems to work, at least under Linux. I'll try to find some time to try from under OSX - need to find and unpack my Mac Mini first...)

[obra]

is this problem on Catalina? There is a known issue that Apple is fixing where Catalina broke the ability to flash a lot of embedded devices

On Oct 22, 2019, at 9:00 AM, Gergely Nagy [email protected] wrote:

 Oh, I missed that part. Hm. I'll see if I can add some debugging to the flasher, that'll help us figure out what's up.

(FWIW, I have an Atreus1 with A*, from FalbaTech, and update via Chrysalis seems to work, at least under Linux. I'll try to find some time to try from under OSX - need to find and unpack my Mac Mini first...)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[brow]

Cool, let me know if I can be of use! I currently use avrdude to flash my Atreus with QMK, and I'd be happy to run that in verbose mode and paste output or anything.

is this problem on Catalina?

Not in my case:

OS: macOS Mojave 10.14.6 (18G95)

[algernon]

I currently use avrdude to flash my Atreus with QMK

Aha! That may be the problem. Chrysalis currently assumes that the Atreus1 has HalfKay (ie, Teensy) as the bootloader. I guess my Atreus uses a Teensy then, not an A*, but with the same pinout. In this case, there's no easy workaround. The best idea I have at the moment is to add a dropdown to Chrysalis that lets you select how to flash the board: either using the Avr109 protocol (avrdude) or HalfKay (teensy). I'm not sure I can reliably autodetect them... unless... unless the VID/PID of your Atreus is different!

And it must be different, because if it would be the same, we'd try to flash, and time out. But we wait for the device indefinitely. That explains the spinning.

Can you tell me the USB Vendor and Product ID of the device when reset into bootloader mode? Not sure how to get that info on OSX, though. Perhaps lsusb works there too?

[brow]

Found this in the macOS System Information app!

Atreus: Product ID: 0xa1e5 Vendor ID: 0x1209 Version: 0.08 Serial Number: 0 Speed: Up to 12 Mb/sec Manufacturer: Technomancy Location ID: 0x40110000 / 6 Current Available (mA): 500 Current Required (mA): 500 Extra Operating Current (mA): 0

[algernon]

Darn. My assumptions were wrong then, because this is the same VID/PID my Teensy-based Atreus uses. Well... two options then: dropdown, or I try teensy or avr109 first, wait for a timeout, then try the other and hope for the best.

Nevertheless, we found the root cause, and that's nice progress! Thanks for the help so far!

[brow]

Ah, sorry, I missed that you asked for the device info when reset into bootloader mode. Here that is:

Pololu A-Star 32U4 Bootloader:

Product ID: 0x0101 Vendor ID: 0x1ffb Version: 0.01 Speed: Up to 12 Mb/sec Manufacturer: Pololu Corporation Location ID: 0x40110000 / 6 Current Available (mA): 500 Current Required (mA): 100 Extra Operating Current (mA): 0

[algernon]

\o/

Awesome. That is different than the Teensy's, so we can have a timeout on the teensy wait, and try Caterina after. I'll try to find some time to do that in the next few days.

[dsummersl]

Keen to hear how this goes! I tried several firmwares with my new atreus (I've done nothing more than verify its an atmega 32u4 chip on the back - the 2014 dates on the board/microchip-board is a little disconcerting, but I think its new?). None of the atreus supplied or QMK-built firmwares I made seemed to work with Chrysalis (it would spin forever on connection) - using avrdude on osx 10.14.6.

Once I compiled/installed the Chrysalis-Firmware-Bundle stock firmware, then Chrysalis detected my keyboard and I could assign a layout to Layer 0!...but after disconnecting from Chrysalis no keypresses result in output :/

[dsummersl]

My keyboard info in case that is at all helpful:

From OSX

Atreus:

  Product ID:	0xa1e5
  Vendor ID:	0x1209
  Version:	1.00
  Serial Number:	Ckbio01E
  Speed:	Up to 12 Mb/sec
  Manufacturer:	Technomancy
  Location ID:	0x14600000 / 3
  Current Available (mA):	500
  Current Required (mA):	500
  Extra Operating Current (mA):	0

avrdude with verbose reports this:

avrdude: Version 6.3, compiled on Sep 21 2018 at 19:15:33
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2014 Joerg Wunsch

         System wide configuration file is "/usr/local/Cellar/avrdude/6.3_1/etc/avrdude.conf"
         User configuration file is "/Users/danesummers/.avrduderc"
         User configuration file does not exist or is not a regular file, skipping

         Using Port                    : /dev/cu.usbmodem14601
         Using Programmer              : avr109
         AVR Part                      : ATmega32U4
         Chip Erase delay              : 9000 us
         PAGEL                         : PD7
         BS2                           : PA0
         RESET disposition             : dedicated
         RETRY pulse                   : SCK
         serial program mode           : yes
         parallel program mode         : yes
         Timeout                       : 200
         StabDelay                     : 100
         CmdexeDelay                   : 25
         SyncLoops                     : 32
         ByteDelay                     : 0
         PollIndex                     : 3
         PollValue                     : 0x53
         Memory Detail                 :

[algernon]

I'll try to find some time to do that in the next few days.

...and a few... uhh... days, yes, definitely days.... anyway, a few days later, we have merged a whole new flashing process, which should make it much easier to support multiple flashing protocols / bootloaders / whatever. Not quite there yet, but with another refactoring about to happen soon, we'll be able to finally address this issue too.