I did something dumb and flashed a bin to my keyboard and could no longer see the /dev/ttyACM0 device. If anyone else runs into this just remove your keyboard from the uConsole and plug it into the uConsole with microUSB. Get the command (./flash) ready to run (timing seems to be crucial like the cheap promicros they use for mech. keyboards) on the bottom of the board is an unpopulated section labeled “S1” bridge those contacts and a green light will blink. While the green light is blinking run the command. It took me about three tries to get it to work.
4 Likes
If you have another computer you can always ssh in and run the flash command that way.
Yes I am aware and that was tried. The flash command would fail as it could not find the proper device doesn’t matter if you did it over usb or ssh. You have to hold the “button” to throw it back into the mode where it will accept programming again.
Same. Got my Device µConsole yesterday, downloaded the bin-File (uConsole/Bin/uconsole.kbd.0.4_48mhz.bin at master · clockworkpi/uConsole · GitHub) and now its bricked.
Why are there bin-files, which are not functional? How can i restore my Keyboard again?
I got it working again.
I used the schematic of the STM32F104R chip to figure out the pins for my ST-Link and flashed a standard BIN file using the STM Cube Programmer. Then I was able to flash the existing keyboard.ino.bin, and in the uConsole I had to repeat the flashing process with the flash.sh and then it worked again.
Strangely enough, clicking with the trackball now also works.
But it’s not a real mouse click because I can’t click anything with it on the desktop, but I can click in Midnightcommander.
And the volume button now also works with shift + and without -.
I didn’t really want anything more.
If it had at least said somewhere that the latest version for the keyboard was already included in the ready-made TGZ file, everything would have been easier.
Addendum:
Now it is necessary to install the Flash.sh script in /etc/rc.local, otherwise the keyboard will not work.
After switching off the device and switching it on again at some point, the keyboard no longer works. Only when I flash it again does it work again.
Similar problem when I connect something to the external USB port, whether USB stick, SSD, or other devices, then the keyboard no longer works.
Addendum 2:
It appears that the “wrong” bin file mentioned in my previous answer (uConsole/Bin/uconsole.kbd.0.4_48mhz.bin at master · clockworkpi/uConsole · GitHub) is not the wrong one , it’s just not intended for the Upload method present in the tgz file.
These appear to be images of the entire flash memory of the STM32F103R… Because after a lot of trying, I just tried the bin file that I originally used to destroy everything.
Since this appears to be an image, everything now works perfectly again.
A few tips would have been nice as to which files are for what.
I’m sure not everyone has the tools and resources to repair THAT without soldering anything.
I might be in a similar situation - could you elaborate how you flashed the complete image to the Chip?
I tried to flash a QMK firmware (described here) and now the keyboard does not react at all - also it does no longer show up as a ttyACM0 USB device.
So I took out the PCB - there is the Micro-USB Port (UART capable as to the Clockwork webpage) as well as a separate UART connection. My best guess would be to use the latter to flash the controller. How did you do it?
I haven’t used this myself, but there’s instructions in the clockworkpi git page.
Oh thank you, didn’t see that. This looks promising at least 
Ahw - I have everything here even an USB-UART adapter. But soldering onto the 0.5mm pitched traces it not my thing so I have to get a proper flat cable and breakout board. And this will take almost two weeks…
At least the uConsole is not my primary computer.
Just curious, did you have anything plugged into the USB A port when the update failed? I have a teensy 4.1 that kills the keyboard if i plug it in after power on, it has to be plugged in while power is off and then it works fine.
No - I tried to flash the QMK firmware for the first time as described in the other thread. While running maple_upload I got a progress bar that went to around 70% and then it simply threw an error.
Nothing connected to the USB port. IIRC there was not even power connected to the USB-C.
Now I have to wait for the flat cable and pinhead adapter before I can try again. We’ll see if I can reproduce the error or (preferrably) it just works the next time.
I did in fact try to flash your latest “…sway.bin” withouth flashing any of the other QMK firmwares first. I don’t think this should be a problem but maybe I’m wrong.
Shouldn’t matter because the maple_upload script is just calling dfu-util without specifying a transfer size (which isn’t recommended anyway), and I’m currently running a larger firmware than the sway.bin
I just noticed the maple_upload script is specifying /dev/ttyACM0 - which no longer exists with my qmk-updated firmware. Have you tried running
sudo dfu-util -w -d 1eaf:0003 -a 2 -D clockworkpi_uconsole_default.sway.bin -R
and then bridging s1?
EDIT: I just reread your dmesg output in the QMK post and you’re not getting vendor:product id’s so I don’t think this will help. Is there anything for the keyboard in lsusb?
Rather than another edit, another reply…
my lsusb output:
:~ $ lsusb
Bus 001 Device 010: ID feed:0000 Clockwork uConsole Keyboard
Bus 001 Device 002: ID 05e3:0608 Genesys Logic, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Important bit is “feed:0000”. So I tested (bravely!):
sudo dfu-util -w -d feed:0000 -a 2 -D clockworkpi_uconsole_default.sway.bin -R
and successfully flashed the firmware.
The official page says “8. Rest assured that this flash program will not brick your keyboard.” but needing to break out some extra hardware counts as a soft-brick in my book 
Very brave indeed!
But nope, I only see the hubs. dmesg still shows the “device not accepting address” error.
My guess is that the STM32 chip also takes care of USB and an incompletely flashed binary breaks this functionality too - so it is no longer accessible via USB.
I’m rather convinced that flashing via UART will fix the issue except if there is a real hardware defect. But that would be a strange coincidence so I keep my hopes up.
And yes, I also read that paragraph about resting assured and laughed silently
I finally received the missing cables (including pre-christmas shipment troubles…)
But no. It seems the keyboard is thoroughly bricked. Not even stm32flash can see the chip - it just times out. I have checked connections and will do some more tinkering but I think I’m out of luck with this one.
I wonder how this would be even possible, except if there was some hardware fault involved from beginnin that already prevented my initial flash and thus causing the error.
Bad luck - I hope new keyboard PCBs are available separately. This is a tinkerers toy anyway so there’s that…
Some more tinkering - some more information and a good outcome!
Let’s say the linked description on how to flash the STM32 microcontroller via UART is lacking. Nowhere it mentions connecting the device’s grounds which is of course very necessary.
So to be clear: DO NOT FORGET THE GROUND CONNECTION!
Flashing worked and the keyboard now does as well. I feel only a little bit stupid because I didn’t think of the ground connection myself at first. I did in the end though and that counts
So I recovered the bricked keyboard PCB - now on to bricking it again using the alternate firmware (or rather getting it to work - we’ll see)
3 Likes