Firmware Update hangs on "4. Flashing Neuron"

[xaionaro]

Describe the bug Bazecor-1.3.9 hangs on reflashing Neuron of Dygma Defy from v0.0.6 to v1.2.5-beta.

To Reproduce Steps to reproduce the behavior:

1. On Linux launch Bazecor-1.3.9-x64.AppImage.
2. Click on "Connect", "Firmware Update", "Update now" and "Let's start".
3. Click the far-left (escape?) button on the Dygma Defy.
4. Look forever on the never-ending "4. Flashing Neuron" window.

Expected behavior "4. Flashing Neuron" hangs for no more than half hour and then flashing successfully completes.

Screenshots -1704642621730.log

Desktop (please complete the following information):

• OS: Ubuntu Lunar
• Bazecor Version: 1.3.9-x64

Additional context I see a Bazecor spawns a lot of lsblk processes (I've shared the details in #402). Also @sfavazza shared there the details of the same bug on their side (and they also use Linux).

[tupats]

Getting the same issue. Dygma Defy wired, both on Linux and MacOS

[jreklund]

@xaionaro @tupats @sfavazza You can manually flash the Wired Neuron in Linux using the following steps:

1. Unplug ALL usb-cables from the Wired Neuron
2. Grab a metall paperclip and press AND hold down the tiny button inside Neuron (see picture)
3. While holding down the button - plug in the USB-C cable to your computer
4. Hold... for like 5 seconds
5. (mount the USB-drive)
6. Copy Wired_neuron.uf2 to the USB-drive
7. It will flash itself (if I recall the led will flash)
8. Unplug the Neuron
9. Plug in each half and then the Neuron
10. You need to restore the default keyboard layout with Bazecor

How to mount the drive:

$ lsblk # it will show the blocks ex. mine
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda           8:0    1   128M  0 disk
└─sda1        8:1    1   128M  0 part
nvme0n1     259:0    0 953.9G  0 disk
├─nvme0n1p1 259:1    0   512M  0 part /boot/efi
├─nvme0n1p2 259:2    0    42G  0 part /
├─nvme0n1p3 259:3    0 903.4G  0 part /home
└─nvme0n1p4 259:4    0     8G  0 part [SWAP]

$ udisksctl mount -b /dev/sda1 # in my case is sda1 because I have nvme drive, ex. mine
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda           8:0    1   128M  0 disk
└─sda1        8:1    1   128M  0 part /run/media/your-username/RPI-RP2

$ sudo cp Downloads/Wired_neuron.uf2 /run/media/your-username/RPI-RP2/ # used sudo just in case

[xaionaro]

@jreklund : Thanks for the reply. It helped, but only partially. Now it does report like it is upgraded:

But if I try to reflash it using Bazecor (just in case to make sure everything is fine), then it still hangs the same way.

I also quickly recorded a video with my experience of reflashing: https://www.youtube.com/watch?v=WtwK-JB_gnc (sorry for a hard accent in the pronunciation).

[jreklund]

@xaionaro Thanks for the video! Manually flashing will not fix the Bazecor bug, where it can't mount the Neuron properly (just my guess).

It's just doing the step 4 outside of Bazecor. Step 5 is restoring your layers that you also need to do manually.

Don't know if Preferences > Chrome Tools > Console reports anything useful for the developers while on Step 4.

If you do Step 5 Restoring your layers manually, does the keyboard work properly except the firmware update process?

[alexpargon]

Hey there @xaionaro !

( first sorry for not checking these issues before but we are pushing the Raise 2 certification as Manel leaves today for China and has to take the Soft tools and correct FWs to certify the boards 😓 )

The issue seems related with the auto-mount feature in your Linux Distro, the first thing that Bazecor does when trying to flash it is to automatically enter the UF2 loading mode of the Raspberry-pico ROM bootloader. then it locates that drive (that is when is getting stuck in your video, it's just waiting for the folder to appear) and then it proceeds to load the FW to that folder via file copy.

Both Mac and Windows have auto-mount enabled by default and the mounted drive's paths are mappable with the library that we use to detect connected devices, auto-mounting is not happening in your Linux! if you mount manually the UF2 bootloader when Bazecor stops advancing during the flashing procedure, it will probably work, either way, I'm going to test this out on a Linux machine to see if we can automate that part when auto-mount is disabled.

let me get you back in a little while. Bye!

[tupats]

Alex, I was having the same issue in MacOS as well, it automounts but is instantly unmounted. Same on my Linux desktop. Manually flashing worked though.

[alexpargon]

Alex, I was having the same issue in MacOS as well, it automounts but is instantly unmounted. Same on my Linux desktop. Manually flashing worked though.

Hey there @tupats ! i tried this on my own with a macbook m1 and nothing weird happened, just flashed as expected 😓 so maybe you can go to preferences at the bottom and activate the "Chrome tools" toggle so that you can paste us the error that happens when flashing.

[xaionaro]

@jreklund , @alexpargon : Thank you for the help and for the insights.

Using your insights I can confirm that the problem is indeed related to mounting. I added an user mount into /etc/fstab and manually mounted the block device when Bazecor was hanging and Bazecor successfully unfroze and finished the flashing procedure. So the problem seems to be purely software (with Bazecor having extra assumptions about how the system is configured), which is a relief :)

More specifically added to /etc/fstab:

LABEL=RPI-RP2   /mnt/RPI-RP2    vfat    defaults,noauto,user 0 0

created the directory and then just did:

mount /mnt/RPI-RP2

when Bazecor was hanging on 4. Flashing Neuron. And it successfully completed:

The video with this experiment is available here: https://youtu.be/EL2dDRAwnjE?t=370

Anyway, this is good enough personally for me, but keeping the issue open because it still seems like a bug of Bazecor. IMO, would be nice if it at least give a proper message (what to do, or at least link to this discussion) instead of just hanging indefinetely and consuming CPU :)

---

If you do Step 5 Restoring your layers manually, does the keyboard work properly except the firmware update process?

Keyboard seems to work properly. Though it is uncertain: haven't started to use it, wanted to figure out the flashing problem first. Will start actively using it next week and report back if there are any problems. But so far haven't observed anything weird/wrong.

( first sorry for not checking these issues before [...]

Absolutely no worries, thanks for help :)

[krillin666]

I have this problem but since I have the wireless version, how can I mount and manually reset the keyboard?

[alexpargon]

I have this problem but since I have the wireless version, how can I mount and manually reset the keyboard?

This issue with mounting the Neuron as a USB drive only happens with the Wired version of the Neuron, if you have a wireless keyboard and aren't able to flash it properly with Bazecor please open a new issue and try to capture the errors that appear on the Chrome tools so we can know what's happening!

[rnpatel]

This is still happening for me in macOS with the latest firmware (1.2.7-beta) and Bazecor 1.4.0-rc2. Manually flashing works fine, but it's an annoyance to have to go through that process.

[thokall]

So is there any work done on this issue or is it on hold?

[patstrom]

This just means I cannot update at all on Linux unless I do it manually. I suspect I am now in a situation where my halves have been updates the the neuron haven't. Is there any update on this?