Reverse Engineering a Handheld Tesla Coil

Flash Driver Problems

First flash attempt using the stm32f1x driver in the target config:

Error: Cannot identify target as a STM32 family.
       Device ID = 0x50020105
       auto_probe failed

The AT32 has its own device ID; the STM32 driver doesn't know it. Manual unlock attempts via telnet (mwh, then mww) with STM32 unlock keys got nowhere (wrong driver, wrong unlock sequence). GDB's restore command was rejected because gdb_memory_map triggered auto_probe on connect, which failed immediately. flash bank can't be issued at runtime via telnet; it has to be in the config before init.

The packaged OpenOCD doesn't have an Artery driver. Building from source does.

Building OpenOCD from Source

git clone https://github.com/openocd-org/openocd.git ~/openocd-src
cd ~/openocd-src
./bootstrap
./configure --enable-bcm2835gpio --enable-internal-jimtcl
make -j4
# ~10 minutes on a Pi 3B

--enable-internal-jimtcl is needed because jimtcl isn't available as a standalone package on Raspberry Pi OS. Without it, configure fails.

After building, the new binary can't find swj-dp.tcl unless you point it at the source tree:

~/openocd-src/src/openocd -s ~/openocd-src/tcl -f interface.cfg -f target.cfg

The -s flag sets the script search path. Without it the binary looks in the installed share directory, which doesn't exist because you didn't run make install.

Searching the source for Artery support:

grep -r "50020105" ~/openocd-src/src/

~/openocd-src/src/flash/nor/artery.c:  { 0x50020105, "AT32F421F8P7", ... }

Device ID 0x50020105 is explicitly listed in artery.c. Updated the target config:

flash bank at32.flash artery 0x08000000 0x10000 0 0 at32.cpu

And corrected the CPUTAPID to the actual reported value:

swj_newdap at32 cpu -irlen 4 -expected-id 0x2ba01477

Successful Flash

With the new binary and the artery driver:

Device ID = 0x50020105 (AT32F421F8P7)
Flash size = 64 KiB

Correct identification. Then:

> program firmware_v1.bin verify 0x08000000
wrote 65536 bytes in 3.68s
verified 65536 bytes in 0.67s

Backup reflash, v1, and v2 all programmed and verified successfully. To restore the backup at any point:

> program firmware_backup.bin verify 0x08000000

Result

The v1 and v2 modified firmwares ran on the device. The frequency change was imperceptible in testing.

Correction: The Capacitor Conclusion Was Wrong

The original explanation here was that the capacitor bank was the real bottleneck: halving the timer values just fired the trigger into a half-charged bank, producing the same arc rate at lower energy. This is incorrect and is retracted.

The evidence came from testing v4 firmware, which reduced the counter threshold at 0x8000a8c from 735 to 200. The arcs were weak, but the first arc after power-on was also weak, before any recharge issue could apply. At power-on, the caps are fully charged. A weak first shot means cap recharge time is not the gating factor. Something in the firmware was directly controlling arc energy, independent of the capacitor state.

The reason v1 and v2 showed no perceptible frequency change is explained below.

What the ARR Constants Actually Control

The constants at 0x80022a4 (8,000,000) and 0x80022a8 (4,000,000) do feed into a timer ARR via the function at 0x800215c. However they set the period of a timer that is not the direct discharge trigger. Patching them changes something in signal or mode timing but does not change the rate at which arcs fire. That is why v1 and v2 were imperceptible.

One additional detail from the analysis: a right-shift lookup table at 0x0800267c holds the values [0,0,0,0,0,0,0,0,1,2,3,4,6,7,8,9], indexed by a 4-bit field from the timer register. This table applies a final divisor to the ARR constant before writing it to the timer. For indices 0 through 7 the shift is 0, so there is no effect in those modes. It appeared significant during analysis but turned out to be a red herring for frequency control.

The Two-ISR Architecture

Tracing the vector table revealed two ISR handlers that together drive the discharge cycle:

ISR at 0x8000a4c (IRQ vector 25): pulse width

This ISR increments a counter and compares it against a threshold of 735, encoded as movw r1, #735 at flash offset 0x8000a8c. When the counter hits 735, it calls a GPIO write function at 0x8001be4 that clears a GPIO pin, ending the discharge pulse, then resets the counter. This ISR controls how long each individual arc lasts. Reducing the threshold to 200 shortened the ON time, delivering less energy per arc regardless of cap charge state. That is exactly why the first shot after power-on was weak.

ISR at 0x800129c (IRQ vector 36): discharge frequency

This ISR runs a two-level counter structure. An inner counter increments and compares against 3000 (movw r1, #3000 at 0x80012c4). When the inner counter hits 3000, the outer counter increments and the inner resets. When the outer counter hits 10 (cmp r0, #10 at 0x80012e0), the GPIO pin is set to start a new discharge pulse and both counters reset. Effective threshold per discharge: 3000 x 10 = 30,000 ISR ticks. This ISR controls how often a new arc begins.

The Correct Patch (v6)

To double discharge frequency, patch the 3000 threshold in the second ISR to 1500, and the midpoint comparison at 0x8001300 from 1500 to 750. Both are Thumb-2 movw immediate encodings:

0x80012c4: f640 31b8  (movw r1, #3000)  ->  f240 51dc  (movw r1, #1500)
0x8001300: f240 51dc  (movw r1, #1500)  ->  f240 21ee  (movw r1, #750)

This is what v6 implements. With the device already running at roughly 13.5Hz at max FREQ setting, halving the threshold pushes it toward 27Hz, at or above the perceptual fusion threshold where individual arcs begin to feel continuous. Testing confirmed increased frequency with full arc strength maintained, which also confirms that capacitor recharge time was never the bottleneck.

Next Target: Auto-Boot at Maximum Power and Frequency

Further analysis confirmed that both POWER and FREQ buttons are step incrementers, not toggles. Each press increments a RAM counter by one. Neither reads GPIO pin state in a loop. This means the device has no concept of "on" vs "off" baked into hardware logic: it reads counter values from RAM, and those counters can be written at init.

The goal: patch the init function at 0x8000978 to write maximum counter values at startup, so the device boots directly into maximum power, maximum frequency, actively discharging, with no button presses required.

Finding the Counters via Live Memory Diffing

The FREQ counter maximum is already known to be 10, from the cmp r0, #10 instruction at 0x8000ea4 found during ISR analysis. The POWER counter maximum and the RAM addresses of both counters still need to be located. Live memory diffing via OpenOCD is the right approach.

With the device running, read a region of RAM, press the target button once, read again, and diff:

halt
mdh 0x20000000 64
resume

Press FREQ once, then immediately:

halt
mdh 0x20000000 64
resume

Any halfword that changed by exactly 1 is the FREQ counter. Repeat independently for POWER. Keep pressing POWER and reading until the value stops incrementing to find its maximum. A third address to look for: a discharge-enable flag, a halfword that flips from 0 to 1 when both counters are above 0 and the device starts firing. This will also appear in the diff.

Patching Init

Once all three addresses are known, the init function gets store halfword instructions inserted to write the max values directly:

• FREQ counter address written to 10
• POWER counter address written to its maximum step value
• Discharge enable flag written to 1, if a separate flag exists

The button handlers only increment the counters; they do not reset them on each loop iteration. The ISRs read counter values and use them to scale behaviour; they do not re-read hardware pin state. A value written at init persists. The patch is sufficient without touching the ISRs themselves.

Why the NOP Approach Failed

An earlier attempt patched the branch at 0x8000a5a in the discharge ISR to a NOP, bypassing what appeared to be a power gate check before the call to 0x8001b20. It had no effect. The likely reason: 0x8001b20 reads a peripheral register (GPIOA base at 0x40020000) rather than a RAM flag, so that particular check is a hardware GPIO read. The NOP bypassed it, but counter-based guards deeper in the ISR call chain remained intact and continued blocking discharge.

The live diff approach bypasses the guesswork entirely. All relevant addresses will appear unambiguously in the before/after comparison in a few minutes of button pressing.

What's Next

• Run the live memory diff to locate the FREQ counter, POWER counter, and discharge-enable flag addresses
• Patch init to write max values at boot
• Explore the SIG input mode, which takes an audio signal and modulates discharge on it, a different code path entirely

Tools

• Raspberry Pi 3B: SWD programmer via GPIO bit-banging
• OpenOCD (compiled from source): SWD interface and flash programming; packaged version lacks the artery driver
• arm-none-eabi-objdump: Thumb-mode disassembly with --force-thumb
• Ghidra: initial analysis attempt; useful for the vector table but defeated by ARM/Thumb auto-detection
• Python3 struct: raw binary constant extraction and patch writing
• Multimeter: SWD pad identification by voltage

> End of output.

‎