Baofeng DM-32UV hardware

This page covers what is needed to bring up the DM-32UV: SoC, memory, peripherals, pins, RF chip, audio, flash, calibration, GPS and the update paths. The DMR modem inside the SoC is in modem-hrc7000.md. The AMBE codec placement is in codec-dm32.md. What has been checked on the radio is in feature-matrix.md and dm32-bringup.md.

Values are the ones RadioFoundry uses. "(measured)" marks a value measured on a radio, "(datasheet)" one from the HR_C7000 user guide (v2.7, 2016) alone, and "(unverified)" one not confirmed on a radio.

1. SoC

1.1 Clocks and PLL (at boot, before anything else)

All registers are in the modem/system block at 0x11000000. The sequence below is RadioFoundry's. The resulting 168 MHz core clock matches what the UART divisors and timers assume.

Resulting clocks used everywhere below: CPU/AHB 168 MHz, APB 84 MHz (timers, UARTs, SPI, I2C), SoC reference 24 MHz. Soft reset of the whole chip: QUAD_ENABLE = 0, then SYS_SOFT_RSTN = 0. The soft reset keeps LCSFC_BAUDR: after a session at divider 2 the ROM and bootloader can't read flash in single-bit mode and the radio stays dark until a power cycle. Set LCSFC_BAUDR = 4 before the reset (measured).

The Baofeng bootloader starts the PLL itself but leaves the XIP controller in single-bit mode at the reset divider (QUAD_ENABLE = 0, LCSFC_BAUDR = 4). Steps 2 and 3 must run anyway. Measured, 11.5 KB of straight-line code from flash: 2.9 ms as left, 0.9 ms with quad mode, 0.48 ms with quad mode and divider 2. Before the fix the idle radio used about 80% of the CPU and DMR voice encoding could not keep up (measured). The rule is gotchas.md 2.7.

1.2 Boot header and start-up

1.3 Cache controller (set before running from XIP flash)

Controller at 0xE000F000:

2. Memory map

| 0x04000000 | | LCSFC flash controller register window (FLASH_SPI_BASE; not used directly) | | 0x11000000 – 0x1100FFFF | | Modem / system registers (clock, reset, IO mux, baseband) | | 0x12000000 – 0x1200FFFF | | i8080 LCD controller | | 0x13000000 – 0x1303FFFF | 256 KB | USB 1.1 full-speed device controller (Synopsys DesignWare OTG core built device-only). Present on the SoC but the DM-32UV has no USB data connector and no firmware uses it (3.11) | | 0x14000000 – 0x1415FFFF | | APB peripherals (section 3) | | 0x15000000 | | SDIO | | 0x16000000 – 0x1600FFFF | | Modem buffer RAM (DMR TX/RX RAM, AMBE voice RAM, prompt FIFO, codec registers; modem-hrc7000.md) | | 0x17000000 | | PIC | | 0x18000000 – 0x18007FFF | 32 KB | SRAM on the system AHB, shared with the modem | | 0x18000000 – 0x1800009F | 160 B | Microphone PCM for the encoder (written by hardware) | | 0x180000A0 – 0x1800013F | 160 B | Decoded PCM for the speaker (written by the CPU) | | 0x18000800 – 0x18007FFF | 30 KB | Free for software; the codec's tables are copied to 0x18000800 (up to 0x18004BFC for the largest) | | 0xE000F000 | | Cache controller | | 0xE000E000 | | C-SKY core timer (not used) |

Flash file offset in a Baofeng firmware update file = runtime address − 0x0300C000 + 0x100.

3. Peripheral base addresses

3.1 UARTs (16550 style)

Registers at base +: RBR/THR/DLL 0x00, DLH/IER 0x04, IIR/FCR 0x08, LCR 0x0C, LSR 0x14, USR 0x7C.

A reset with the host polling left the debug link deaf until a power cycle (bench 2026-10-22; quiet resets came back every time): the host was still sending, the divisor write was dropped while the UART was busy, and the low divisor byte went out as data. Every UART set-up (platform/hrc7000/uart_format.h) therefore drains the RX FIFO, writes, reads LCR, DLL and DLH back and tries again until they stick (about 100 ms at most). The general rule is gotchas.md 2.8.

3.2 SPI master (DesignWare SSI)

Registers at base +: CTRLR0 0x00, CTRLR1 0x04, SSIENR 0x08, SER 0x10, BAUDR 0x14, TXFTLR 0x18, RXFTLR 0x1C, TXFLR 0x20, RXFLR 0x24, SR 0x28, IMR 0x2C, ISR 0x30, DMACR 0x4C, IDR 0x58, version 0x5C, DR 0x60.

Set-up used for the data flash, in order:

1. SSIENR = 0.
2. CTRLR0 = 0x07 (8-bit frames, mode 0, TX/RX), CTRLR1 = 0.
3. BAUDR = 2 (APB / 2 = 42 MHz SCLK).
4. Thresholds 0, IMR = 0, DMACR = 0.
5. SSIENR = 1.

Per byte: wait for SR bit 1 (TX not full), write DR, wait for SR bit 2 (TX empty), wait for SR bit 0 to clear (not busy), read DR. SER is 1 during the transfer and 0 after it. Chip select is also driven by hand on GPIO 18 (see 8.1).

3.3 I2C2 and the internal RTC

The RTC hangs off the internal I2C2 at 7-bit address 0x70 (datasheet: device address 1110000b; TAR = 0x70).

I2C2 set-up: ENABLE = 0; CON = 0x65; INTR_MASK = 0x40; FS_SCL_HCNT = 0x61; FS_SCL_LCNT = 0x68; TX_TL = RX_TL = 6. Registers at base +: CON 0x00, TAR 0x04, DATA_CMD 0x10, FS_SCL_HCNT 0x1C, FS_SCL_LCNT 0x20, INTR_MASK 0x30, RX_TL 0x38, TX_TL 0x3C, CLR_INTR 0x40, ENABLE 0x6C, STATUS 0x70, ENABLE_STATUS 0x9C, and a non-standard START at 0xA0.

Write of one RTC register: ENABLE = 0, read CLR_INTR, TAR = 0x70, ENABLE = 1, DATA_CMD = register, DATA_CMD = value, START = 1, wait STATUS & 0x05 == 0x04, START = 0, ENABLE = 0, wait ENABLE_STATUS bit 0 clear. Read: drain RX FIFO (STATUS bit 3), same opening, DATA_CMD = register, DATA_CMD = 0x100 (read), START = 1, wait STATUS bit 3, read DATA_CMD.

Datasheet first-power-up order: reset the RTC I2C interface, soft-reset the RTC (RTC_SOFT_RST_N = 0, wait 25 ms, = 1), optionally set the match (alarm) registers, load time, CCR.

3.4 Timers

DesignWare-style, clocked from APB 84 MHz. Per timer: LOADCOUNT +0x00, CURRENTVALUE +0x04, CONTROLREG +0x08, EOI +0x0C (read to clear), INTSTATUS +0x10.

CONTROLREG: bit 0 enable, bit 1 user-defined (periodic reload) mode, bit 2 interrupt mask (0 = interrupt on). Start: CONTROLREG = 0x02, LOADCOUNT = 84 000 000 / Hz, CONTROLREG |= 0x01.

3.5 Watchdog (0x14010000)

LOCK +0x00, OT_LOAD_H +0x04, OT_LOAD_L +0x08, RST_LOAD +0x0C, EN +0x10, KNOCK +0x14. Unlock key 0x5ADA7200, feed value 0x55AADD22. Disable: LOCK = 0x5ADA7200, EN = 0, LOCK = 0. Whether the Baofeng bootloader leaves it running is unknown.

From the HR_C7000 manual (document 2, WDT registers and the reset chapter): LOCK reads 1 while locked (its reset value) and 0 while open; any value but the key locks it. OT_LOAD_H is 3 bits (2:0) over the 32 of OT_LOAD_L: one 35-bit start value the counter counts up from, the timeout being its overflow at 2^35 (reset values H = 7, L = 0xC0000000: about 60 s). RST_LOAD (24:0, reset value 0x03F80000) counts on to 0x03FFFFFF before the reset, about 20 ms. EN is the only switch: no interrupt, no mode bit, no other enable; the watchdog reset is a global reset. The counter runs at the 24 MHz crystal (another HR_C7000 board, measured: H = 7, L = 0xF0000000, 2^28 counts, reset after 11.1 s). Not known (unverified): whether a soft reset or a watchdog reset clears EN. RadioFoundry (CONFIG_WATCHDOG, platform/hrc7000/watchdog.c) arms it after the clock set-up with every write under LOCK: EN = 0, the loads, a feed, EN = 1. It feeds with LOCK = key, KNOCK = 0x55AADD22, LOCK = 0. The load is 2^35 - 4 s x 24 MHz. The bench measurement and the rest are in watchdog.md.

3.6 PWM (backlight)

PWM0: CFG +0x00, RPT +0x04, PER +0x08, FP +0x0C, STATUS +0x10. PWM0 comes out on PTA15 (= GPIO 0x0F, LCD backlight) when IO_DIPLEX0 bit 17 = 0. Dimmed mode: IO_DIPLEX0 bit 17 = 0, CFG = 0x328, PER = 0xC8 (200), FP = percentage, CFG = 0x32C, CFG = 0x32D. Full on or off: IO_DIPLEX0 bit 17 = 1 and drive GPIO 0x0F as an output. With PER = 200 and FP = 0..100 the duty only reaches about 50 % (unverified). Key backlight (GPIO 0x28) is on/off only.

3.7 ADC (0x140D0000)

10-bit, 8 channels A–H wired to ADC0_IN..ADC7_IN on PTC15..PTC22 when the IO mux selects them.

Registers: CTRL 0x00 (bit 3 soft reset, bit 2 continuous scan, bit 1 glitch filter, bit 0 low power), INTR_DELTA 0x04, INTR 0x08 (bit 16 + per-channel enables), INTR_STA 0x0C, START 0x14, CTRL_STATE 0x18, INTR_THRESHOLD 0x1C, CTRL_STOP 0x20, CH_VLD 0x24, PD_SEOC_TIME 0x28, P2S_EN 0x2C, DATA_AB 0x30 (A in 9:0, B in 25:16), DATA_CD 0x34 (C in 9:0, D in 25:16). In single scan only the lowest enabled channel is converted.

IO_DIPLEX2 = 0x0FC80100 at boot leaves ADC1_IN and ADC2_IN analog (bits 20, 21 clear) and ADC0, ADC3..7 as GPIO (datasheet bit map). So the analog inputs available are channels B and C. Which one is the volume pot is unknown.

3.8 DAC (0x140F0000, 3 channels, 12-bit)

Registers: PD_CTRL 0x00 (bit n = 1 powers channel n down; A=0, B=1, C=2), PD_MODE_EN 0x04 (low-power mode per channel), DATA_A 0x08, DATA_B 0x0C, DATA_C 0x10. Output pins DAC_VOUT_MCUA/B/C on PTC23/24/25 when IO_DIPLEX2 bits 27/28/29 are 0.

At init RadioFoundry writes PD_CTRL = 0x01 (A off, B and C on), PD_MODE_EN = 0x01, clears IO_DIPLEX2 bit 28 (channel B pin to DAC). FM receive sets PD_CTRL bit 1 (B off); DMR and FM transmit must clear it again.

3.9 GPIO banks and the pin index scheme

Pin index 0–95: 0–31 GPIO A (PTA0–31), 32–63 GPIO B (bit = index − 32), 64–95 GPIO C (bit = index − 64). All tables below use this index (unverified).

Per bank (DesignWare APB GPIO): DR +0x00, DDR +0x04 (1 = output), INTEN +0x30, INTMASK +0x34, INTTYPE_LEVEL +0x38 (1 = edge), INT_POLARITY +0x3C (1 = rising/high), INTSTATUS +0x40, RAW_INTSTATUS +0x44, DEBOUNCE +0x48, PORTA_EOI +0x4C, EXT_PORTA +0x50 (input level), INT_BOTHEDGE +0x78.

Bank interrupt vectors: GPIO B = 46, GPIO A = 47, GPIO C = 49.

3.10 i8080 LCD controller (0x12000000)

The bus pins (CS, RS, WR, DB0–DB7) are handed to the controller by clearing IO_DIPLEX2 bits 3–7 and 9–18 (IO_DIPLEX2 &= 0xFFF80107). RD (PTC6) stays a GPIO held high; NRESET is GPIO 0x42. A short delay (a few cycles) after each byte is needed.

3.11 USB controller (present on the SoC, not usable on the DM-32UV)

Summary. The HR_C7000 has a USB 1.1 full-speed device controller, but the DM-32UV gives it nothing to talk to. The USB-C socket people see is on the BC-32UV battery pack: it charges the pack through the pack's own charger, with red (charging) and green (full) LEDs on the pack (per the battery listings; the USB-C cable in the box can't program the radio). The radio body has no USB connector; programming and firmware updates use the two-pin K1 jack, which carries UART0 through a USB-serial cable. So RadioFoundry keeps CONFIG_USB=n on this board. The controller facts below are kept for a future HR_C7000 radio that does wire the USB pins, and to settle the question for good.

What the original firmware does with it

It does not use the controller. It builds no address in 0x13000000–0x1303FFFF, changes only bits 6 and 7 of CLK_MGR 0x02C (never bits 16/17, the USB gates), installs no handler for the USB interrupt (vector 53, PIC source 21) and carries no USB descriptors. Its "task usb" is the PC programming protocol on UART0, so the "USB" in the name is the USB-serial programming cable, not the controller; the protocol is in dm32-stock-cps.md. The UI has no charging state (only battery-low warnings). The Baofeng bootloader's update mode speaks the serial protocol of 13.2 on the same cable (unverified). The ROM boots from the serial port or SPI flash only; there is no USB boot mode.

Controller (datasheet, USB chapter)

Clocks, reset, pins, power

Register map against the standard DWC2 layout (what a TinyUSB dwc2 port has to know)

The documented registers sit at the standard offsets (GAHBCFG 0x008, GUSBCFG 0x00C, GRSTCTL 0x010, GINTSTS 0x014, GINTMSK 0x018, GRXSTSR/P 0x01C/0x020, GRXFSIZ 0x024, GNPTXFSIZ 0x028, GHWCFG1–4 0x044–0x050, DCFG 0x800, DCTL 0x804, DSTS 0x808, DIEPMSK 0x810, DOEPMSK 0x814, DAINT 0x818, DAINTMSK 0x81C, DTHRCTL 0x830, DIEPEMPMSK 0x834, DIEPCTLn 0x900 + 0x20n, DOEPCTLn 0xB00 + 0x20n, PCGCCTL 0xE00). The differences:

Open questions for the first hardware test

These need only the debug link on UART0 and a host computer; nothing here transmits.

1. Plug a USB-C cable from a computer into the battery pack with the radio on and off. Expected: the pack's charge LED lights and no USB device appears on the host (macOS: System Information, USB; Linux: lsusb). If any device does appear, report its VID:PID and product string: that would mean the pack or the radio has a USB data path we don't know about.
2. With RadioFoundry running, read CLK_MGR 0x02C and GSNPSID (0x13000040) through the debug link once a register-peek command exists. Expected 0x4F54270A with the USB gates on; this confirms the core is present and clocked on this die revision.
3. Read CLK_MGR 0x02C before RadioFoundry's clock set-up runs, to learn whether the Baofeng bootloader leaves the USB gates on.
4. Optional, only if the radio is opened for another reason: look for test pads or vias near the SoC on the USB_DP / USB_DM nets (balls F1/F2). Report a photo; don't probe them live.

4.1 PIC (0x17000000)

Init used: MODE = 0 (level), PO = 0xFFFFFFFF (high active), MASK = 0xFFFFFFFF, the same for the _1 registers, INT_ST = INT_ST_1 = 0xFFFFFFFF. (Both masks must be written at init; the reset value is all masked.) Enabling vector v: clear bit (v − 32) in PIC_MASK for v < 64, bit (v − 64) in PIC_MASK_1 for v ≥ 64.

Dispatch: all 64 user vectors (32–95) point at one common entry; it saves context, writes 0x04 to PIC_COW1, takes the vector number from PSR bits 23:16, subtracts 32 and calls through a 64-entry software table.

4.2 Vector table

Vectors 0–31 are C-SKY exceptions: 0 reset, 1 misaligned access, 2 access error, 3 divide by zero, 4 illegal instruction, 5 privilege violation, 6 trace, 7 breakpoint, 8 unrecoverable error, 9 soft reset, 10 normal interrupt, 11 fast interrupt, 12 hardware accelerator, 16–19 trap 0–3. User interrupts are vector = PIC source + 32 (datasheet table 30), all level-triggered, high active:

The four modem interrupts are masked as a group by PIC_MASK bits 29–31 and PIC_MASK_1 bit 0 (datasheet mapping). PIC_MASK_1 bits 29–31 are vectors 93–95 and mask nothing here.

5. Pin map

Index = GPIO pin index (3.9). "Dir" is as configured; "Act" is the active level. The USB pins are dedicated balls, not GPIOs, and have no IO mux setting: USB_DP ball F1, USB_DM ball F2, USB_AVDD33 (3.3 V) ball G3, USB_AVSS33 analog ground. Whether F1/F2 are routed anywhere on the DM-32UV board is unknown (3.11).

5.1 IO mux and pull set-up at boot

Then individually: audio path pin 0x2E = 1; rows 0x47–0x4B = 1; LCD DB6 (0x4D) = 0; power monitor 0x10 input; power latch 0x11 = 1; flash CS 0x12 = 1; columns 0x31–0x34 inputs; PTT 0x2B input; LNA and PA selects (0x22, 0x24, 0x37, 0x23) = 0; FD6818 GP0/GP1 inputs.

Transmitter safe state (board_rf_safe, crash-log.md 8), at every fault, reset and stub entry and first in main(): the PA selects UHF (0x23) and VHF (0x37) low, DAC B (the PA drive) 0 and powered down; on the fault and reset paths also the modem's FM_PTT and LAYER2_TXRX_CTRL 0. The FD6818 keeps its state until the next start. The fault trace goes out on UART0 (the programming cable). Writing DAC B before hrc_clock_init is harmless because the vendor loaders leave the peripheral clock gates on (1.1).

6. Keys, encoder, LEDs, power

6.1 Keypad matrix

Rows are LCD data lines DB0–DB4 (GPIO 0x47–0x4B), columns are 0x31–0x34. To scan: save IO_DIPLEX2, set its bits 9–15 (DB0–DB6 back to GPIO), then for each row drive it low, wait a few microseconds, read the four columns (low = pressed), drive it high again; restore IO_DIPLEX2. Rows idle high.

The physical labels of the row 1 / row 2 column 1 keys and the up/down pair are named by position; check against the keypad.

6.2 Side keys and PTT

Because SK1/SK2 pull a column low on their own, a matrix scan must ignore columns that are already low before any row is driven. The radio's third programmable key (P1/P2, orange/top) has not been located.

PTT shares the cable's serial line (measured). The PTT pin (0x2B) is also the K1 jack's line that carries the host's serial data to UART0, so every 0 bit the host sends pulls the pin low. Measured on a radio, 3 s per case, key scan every 10 ms:

Two low scans in a row pass the key debounce, so a host polling the debug link can start a transmission. It did, twice, on the bench. A real press holds the line low, which UART0 reads as a break or framing error, never as a good byte. So the key scan counts the pin low as PTT only once no good byte has arrived for 50 ms (drivers/input/sharedptt, hrc_host_uart_last_rx), and the pin has read low that way for 20 ms (SHARED_PTT_HOLD_MS). The diag line ptt ign N counts the low scans ignored.

The hold is in time because scans aren't always 10 ms apart. With PPP up and the debug link polled over it, the input task ran late about 11 times a second and caught up with scans back to back. A logging build caught a press made by two scans in the same millisecond, 65 ms after the last host byte, with the pin low on four quick reads: the start of a new host byte, not yet received (2026-10-22, RADIO). Before the hold, 2 such presses came in 100 s, each a short DMR voice transmission; no line errors (ue 0) and no overruns.

6.3 Rotary encoder

A = GPIO 0x27, B = 0x26, inputs with GPIO B interrupts (vector 46). On every change of B: direction = −1 if A == B else +1. One count per B edge.

6.4 LEDs and backlights

Two LEDs, red and green, active high on GPIO 0x20/0x21 (which is which: see the pin map conflict). LCD backlight GPIO 0x0F / PWM0, keypad backlight GPIO 0x28.

6.5 Power

Power knob: the firmware holds GPIO 0x11 high to stay on; GPIO 0x10 reads 1 when the knob is turned off, and the firmware then saves state and drops 0x11.

6.6 Vibration motor (open)

Online sources say the DM-32UV has a vibration motor (unverified). A round two-wire part was seen on a board, but it may be the microphone, and no drive pin is known. RadioFoundry has no vibration support for the radio until both are confirmed (boards/dm32/board.toml, [hardware] unconfirmed).

Open item: identify the part and the GPIO that drives it, then add hal_power_t.vibrate and CONFIG_VIBRATE ?= y.

7. LCD panel

240 × 320 color TFT with an ST7789-class controller on the 8-bit i8080 bus (command set matches ST7789; no datasheet is available). RGB565, two bytes per pixel.

The case's bezel hides the panel's edges: RadioFoundry's safe-area insets are 10 px left and right and 5 px top and bottom (CONFIG_DISPLAY_INSET_* in boards/dm32/config.mk, ui.md 1). At bring-up text 6 px from the left or right edge was still clipped (measured in a half-resolution frame: 5 px left, 4 px right, 3 px top and 2 px bottom there).

RadioFoundry drives the panel at full resolution in 16 colors: the core's frame buffer holds a 4-bit palette index per pixel (37.5 KB; RGB565 would take 150 KB), and each changed row goes out as RGB565 through the palette (gfx.c, st7789_write_rows_indexed).

Reset: NRESET high, wait 120 ms, low, 120 ms, high, 120 ms. Then:

Inverse video is done by toggling 0x21 / 0x20 with 10 ms around it.

8. FD6818 RF transceiver

Single-chip VHF/UHF transceiver; register-compatible in spirit with the RDA1846S/AT1846S family but with its own addresses for frequency and band. No FD6818 datasheet is available; the values are the ones that work on the radio.

8.1 Bus and timing

Three-wire serial, bit-banged on GPIO: CS = 0x18 (active low), clock = 0x07, data = 0x08.

Registers 0x65 / 0x67 are not read by the radio's own firmware (unverified: its S-meter may be fake).

8.2 Register tables (address: high byte, low byte)

Power-on init (in order):

Rows 18, 20, 22 and 24 (B3 / B4) and the C7 = 0140 of Enter DMR below have address bit 7 set, which the FD6818 reads as a read cycle: the chip drives the data line while the MCU drives it too. The radio's own firmware does not send them. RadioFoundry leaves them out; FM and DMR receive and transmit work without them (measured).

Register 0x09 is written 16 times with the top nibble as an index: a 16-entry internal table (purpose unknown; looks like an AGC/gain table).

Post-init (after init): 47=0000, 13=037E, 47=6042, 7E=302E, 2B=C000, 43=3028, 78=6968, 30=0000, 38=BA00, 39=00DB (144.000 MHz), 32=0244, 07=0470, 07=21CE, 51=0000, 3F=0000, 37=1F0F, 30=0000, 30=BFF1, 47=6042 (AF mute), 48=BBBF (volume).

Enter FM: 30=0000, 13=037E, 47=6042, 7E=302E, 2B=C000, 43=3028, 07=0470, 07=21CE, 51=0000, 3F=0000, 37=1F0F, 30=0000, 30=BFF1, 47=6042, 48=BBBF.

Enter DMR: 47=0000, 30=0000, 30=0000, 13=037E, 47=0140, 48=BBBF, 7E=B03F, 2B=0700, 43=4048, 78=6968, 30=0000, 32=0244, 37=1F1F, 30=0000, 30=BFF1, 47=0140, 3F=0000, C7=0140, 47=0140.

8.3 Frequency, band, state, bandwidth

Band select by frequency (f in 10 Hz units; first matching row wins):

Below 16 MHz nothing is written.

8.4 RSSI, noise, sub-audio

Receive sequences, in the radio's own order. CTCSS: 0x07 = the tone word, 0x07 = 0x21CE, 0x52, then 0x51. DCS: 0x07 = 0x0AD7 first, the two 0x08 halves, then 0x51. Off: 0x07 = 0x0470, 0x07 = 0x21CE, 0x51 = 0.

The C7000 does the FM modulation (two-point, modem-hrc7000.md) and makes the TX sub-audio. Receive tones come from the FD6818: the speaker switch (PTB15) takes the FD6818's audio away from the C7000's ADC in FM receive, so the C7000's detector hears nothing. The FD6818 detects on its own demodulated audio. RadioFoundry turns the FD6818's sub-audio off before FM TX because 0x51 b15 also enables its transmitter.

8.5 TX/RX switching, PA and LNA

RadioFoundry departs from "Enter DMR TX" in one place: it leaves the FD6818 in RX (0x30 = BFF1) with the RX band's LNA on, and turns the LNA off at each burst's RF TX interrupt and back on after the burst. The hotspot keys the transmitter to listen (radio_sm.c, hotspot_arm); with C1FE and the LNAs off at key-up, the radio heard nothing until its first burst. Found on a board with the same chips (measured there); DMR TX off air still passes on the DM-32UV with the change (measured).

Split channels (RX and TX frequencies differ: a repeater or a duplex hotspot) have one synthesizer for both. RadioFoundry keeps it on the RX frequency from key-up on, so the radio hears the downlink's CACH and sync between bursts and can time its bursts to it. The RF TX interrupt moves it to the TX frequency for a burst (idle, frequency words, C1FE), and the switch after the burst moves it back (fd6818_dmr_burst_at). A simplex channel writes no frequency frames. Before this (issue 72), tx tuned the synthesizer to the TX frequency at key-up and left it there: the radio was deaf to the hotspot's downlink, never aligned to it, and its bursts were not taken. The radio's own firmware retunes at every burst end too. The PLL lock time after each retune is not measured yet (HIL check open).

Band for PA/LNA purposes: VHF below 280 MHz, UHF from 280 MHz (the 220 MHz range shares the VHF path).

8.6 DMR PA timer

The PA is switched off from the next timeslot interrupt once the burst has run at least 20 ms (the RF RX interrupt is not used).

8.7 Air band AM and the broadcast receiver

The generic design is in airband-and-broadcast.md; the bring-up checks in dm32-bringup.md 11 answer the questions below.

Public claims

• Baofeng's product page and the RadioGuru review's table list "Additional RX bands: AM 108-136 MHz, FM 65-108 MHz" and the aviation band as a feature (baofengradio.com, review).
• The radio receives aviation AM with its original firmware. Treat AM air band RX as a capability of the radio.

Which chip demodulates AM

Not decided by any source. The evidence:

Working hypothesis (unverified): AM is demodulated by the FD6818 (0x47 AF type 7), its AF output goes to the speaker amplifier through the source switch (0x2F) instead of the C7000 codec, and the 108-136 MHz signal comes in through the VHF front end (VHF LNA, GPIO 0x22; the 136-174 MHz filter costs sensitivity at the low end). The alternative is AM audio fed into the C7000's audio path. Bring-up check 11 decides between them.

Open questions

What RadioFoundry does (unverified until bring-up): rx_am in boards/dm32/radio_dm32.c is the FM receive path (VHF LNA, speaker source to the FD6818, A2) with the AF output word 0x47 = 0x0740 (AF type 7, A1); rx() writes 0x0140 back. The AGC and filter are the FM ones (A3). The RDA5807M runs through the shared HR_C7000 glue (platform/hrc7000/bcast_hrc.c) on PTA25 / PTA26 with no enable pin; its audio path turns the amplifier on and leaves the speaker source alone (B4). The air band is an RX-only band of 108-136 MHz and the broadcast range 65-108 MHz in boards/dm32/board.c.

8.8 Receiver power saving

The radio's own battery save, in order. RadioFoundry uses it in FM receive (the core only sleeps there).

The radio's sleep lengths are 12, 18 or 30 ticks of its receive service by the battery save level, with a busy detect waking it at once (the tick's length in ms is not known). RadioFoundry's lengths come from the core settings.

9. Audio path

9.1 Internal audio codec registers (byte registers at 0x160009C0 + offset)

Values written at init; field meanings from the datasheet:

APRS AFSK transmit (measured on the SDR bench, 2026-10-16, 467.375 MHz, 25 kHz, lowest power, a canned frame through hal_afsk_t.tx_start): a valid FCS at every level tried, 29 flags of TX delay, twist about -1.1 dB, 14-15 degrees phase residual. Level 50 (PCM amplitude 2750) gives 3.1 kHz peak with 2.2 / 2.5 kHz mark / space deviation; level 75 gives 4.5 kHz peak; PCM 5850 and up is limited at 5.1 kHz peak. Receive decodes off air. While AFSK receive runs, the speaker plays FM through the HR_C7000 instead of straight from the FD6818. A flat transmitter at a strong level shows 320-400 Hz 1-10 dB under the tones: 50-80 % decode with one demodulator path, 12 of 12 with both. Both paths take about 6 % of the CPU at 8 kHz.

9.2 PCM paths for USB and serial audio

For the USB audio design (usb-audio.md 2). Not measured.

• Host port: the SoC's USB controller has no connector (3.11), so the host port is the programming cable's UART0 at 115200 baud (3.1). USB audio and the network personality are out; serial audio (USRP in SLIP frames) is the transport.
• DMR: the SoC's mic and speaker PCM buffers feed the CPU's AMBE codec, as on the STM32 radios (modem-hrc7000.md 1, 6.2).
• FM: the C7000's FM block demodulates receive audio and plays it through the codec DAC (AUDIO_CONTROL bit 6), and the microphone goes into the codec ADC, with GPIO 0x2E choosing the FM or DMR path (9). The C7000 documents more than the HR_C6000 here: "FM RX data" and "FM TX data" interrupt sources, and AUDIO_CONTROL bits for mic PCM to the CPU (bit 4), CPU-fed speaker PCM (bit 5) and the voice source (bit 0: codec or TX RAM) (modem-hrc7000.md 2.4, 8.1). FM receive audio reaches the CPU through the RX RAM (modem-hrc7000.md 8.5); APRS receive uses it. APRS transmit sends its tones as PCM through the prompt FIFO into the modulator (modem-hrc7000.md 8.4).

10. Data flash (16 MB)

10.1 Data flash map

The vendor CPS protocol on UART0 (115200) is a raw 24-bit window on this flash: 52 addr3 len2 reads, 57 addr3 00 10 <4096 bytes> writes, entered with PSEARCH / PASSSTA / SYSINFO and FF FF FF FF 0C "PROGRAM". The full command set of the radio's programming task is in dm32-stock-cps.md.

11. Factory calibration

11.1 Location

Scan 4 KB pages 0x1000, 0x2000, … 0xC8000; the first whose byte at +0xFFF equals 2 is the calibration page It is never written.

Read three pieces into a 0x175-byte working image:

11.2 Fields (offsets in the working image)

11.3 How the values are used

For a UHF frequency below 400 MHz an unsigned subtraction gives idx 4. Clamp to 0.

12. GPS

RadioFoundry's driver is platform/hrc7000/gps_hrc.c (another HR_C7000 board uses it on UART2; the board gives it the UART, power pin and level in hrc_gps_cfg_t), on the shared receive ring drivers/gps/gps_rx (also used by an STM32 board) and the line framing drivers/gps/nmea_line:

Settings > Location > GPS switches the module's power on the HR_C7000 boards (hal/board.h gps_enable). An STM32 board's driver doesn't implement the hook (its power pin is left as the hardware has it): the setting there only stops APRS using the fix.

13. Firmware file format and update paths

13.1 Baofeng firmware file (BFUV32-V2)

A vendor image unpacks and repacks byte for byte with only these rules.

13.2 Baofeng bootloader (update mode)

Enter by holding PTT + SK1 while turning the radio on; the green LED lights (unverified). Protocol on the programming cable, 115200 8N1:

The image sent is the raw application (the 256-byte header is stripped). The file name and size are not used. The vendor CPS also sends seven 130-byte zero blocks before rebooting; they are not needed (unverified).

If the radio does not boot the new image, remove and refit the battery; update mode still works (unverified).

tools/serial_loader.py implements this protocol (untested on a radio; dm32-migration.md 1). serial_loader.py --probe runs steps 1-3 only and prints the answers, for checking whether another HR_C7000 radio's update loader speaks this protocol and which model string it reports at step 3.

Release: the application area is 0x0300C000..0x030E8000 (880 KB) and the codec slot is 0x030E8000..0x03100000. The updater erases the whole application area before writing, the slot included, so the codec can't be kept: every flash merges the codec from the user's vendor firmware file (keep_codec = false in boards/dm32/board.toml), through the serial-loader family, not DFU. Open for bring-up: whether the updater erases only size bytes, which would allow a keep mode with an image that ends before the slot.

13.3 ROM serial boot (recovery, no bootloader needed)

The HR_C7000 ROM listens on the serial port after reset. Dahua's DH_SOC_TOOLS (Windows) with a script first loads a "miniBoot" image to RAM 0x00014000 and starts it, then writes the application to flash (at 0x03001000, unverified). Works with FTDI-based cables only; CH340 cables, which work with the Baofeng bootloader and CPS, do not reach the ROM loader (unverified). The ROM protocol itself is not documented here. Production radios are programmed over JTAG (unverified).

13.4 Backing up

Back up the program flash (1 MB) and the data flash (16 MB) before flashing anything; both can be read through the bootloader/ROM path (unverified).

14. Other chips

15. AMBE codec placement (summary)

The codec is not in this repository. Two placements work (details in codec-dm32.md):

16. Traps and open items

Hardware behaviors that bite a fresh implementation, and what is still open.

17. How RadioFoundry uses it (make BOARD=dm32)

Runs on a radio: docs/testing/dm32-bringup.md is the bring-up checklist and lists what is still open.

17.1 SRAM layout

The application has one RAM region below the codec's window (boards/dm32/memory.ld, platform/hrc7000/common.ld; the linker fails the build when it overflows). The codec window 0x43A00..0x58000 (83,456 B) holds the codec code copied from the codec slot at boot (codec-placement.md); RadioFoundry links nothing there. No DMA reaches SRAM on this board, so any buffer can sit anywhere in the region. crt0 (platform/hrc7000/crt0.S) copies .ramfunc and .data from flash and zeroes .bss and .ram_lo before main; nothing in .ram_lo may have an initializer (it is NOLOAD: an initial value would be dropped).

The image sizes and the RAM left in each build are in feature-matrix.md, "Whole images".

17.2 Runtime stub entry (CONFIG_STUB_ENTRY)

A bench and recovery path: the host loads its own flash-access RAM monitor (the "C7 stub", a small program that reads and writes the radio's flash chips with no firmware running) into SRAM and RadioFoundry jumps to it at run time, with the radio powered on, no power cycle and no DFU. It is the same monitor the serial boot ROM loads with the radio off; this just gets it running from a radio that is already up. On by default (CONFIG_STUB_ENTRY, with or without the debug link: docs/spec/stub-entry.md); the command answers unavailable on a board whose platform has no hal_system_t.enter_stub (every board but the HR_C7000 so far). The wire format is debug link command 0x1A (docs/spec/debuglink.md 3.18).

RAM region. The monitor is loaded into the codec window at the top of SRAM, 0x43A00..0x58000 (83,456 B), which boards/dm32/memory.ld leaves out of the image entirely (section 17.1): RadioFoundry links nothing there. A radio that hosts its codec runs it in that window, so the first STUB command parks the codec (hrc_vocoder_park: it waits for a call in progress, then every later call returns silence) before the window is handed out. Without that, an upload on a DMR channel overwrote the running codec and hung the radio (bench 2026-10-15). The load span is 0x44000..0x58000 (HRC_STUB_BASE / HRC_STUB_SIZE, 80 KB, 4 KB aligned inside the window). Nothing in RadioFoundry's own RAM (below the window) is touched while the image loads, so the host link task keeps running to receive it; RadioFoundry abandons all of its RAM only at the jump.

The monitor (the universal build, protocol version 6) is 7,004 bytes and runs at 0x30000, not where it was loaded. Its first 0x80 bytes are position independent and use no stack: interrupts off, then a copy of the image from the load address to 0x30000 and a jump there. It then zeroes its .bss and sets its own 4 KB stack. The whole footprint is 0x30000..0x37978 (31,096 B: image, .bss to 0x36974, stack 0x36978..0x37978); the linker refuses a layout over 32 KB or outside SRAM. That range is RadioFoundry's RAM, which is dead after the jump, and it does not overlap the loaded copy at 0x44000... The entry stops without writing anything if the two would overlap. Deepest stack use measured on two HR_C7000 boards: 168 bytes. The same image is what the serial boot ROM loads at 0x10000 with the radio off (28 blocks of 256 B; the ROM itself uses no RAM, only registers). Placement for every route: stub/README.md, RAM placement.

Clock and UART. The monitor leaves the UART divisor RadioFoundry programmed (115200 at 84 MHz, /46), so the link never drops a byte at the hand-over, and listens on UART0 and UART1 until told otherwise. After HELLO the host measures timer 2 (the monitor's tick source, 84 MHz here, 24 MHz after a boot ROM load) and sends CONFIG: the clock rates, the UART to keep (the one the request came in on), the board id and the board's pins. The next HELLO echoes them, and the host checks the echo before any write; an unconfigured monitor refuses writes.

Quiesce and jump (platform/hrc7000/system.c enter_stub, a .ramfunc so it runs after flash is handed back): CPU interrupts off (psrclr ie), every PIC source masked (both banks), with CONFIG_WATCHDOG the watchdog stretched to 32 s and fed (the stub feeds it; watchdog.md 3.2), otherwise off, then QUAD_ENABLE = 0 and LCSFC_BAUDR = 4 to put the XIP flash controller back to its reset mode so the program flash answers the monitor's SSI again and a later soft reset boots (the same steps hrc_soft_reset relies on), and a jump to the entry address. No DMA reaches SRAM on this board, so no DMA engine has to be stopped. RTOS tasks are not stopped gracefully; masking interrupts freezes the scheduler and the jump never returns (recover by a power cycle).

Load protocol. The host sends the image over the debug link in STUB_CHUNK_MAX (59 B) chunks after a BEGIN that carries the length, a CRC-32 of the whole image, the entry address and a 32-bit magic key ('C7SB'); each chunk's integrity is the debug link frame's own CRC-16, and the region is zeroed at BEGIN so a dropped chunk fails the final check. ENTER repeats the magic, and RadioFoundry verifies the exact length and the CRC-32 of the loaded bytes before it quiesces and jumps: the three guards (magic, length, CRC-32) are what keep a stray or truncated frame from ever launching it.

Bench results. Entry from RadioFoundry, program flash and data flash reads, --write-app and the restart ran on a second HR_C7000 board (2026-10-15). The universal build ran from RadioFoundry on that board and the DM-32UV (2026-10-17): reads of both chips, the bootloader identical to earlier dumps, a write test on the data flash, and the restart. Not yet run with the universal build: the boot ROM load at power-on.

View the source of this page