Project 001 · 21 September 2026 · In progress

Reverse engineering the ToolkitRC P200

The goal is simple: take three compact P200 supplies, understand how their control electronics work, and turn them into a computer-controlled three-channel bench supply. The interesting part is everything between those two points.

This is a live engineering notebook. Confirmed measurements are separated from working hypotheses, and conclusions are revised when new evidence contradicts them.

Why this supply?

The P200 is small, can be powered from a 24 V DC bus, provides a programmable main output, and also contains a useful USB-C fast-charging output. Three units could cover most everyday low-current bench work while a larger RIDEN supply remains available for occasional high-power loads.

Identifying the hardware

The unit under test is the original P200 rather than the later P200 V2. The enclosure is approximately 84 mm long, matching the V1 mechanical dimensions. This mattered immediately: V1 and V2 use different firmware packages.

Model ToolkitRC P200 V1

Main MCU GD32F103CBT6 observed on PCB

Update interface USB Mass Storage

Firmware file ToolkitRC P200 V1.05-STN · app.upg

USB: useful, but not remote control

Connecting the P200 to Linux exposed a single USB interface: STMicroelectronics 0483:5820, class 8 Mass Storage, SCSI Bulk-Only. Linux mounted a tiny FAT12 volume labelled Toolkit. No CDC serial, HID or secondary vendor interface was exposed.

The volume is therefore useful for firmware update work, but it does not provide an obvious documented path for normal PC control.

Firmware package

The official V1.05-STN package contains an app.upg image of 86,548 bytes. Linux identifies a Cortex-M vector table at the beginning, including an initial stack pointer of 0x200013F0 and a reset vector of 0x08009101.

Useful plaintext strings are present in the image, including output voltage/current labels, USB charging protocol names and a START OUTPUT message. However, a first-pass assumption that file offsets mapped directly to executable flash addresses did not survive testing: data at the apparent reset location did not disassemble as sensible Thumb code. That is now treated as an unresolved firmware-format question rather than forcing an interpretation.

PCB access changes the plan

Opening the unit revealed labelled test points and a debug header. The board exposes signals labelled for 3.3 V, reset, clock/data and several control points. The GD32F103 supports SWD, so a read-only debug connection is one of the next investigation paths.

Another group of test points appears to expose a low-voltage serial control bus near the power-control section. The next step is to measure the idle voltages first, then capture the traffic with a logic analyser while changing voltage, current limit and output state.

Next measurements

The next bench session will focus on evidence rather than modification:

Measure all labelled test-point voltages relative to ground.
Capture the suspected clock/data pair with sigrok/PulseView.
Record separate traces for boot, output on/off, voltage changes and current-limit changes.
Verify SWD pin continuity before connecting the debugger.
Keep all first SWD operations read-only; no unlock or erase operations.

End goal

If the control path can be reproduced safely, the display boards may no longer be required. A small microcontroller interface could expose voltage, current, output state and telemetry to a Linux host, allowing three P200 power stages to share one 24 V source and appear as independent channels in a web dashboard.

Target architecture: 24 V supply → three P200 power channels → Pico-class controller → Linux dashboard, with the existing high-power RIDEN channel retained for occasional loads.