I guess Soarer's Converters are being manufactured now, because the ones I found online are from sellers who don't know what microcontroller is inside, and the listings all seem to share the same photos. Here's an example:
I bought one of these and wrote up what I learned about it
over at deskthority. I'm sharing it here in case others find themselves in a similar situation and want to identify what they have on their hands.
The one I bought responded to scinfo as running code version 1.12, which is the latest version number, but I wanted to overwrite it with Soarer's original hex file because I don't trust preinstalled firmware from random sellers. Also, the device was producing key events when plugged in, which showed up in my terminal as repeating F7 until I pressed a key, and I hoped that clean firmware might fix it.
Forum consensus was that the microcontroller was most likely an ATmega32U4, but none of dfu-loader, avrdude, or teensy-loader-cli recognized it as that MCU, nor as any of the other MCU names found in Soarer's docs. To make this work, I would have to figure out which firmware hex file to use, and find a tool that could upload it.
To narrow down the microcontroller possibilities, I compared the data sheets for each of the chips supported by Soarer's firmware with these values reported by scinfo:
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 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. That seemed like my best bet.
The device showed up as USB ID 16c0:047d in normal mode and 16c0:05df in bootloader mode (after running the scboot tool). That second ID appears in several unrelated projects online, probably because it's a popular ID to use for homebrew projects. Among them, I found
these BootloadHID instructions. That's no guarantee, of course, but I decided to risk bricking the device and try the
bootloadHID command line tool.
The guesswork and risk paid off. It worked.
Keyboard input was broken after flashing the firmware, but uploading a blank config with scwr 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, the sleuthing and a little risk paid off. It's working well now. I hope this info helps someone else.