Notes on Building WCH BLE CH592 EVT Exam with Bare Makefile

Here are some notes from tinkering with the WeAct Studio BLE Core Board.

It’s Not Used in Many Designs

My interest in the board comes from my interest in custom mechanical keyboard designs.
– The best part of ‘free and open source’ is the “gratis” part.
But the “libre” part is neat, too: it’s much easier to realize an interesting keyboard design if all you need to do is iterate on a keyboard design someone else has made.

I’ve never tried designing a Bluetooth keyboard.
The sour grapes explanation is that Bluetooth devices are finicky to use. (Which is true).
What most hobbyists do for Bluetooth keyboards is use Bluetooth-powered devboards like the nice!nano, and use ZMK firmware. – TBH part of why I’m not interested in this devboard is it costs over 20 USD. (And it’s most common in split keyboards, which’d need one for each side!).

I recently picked up a WeAct Studio BLE Core board, ordered from AliExpress.
(I’ve used a few different devboards from WeAct Studio in several of my keyboard PCB designs; including WCH MCUs).
The BLE core board has designs for the different MCUs: CH573, CH582, CH592.
In contrast, this devboard costs $2.

But despite it being such a cheap board, I can’t find any designs which use this board.

Some notes on what I could find:

The Alternatives wiki page on joric’s nrfmicro repo describes the CH582 as:

QMK has a CH582 port! It has BLE and there’s a dev board for it on Aliexpress for about 2 bucks. That is, if you’re willing to experiment since, as far as I’m aware, no keyboard has been designed with it and there’s not a lot of users yet. [ZMK not supported.] … Last I looked, datasheets were basically “sorry, not documented” on the registers for BLE hardware. And 32KB of RAM on the CH582F would definitely be a challenge.

Regarding “low RAM an issue” semickolon (who authored FAK firmware for the CH552 MCU) commented that the chip’s BLE only uses 4KB RAM, and that FAK had about 1KB RAM. (He also mentions he’s got a keyboard working with some firmware he’s building for the chips).

The datasheets indeed omit documentation for the registers for the BLE hardware.

FWIW, I did see some BLE keyboards using these WCH chips on OSHWHub such as cansong’s ch579 keyboard, which points to JokerAlon’s ch579m. Albeit, the readmes for these aren’t in English. – The schematics are available, at least.

Albeit, at the time of writing, there really aren’t many English search engine results for CH592. Nor CH58x. Nor CH57x.
The keyboards above seem to be row-stagger, and with big spacebars. (The big spacebars make it easier to design a PCB, but don’t make for a good keyboard. – I do recall seeing boardsource.xyz’s solution to this for their technikable ble ortho was to omit the 2 keys in the bottom corners of each side..).

I wasn’t aware of it before, but both the wiki page above (and the reddit comment) point to O-H-M2’s port of QMK for CH582. (Looking at the port a bit: it retains upstream QMK’s codebase unchanged, and adds some platform-specific code for CH582).
(There are keyboards listed in this; one seems to be a giant handwired ortho, the others are either macropads/numpads, or row-staggered with big spacebars).
The default branch name is via; the readme mentions via functionality is implemented. (I don’t use via/vial, but seems it’s useful for many).

On GitHub, OpenWCH provides EVTs with Examples and SDKs for CH592 (and other chips). (Whereas, CH552 is in the SoCXin org). – These examples include a BLE HID “keyboard” (it periodically sends a HID keyboard report, but doesn’t read GPIO pins).
– So, there is working code, and a README PDF(!) describing how to run the example.. this PDF describes to use MounRiver Studio.

Using MounRiver Studio works (at least for building these EVT Examples; I didn’t try flashing from MounRiver).

I saw that the WeAct BLE repo included Makefiles for its code (copied from the EVT).
Copy-pasting the comment at the header of the file into a translate service: “generated, do not modify”.
Oh no.

That’s … not a promising sign.

Fortunately, the QMK port to CH582’s readme has instructions which mention downloading the MounRiver Studio toolchain and using cmake/make.

Toolchain: Building the CH582 Port of QMK

I’m running NixOS, and one of the downsides of using NixOS is it can be difficult to run binaries distributed in tarballs.

MounRiver Studio and its toolchain is distributed as binaries in a tarball.

I was able to come up with some Nix packages for the libmcuupdate.so distributed in the toolchain tarball, and the GCC toolchain:
https://github.com/O-H-M2/qmk_port_ch582/commit/40828b8361bbc711fb7c7af00374eea565f75d2f
(I adapted another Nix package which downloads GCC in a tarball).

With that, I was able to build the QMK port for CH582 built.

Oh. Wait. Taking a look at the --version for the toolchain MounRiver Studio distributes:

$ riscv-none-embed-gcc --version
riscv-none-embed-gcc (xPack GNU RISC-V Embedded GCC, 64-bit) 8.2.0
Copyright (C) 2018 Free Software Foundation, Inc.

Risc-V Toolchain

Links to things:

The old riscv-none-embed-gcc-xpack, and SiFive’s riscv-gcc.

And the newer riscv-none-elf-gcc-xpack. And this seems related: https://github.com/riscv-collab/riscv-gnu-toolchain.

The change from riscv-none-embed-gcc to riscv-none-elf-gcc is mentioned in the xPack riscv gcc 11.3 release notes.

Trying these upstream xpack riscv toolchains with the qmk port for ch582.. for one, TOOLCHAIN_PREFIX needs to be set to risc-none-embed if using the older GCCs. But, I did need to make a couple of other changes:

The MounRiver toolchain has an extra param highcode-gen-section-name that the xpack toolchains don’t have: https://github.com/O-H-M2/qmk_port_ch582/commit/347e15458be15a714494d0088fa77243f62e7009

And, as the xPack riscv gcc 12.1 release notes explain, errors like extensionzicsr’ requiredcan be fixed by adding_zicsr` to the arch: https://github.com/O-H-M2/qmk_port_ch582/commit/dafb73132b6642ac70322239673060fe56d0b9b9

(I didn’t try the toolchain that’s checked into the git repo; but seeing stuff like that makes me wonder if the embedded developers are doing okay).

Building the Examples Outside MounRiver Studio

The EVT Examples are supplied with only a MounRiver Studio project file.

Since I’m not sure what works and what doesn’t work (in terms of how to compile the examples outside of MounRiver), it’s easiest to start from something that works. – Building it in MounRiver works, which generates some Makefiles.

Using that, I adapted a Makefile with the same compiler flags to get a Makefile which produced a working build.
(Or, honestly: I’d copied the makefile from the broadcaster example, but that set different -D defines, which didn’t play nicely with the BLE HID example, and it took me some time to notice why my Makefile wasn’t producing a working build of the example).

Anyway.

I copied the BLE HID_Example example, put it together with a standalone Makefile, and some Nix files to provide the toolchain, and shared it in this repo: https://github.com/rgoulter/ch592-ble-hid-keyboard-example

Flashing the Firmware

Flashing the CH592 is the same as flashing the CH552. You can enter the bootloader by holding the BOOT button when plugging the board into the computer, and then use ch32-rs’ wchisp to flash the firmware. (On Windows, I’d had difficulty using wchisp; but the official programs from WCH worked on Windows when I tried with the CH552).

---

---