Baofeng DM-1701 hardware (and its STM32 siblings)

The Baofeng DM-1701, the Retevis RT84 and the TYT MD-UV380 / MD-UV390 (5 W and "Plus 10 W") are one board family: an STM32F405VGT6 (LQFP100) MCU, an HR_C6000 DMR baseband/codec chip, one AT1846S RF transceiver covering both VHF and UHF, a 160 x 128 color LCD on an 8-bit 8080-style bus, a 16 MB SPI NOR flash, a 3-row keypad matrix that shares its column lines with the LCD data bus, a rotary channel encoder, a volume potentiometer with a built-in power switch, and USB full speed device on the MCU's OTG_FS core. This file records what the hardware needs. The DM-1701 is the primary target; differences for the siblings are collected in section 17.

Conventions:

Register-level HR_C6000 behavior is in modem-hrc6000.md and is not repeated here.

1. MCU, clocks, memory

1.1 Part

1.2 Clock tree (normal run mode)

Boot gotcha: the bootloader leaves the system running from HSE/PLL. The HSE configuration cannot be changed while it is the system clock, so the application first switches SYSCLK to HSI, then reprograms HSE/PLL, then switches back to the PLL.

1.3 Reduced-power ("eco") clock

1.4 Internal flash layout

STM32F405, 1 MB: sectors 0-3 are 16 KB, sector 4 is 64 KB, sectors 5-11 are 128 KB. The V02.06 CSV codec runs in place from sectors 10 and 11, where the merge puts it (codec-placement.md, "STM32 radios"; codec-dm1701.md): tables at their original address 0x080D19F0..0x080E3A72, code moved from its original address 0x08074714 to 0x080E3A74..0x080F3C90, and the descriptor at 0x080FFF80.

A flash sector can only be erased whole, so boards/dm1701/memory.ld gives the application sectors 3-9 (0x0800C000..0x080BFFFF, 720 KB in one piece) and asserts that everything it loads into flash ends before 0x080C0000. The image is one .bin from 0x0800C000, and an update erases and writes only the sectors it covers. The bytes around the codec in sectors 10 and 11 are 0xFF after a merge and are never executed. The DM-1701's settings and codeplug live in the external SPI flash, so nothing else writes internal flash.

The manufacturer's firmware, and RadioFoundry builds from before the codec moved, keep the codec code in sectors 7 and 8, which the application now covers. A release or manifest with two ranges (the application and a sector 9 data part) is from before the move and is refused. Moving a radio to this layout writes the codec once, from the manufacturer's firmware file or from a copy the tools read from the radio earlier (release.md, "Codec handling").

rfoundry's keep and merge modes follow from this map (release.md, "Codec handling").

The codec's entry points, as offsets from the code start: encode +0x130, encode FEC +0x4E8, decode +0x5D8. Call with the Thumb bit set when calling through a pointer.

Codec calling convention (the interface to the third-party blob; unverified beyond "it works"):

The 72 encoded bits come back one bit per 16-bit word (LSB) and are packed MSB first into 9 bytes. On decode, the 9-byte (72-bit) AMBE+2 frame must first be de-interleaved and FEC-decoded to 49 bits by the caller (Golay(24,12) on C0, Golay(23,12) on C1 after removing the pseudo-random whitening seeded from C0's 12 data bits with x' = 173x + 13849 mod 65536, the standard AMBE+2 3600x2450 FEC; see the codec spec). The state buffers must be initialized by the codec's own init calls (codec-dm1701.md C). Gotcha: a call site that builds the stack arguments must not be optimized in a way that moves the stack pointer (with -Os around the call, DMR TX crashed); calling through a small assembly shim with an explicit frame avoids this.

1.5 RAM

Main RAM and CCM are both nearly full in a full build (frame buffers, flash sector buffer, calibration copy, USB buffers, data-service buffers); plan buffers explicitly.

2. Pin assignments

All 100 pins that matter, by port. "In" pins have the pull noted. Active levels are what the board needs.

2.1 Port A

2.2 Port B

2.3 Port C

2.4 Port D

2.5 Port E

2.6 Port H

2.7 Reset-time output levels

Set before configuring as outputs: C6000 CS and PWD high; C6000 CLK/MOSI low; LEDs off; both RX 5 V switches, all keypad rows, power latch, mic power low; PA enables, PA band select and beep low; voice CS, speaker mute and amp enable high; backlight low; RX audio mux and flash CS high; CTCSS PWM high. The application drives the power latch high as its first action, otherwise the radio turns off when the user releases nothing more than the power switch transient.

Transmitter safe state (board_rf_safe, crash-log.md 8), at every fault, reset and stub entry and first in main(): PA_EN1 (PC5) and PA_EN2 (PC4) low, PA band select (PC6) low, the APC DAC (PA4, DAC1 channel 1) 0 when its clock is on. The AT1846S and HR_C6000 keep their state until the next start.

3. Interrupts, DMA, timers

3.1 Interrupt priorities

RTOS kernel at 7 (lowest); RTOS "max syscall" priority 5: ISRs that call RTOS APIs must be at 5..15.

The three HR_C6000 interrupts only matter in DMR mode; in FM they can be ignored.

3.2 DMA

Memory-to-memory transfers on the F4 are only possible on DMA2. The frame buffer source must be in main SRAM (not CCM).

3.3 Timers

4. HR_C6000 connection

4.1 Overview

4.2 Configuration port timing

Mode 3 equivalent: clock idles high; for each bit MOSI is set, CLK driven low, MISO sampled, CLK driven high (the chip latches on the rising edge). No added delays were needed at 72 MHz with GPIO writes (about 1-2 MHz effective). CS low for the whole transaction.

Framing (same as the GD-77 family, see modem-hrc6000.md 1.1):

The port is shared by task code and ISRs: transactions must be atomic with respect to the HR_C6000 ISRs (mask or lock around each transaction).

4.3 Voice port

SPI2 master, 8 bit, MSB first, CPOL = 1, CPHA = first edge (mode 2), prescaler 8 -> 4.5 MHz, software CS on PB12. Framing: write = page 0x03, register 0x00, then 27 AMBE bytes; read = 0x83, 0x00, then 27 bytes clocked in (the data follows the two header bytes). Up to 32 data bytes per transfer.

4.4 I2S audio

The HR_C6000 codec register 0xE0 value 0xC9 says "I2S slave" in its documentation while the STM32 is also slave; in practice the chip drives CK and WS on this board (unverified which register bit makes it master).

4.5 Power and start-up

1. PWD low (PE6), wait at least 10 ms.
2. Program the PLL while running from XTALI, switch to the PLL. The datasheet asks for more than 500 us between writing 0x0B/0x0C and switching 0x0A back to the PLL; a driver should wait.
3. Continue with the init sequence in modem-hrc6000.md section 3.

Power down: PWD high. The microphone power (PA13) is usually switched with the receiver; some external speaker-mics generate false PTT events when their bias is removed, so keep PA13 high during receive power saving.

5. AT1846S RF transceiver

5.1 Bus and part

Caching the last value written per register and page avoids redundant I2C traffic (writes that do not change a value can be skipped; read-modify-write can use the cache). I2C3 is used from task code and, for burst-by-burst RF switching, from ISRs: an ISR must not start a transfer while the task owns the bus (check the peripheral state first and skip the action rather than block).

5.2 Init sequence (data)

"wait N ms" rows are delays, not register writes.

DTMF tone registers (0x67-0x76) are not needed: DTMF is generated by the HR_C6000.

5.3 Register 0x30 values used

Bit meanings (datasheet): 14 xtal_mode (1 = 26/13 MHz), 13 filter_band_sel (1 = 25 kHz analog filter), 12 band_mode (1 = 25 kHz DSP), 7 mute, 6 tx_on, 5 rx_on, 3 sq_on, 2 pdn_reg, 1 chip_cal_en, 0 soft_reset.

The 12.5 kHz setting keeps filter_band_sel = 1 (the 25 kHz analog filter) with the 12.5 kHz DSP mode, which is what works on these radios. Bit 1 (chip_cal_en in the datasheet) stays set in normal operation, as found.

5.4 Bandwidth tables (data)

Send the whole table, then update reg 0x30: keep the other bits, set bits 13:12 to 11 (25 kHz) or 10 (12.5 kHz), clear tx_on/rx_on, then set rx_on.

5.5 Mode tables (data)

FM (analog) mode:

DMR mode (the HR_C6000 needs the raw 4FSK baseband):

5.6 Frequency setting

The synthesizer word is in units of 1/16 kHz (62.5 Hz): word = f(Hz) / 62.5 = f(MHz) x 16000. Registers: 0x29 holds word bits 29:16 (in bits 13:0), 0x2A holds bits 15:0. Example from the datasheet: 409.75 MHz -> 0x640960 -> 0x29 = 0x0064, 0x2A = 0x0960.

Write sequence (RX or TX frequency):

TX frequency offset (empirical): with the normal TX sequence (RX frequency written, then TX frequency written with RX on, then TX on) the carrier is about 3 kHz low; RadioFoundry adds +3.00 kHz (12.5 kHz) or +6.15 kHz (25 kHz FM) to the TX word. With a different sequence (frequency written with the receiver off, then straight to TX) there is no offset and adding it puts the carrier +2.93 kHz high (measured on air). The cause is unknown; a new driver should measure the actual offset of its own sequence.

Band selection for the receive front end: VHF band -> PA5 high, PA2 low; UHF -> PA2 high, PA5 low (5.8, section 6).

5.7 Sub-audio (CTCSS / DCS)

Recipes (as values):

DCS word: the 9-bit code (octal digits as 3-bit groups, e.g. 023 -> 0x013), with bit 11 set (the fixed "100" marker: word bits 11:9 = 100), and the 11 Golay(23,12) parity bits of the 12-bit value (marker + code) in bits 22:12. Generator polynomial x^11 + x^10 + x^6 + x^5 + x^4 + x^2 + 1 (0xC75). Compute it; no table is needed.

The chip sends the word MSB first (bit 22 first) and compares received bits in the same order, while DCS sends code bit 0 first. So 0x4B/0x4C take the word bit-reversed: 023 -> 0x763813 -> reversed 0x640E37 -> 0x4B = 0x0064, 0x4C = 0x0E37. The unreversed word (0x0076 / 0x3813, as the AT1846S programming guide shows) went out as D023 read backwards on the SDR bench, and the radio accepted no other radio's DCS; with the reversed word it sends and receives D023N.

DCS turn-off tail (radio-features.md 3.3a): 0x4E bits 10:9 from 10 (DCS) to 11 (CTCSS) for the tail. 0x4A already holds 13440, so the chip sends 134.4 Hz as a CTCSS tone; back to 10 (and the polarity in bits 8:6, kept) on PTT again. The chip's own tail elimination (0x30 bit 11, 0x4E bits 15:14 phase shift) is a CTCSS feature and stays off. Not yet measured on the SDR bench.

5.8 Tones, voice channel and TX audio source

On these radios FM microphone audio is processed and modulated by the HR_C6000 (two-point modulation), not by the AT1846S. The AT1846S tone generator is still used for the 1750 Hz burst and for AFSK (with the HR_C6000 microphone input muted, HR_C6000 0xE0 bit 6 cleared): voice_sel = tone1 makes the AT1846S modulate it, as it does its CTCSS. With voice_sel left at 000 the carrier went out unmodulated (gotchas 3.10); the fixed path is verified on air (HIL 2026-10-10: the burst, the roger beep and APRS AFSK, docs/testing/on-air-coverage.md).

Morse keying for the hotspot's CW ID (tx_tone_key, boards/dm1701/radio_dm1701.c): with the tone set up by tx_tone, key up writes the 0x59 tone deviation bits 15:6 to 0 and key down back to the tone value (0x1C) (bits 5:0 kept from the saved value), so the carrier stays up and the tone switches without a retune. On air: test_hotspot_cwid checks the Morse tone (docs/testing/on-air-coverage.md).

RadioFoundry's tx_tone(hz) (boards/dm1701/radio_dm1701.c, the roger beep and the 1750 Hz burst of radio-features.md 3.3) uses tone1 with 0x79 = 0xC000 and tone deviation 0x1C, and mutes the HR_C6000 microphone path (page 4 0xE0 bit 6). tx_tone(0) and every return to receive restore the saved registers.

DTMF (tx_dtmf, radio-features.md 3.7) is the same path with tone2 as well: 0x35 = the low tone, 0x36 = the high tone, voice_sel = 011 (tone1 + tone2), single tone select and enable as above (0x7A bit 15, the chip's own DTMF mode, times each digit itself and isn't used). The deviation is DTMF_DEV in 0x59 bits 15:6, 0x1C like the single tone until measured for the pair. A new digit only rewrites 0x35 and 0x36.

5.9 RSSI, noise, squelch

Conversion to dBm (measured): UHF dBm = rssi - 151; VHF dBm = -164 + rssi x 32 / 27. The same formulas apply to noise_db. A software squelch on noise_db works well: carrier present when noise_db is below a threshold (RadioFoundry: 70 minus 3 per squelch step, 3 dB hysteresis), sampled every 25 ms.

Roaming reads this RSSI as the site signal (dmr-roaming.md section 3). A survey visit relies on the AT1846S RSSI and the HR_C6000's sync acquisition needing well under 100 ms on a continuous BS outbound (a burst every 30 ms); four 25 ms readings follow.

5.10 APRS AFSK transmit

RadioFoundry's hal_afsk_t (boards/dm1701/afsk_dm1701.c, aprs.md 5) uses the AT1846S tone generator as the voice source, as for the roger beep. TIM6 (APB1 timer clock 72 MHz, prescaler 2, ARR = clk / 2 / 1200 - 1, interrupt priority 5, no RTOS calls) interrupts at every symbol boundary. It writes the next tone to register 0x35 when the tone changes: one I2C write of about 0.1 ms in an 833 us symbol. The radio core keeps the I2C bus free meanwhile. At the end it force-writes 0x35, because the interrupt bypassed the driver's cache. The level (0-100, 50 default) scales the tone deviation register 0x59 around the driver's value.

The tone generator is the voice source only with reg 0x3A bits 14:12 (voice_sel) = 001 and 0x7A bit 14 (single tone) set. An earlier build wrote bits 6:4 and keyed a silent carrier (gotchas.md 3.10, fixed in 694249b). tests/hil/test_aprs.py measured the result on air (aprs.md 13).

5.11 Receiver sleep

RadioFoundry's rx_sleep(true) (receiver battery save, radio-features.md 5.4) puts the AT1846S in idle and switches the receive supply off. rx_sleep(false) retunes.

6. RF path control (PA, LNA, band)

Ordering:

• Enter TX: both RX supplies off; configure the HR_C6000 for FM TX or DMR; AT1846S reg 0x30 to the TX value; then PA enable 1 high, PA band select, then PA enable 2 high. The DAC drive is set when the TX frequency is written.
• Enter RX: PA enable 1 and 2 low first; RX supply for the band; AT1846S reg 0x30 to the RX value; HR_C6000 to FM RX or DMR.
• Burst-by-burst DMR TX (the PA follows the bursts): to TX, reg 0x30 receiver off, the TX frequency, reg 0x30 DMR TX, both RX supplies off, then the PA; back to RX, the PA enables low, reg 0x30 receiver off, the RX frequency if it differs, the RX supply for the band, reg 0x30 RX on. The receiver must work between bursts (an SFR's inbound slot, sfr.md 3). The "transmitting" state of the radio must therefore be taken from the HR_C6000 slot state, not from the PA pins: the last burst of a call (the terminator) is still in flight after the PA logic has gone back to RX once.
• Power-down: PA enables low, both RX supplies low, mic power optionally low, HR_C6000 PWD high, AT1846S reg 0x30 = receiver off value.

Powering both receivers together and powering only the band in use both work; RadioFoundry powers only the band in use.

7. TX power control (DAC)

DAC channel 1 on PA4, 12-bit right aligned, output buffer on, no trigger: 0..4095. The DAC value sets the APC loop reference: higher = more power. The calibration table gives 8-bit points scaled x16 to 12 bits (section 12).

Power levels from four calibrated curves (very low, low, mid, high), each interpolated against frequency (12.3):

Interpolation fractions (empirical):

On the 10 W radio levels 5-8 are 2 W, 3 W, 5 W, 10 W: level 5 = low + (mid - low) x f2, level 6 = low + (mid - low) x f3, level 7 = mid, level 8 = high. Clamp to 4095.

Without a loaded calibration RadioFoundry drives a fixed DAC value of 300 (DM1701_DAC_UNCALIBRATED in boards/dm1701/radio_dm1701.c), a very low drive.

8. Audio paths

The RX audio mux on PD9 is driven low when the AT1846S output (e.g. its tone generator during audible AFSK) should go straight to the amp (unverified).

APRS receive takes FM receive audio from the I2S stream (squelch gated, 8 kHz): no ADC pin sees the discriminator, but the HR_C6000 puts its FM receive audio on I2S (21). The audio tap says so (AUDIO_TAP_FM_RX), and the core reads it through the shared stream (aprs.md 5.3). The stream is gated by the FM feed-through (4:0x36), so it stays on at volume zero (11.2). The HR_C6000's RX RAM carries the same audio ungated, for a later receive path of the board's own.

9. Display

9.1 Panel and bus

After each burst RadioFoundry writes 0x00 to the data address so the shared data lines rest low before the keypad is scanned.

The case's lens hides about 5 px at the left and right edges. RadioFoundry's safe-area insets default to 5 px left and right, none top and bottom (CONFIG_DISPLAY_INSET* in boards/dm1701/config.mk, ui.md 1).

9.2 Controller type and orientation

The panel type is stored by the factory in SPI flash security register 3, byte 0x1D (read with command 0x48 at address 0x00301D), low two bits:

MD-UV380 panels are always treated as RGB order. MADCTL (0x36) written at the end of init: 0x60 for type 1, 0xE0 for type 2, 0xA0 for types 0 and 3. Color: RGB565 big-endian on the bus (high byte first); in BGR panels red and blue fields are swapped.

On the MD-UV380, security register 3 byte 0x1C = 0xF4 identifies a Plus 10 W radio (seen, not used).

9.3 Init sequences (data)

Common: reset pulse (CS high, RST low 20 ms, RST high), CS low, then:

Types 2 and 3 (controller with inter-command unlock), command followed by parameter bytes:

Types 0 and 1 (ST7735-class):

Then for all types:

Then CS high. Writing a band of rows: RASET start/end (DM-1701: add the 8-row offset), 0x2C RAMWR, pixel bytes. Inversion: 0x21 / 0x20.

9.4 Backlight

PD8 (PC6 on Plus 10 W), active high. Dimming: a 101-entry table of 32-bit words is sent by DMA2 Stream1 (TIM1 CC1 request, circular, 100 transfers) to the port's BSRR register: entry 0 sets the pin, entry N resets it, all others are 0, so the duty is N %. 0 % and 100 % stop the DMA and drive the pin directly.

10. Keypad, side keys, encoder, PTT

10.1 Matrix

Rows are driven high one at a time (push-pull high for the row being read, input/floating for the others). Columns are the eight LCD data lines read as inputs with pull-downs; a pressed key reads high. Sequence per scan:

1. Switch the eight data lines from FSMC to GPIO: first drive them low as outputs for a moment (about 10 loop iterations) to discharge them, then make them inputs with pull-down. Without the discharge step phantom key presses appear on some radios (a glitch when leaving FSMC mode).
2. For each row: drive it high, wait about 100 loop iterations to settle, read the columns, return the row to input.
3. The first key found wins (no multi-key support on the front keys).

DM-1701 / RT84 matrix:

The physical labels of the DM-1701's two "function" keys (right and left in the table, likely the P1/P2 or A/B keys) are unverified. Side key 1 is the one just above the PTT (it is the one held with PTT to enter the bootloader); side key 2 is the lower one (unverified ordering on the RT84).

MD-UV380 matrix (for comparison):

The MD-UV380 has no orange key in the matrix.

Side keys are read in the same way (row 2 high, read D5/D6/D7) and can be held together with each other and with PTT.

10.2 PTT

PE11 (internal PTT) and PE12 (external PTT on the accessory jack): inputs with pull-ups, active low; either one means PTT.

10.3 Rotary channel encoder

Quadrature, A on PE14, B on PB11 (both pull-up), with detents. The driver interrupts on both edges of B only and counts one step per B edge (-1 if A equals B after the edge, else +1). One B edge per detent means two quadrature steps per detent, resting where A equals B (00 and 11). Measured on the bench (2026-10-10, a76da0d): 10 slow and 10 fast detents each gave exactly 10 detents and 20 transitions, 11 counterclockwise gave -11 / 22, a wobble without a detent gave 0 detents (14 transitions, 12 reversals), never an illegal state.

RadioFoundry interrupts on both edges of both lines (EXTI14 for A, EXTI11 for B, one handler) and feeds every sample of the two levels to the table decoder in drivers/input/quadrature: each sample against the previous one is no change, one step either way, or both lines changed (a missed sample, ignored). A detent counts only when the lines reach a rest state with two steps the same way since the last one. The interrupt clears its pending flags before it reads the pins, so an edge during the read interrupts again.

Why counting B edges went wrong (seen as missed steps and steps backward, 2026-10-10):

• Going one way, B is the first line to change when the knob leaves a detent. A light touch or a knob that settles back counts a step and then a step back: the focus jumps a row and returns.
• Contact bounce on B gives several edges. EXTI has one pending flag per line, so edges close together (or while the interrupt is masked or preempted) merge, and the handler reads the level after all of them: a rise-fall-rise reads "high" twice and counts two steps for one, never in step with the detent.
• Bounce on A was ignored, but A's level was sampled at B edges only, so a sample taken while A was still settling (a fast turn) gives the wrong direction.

The decoder makes all three harmless: bounce is a step and the same step back (net zero), merged edges are a repeated level (no change), and only whole detents count. Clockwise is positive (forward): the next channel on Home, focus down in lists (confirmed on the radio).

10.4 Power switch

The volume knob's switch interrupts the battery sense line. The MCU holds its own supply with the latch (PA7 high). When the battery reading drops below 5.5 V (11.1) the switch is treated as off: the firmware finishes its shutdown and drives PA7 low, which removes power. This also means a deeply discharged battery looks like "switch off" (unverified whether there is a second sense path).

11. Analog inputs

ADC1, 12-bit, PCLK2/8 = 9 MHz, scan of 4 ranks, 480-cycle sampling, triggered by TIM3 TRGO (about 70 Hz), DMA2 Stream4 circular into a 4-word array:

11.1 Battery

Voltage in 0.1 V units = raw / 37.5 on the DM-1701 / RT84 (raw / 40.3 on the MD-UV380), plus a user trim of -5..+10 (0.1 V steps). Thresholds (0.1 V): full 8.2 V; low-battery hysteresis 6.2 / 6.4 V; "power switch off" below 5.5 V. Ignore readings for 1.5 s after power-up or wake (they settle); average with a long window (1000 samples) for display, use the latest sample for decisions.

RadioFoundry's thresholds: board.battery_low_mv 6200, battery_critical_mv 6000 (boards/dm1701/board.c, radio-features.md 5.1).

11.2 Volume pot

Log-taper pot read on PA0. Raw ranges (measured): DM-1701 min about 29, max about 2075, breakpoint about 318; MD-UV380 22..2070, breakpoint 309; MD-UV390 Plus 10 W 19..2054, breakpoint 308; RT3S 23..2020, breakpoint 317; MD-2017 32..2048, breakpoint 321. A two-segment linear approximation around the breakpoint maps it to -31..+31 dB, with a "minimum = mute" zone at the bottom (with 5 counts of hysteresis).

11.3 Mic level

PA3 gives the microphone level; convert the raw value to dB (20 log10) for VOX.

RadioFoundry's mic_level (boards/dm1701/power_dm1701.c, VOX in radio-features.md 3.4) gives 0-100: 20 log10 of the raw reading over the ADC's 72 dB, from the shared scale in drivers/audio/miclevel/miclevel.h. Not verified on the bench.

11.4 Temperature

Internal sensor: 943 counts at 25 C, 3.1 counts per C (datasheet nominal 0.76 V and 2.5 mV/C at 3.3 V reference). Uncalibrated, coarse.

12. Calibration data

12.1 Location and life cycle

At start-up: read the working copy; if bytes 0x1B0-0x1B7 are not the marker 00 25 00 40 00 45 01 40, read the factory table, overwrite those 8 bytes with the marker, derive the very-low power row and apply the power conversion below, then write the result to 0x010000. Never write the security registers.

Power conversion when deriving the working copy (empirical): very low = low x k0 (always), and if converting: low x= k1, mid x= k2, high x= k3.

12.2 Table layout (512 bytes)

UHF rows have 9 points (400-480 MHz), VHF rows 5 points. "Used" says whether the open firmware applies it.

BCD frequency format: 4 bytes little-endian BCD, 10 Hz units (00 25 00 40 = 400.02500 MHz).

12.3 Interpolation against frequency

Frequencies in 10 Hz units; above 300 MHz use the UHF row.

index = (f - first) / step, clamped to the row; linear interpolation between point[index] and point[index+1]; above the last point, extrapolate with the slope of the last segment. Power and RX-tuning points are scaled x16 (8-bit to 12-bit DAC), gains stay 8-bit (clamp 0..255). Power uses the TX frequency; gains use the TX frequency too.

12.4 Reference oscillator offset

offset = (VHF or UHF tune byte) - 128, signed, for the band in use (TX band while transmitting, RX band otherwise). Written to HR_C6000 4:0x47 = offset, 4:0x48 = 0x03 if offset < 0 else 0x00, 4:0x04 = offset. In FM TX, 4:0x48 = 0x00 and 4:0x04 = offset.

12.5 FM deviation (fixed, not from the table)

HR_C6000 FM TX deviation coefficients used instead of the table rows:

13. SPI flash

13.1 Device and bus

13.2 Map

The flash keeps the GD-77 codeplug layout so that CPS tools interoperate: the first 64 KB emulate the GD-77's 64 KB EEPROM one-to-one, and the GD-77's 1 MB "flash" image starts at 0x020000 (offset +128 KB). Details of the codeplug records are in open-firmware-cps.md.

14. Other peripherals

15. Bootloader and firmware images

15.1 Entering the bootloader

Hold PTT + side key 1 (the key just above PTT) while turning the power switch on. The radio enumerates as a USB DFU device, VID 0x0483 PID 0xDF11 (ST's DFU IDs, but the TYT/AnyRoad bootloader, not ST's ROM loader). The device string at index 1 reads "AnyRoad Technology". The screen stays dark. The interface string describes the memory layout in the usual DfuSe "@name/0xADDR/NN*SSKg,..." form.

15.2 Flashing protocol (DfuSe-style, as the loader drives it)

The image is written as one contiguous stream starting at 0x0800C000: byte n of the file goes to 0x0800C000 + n.

Every listed region has the same rule: blocks 2..N, the key applied from the image start, which is block aligned at every sector start (for example 0x080A0000 - 0x0800C000 = 0x94000, a multiple of 1024). rfoundry erases and writes a region only when it has data, so an update leaves sectors 10 and 11 (the codec) out. The loader accepts a sector written on its own, with sectors left out on both sides: a RadioFoundry image that wrote only sectors 3-6 and 9 flashed through rfoundry, booted and passed the radio-only HIL group (2026-10-14).

15.3 Image encryption

The bootloader decrypts what it receives. The host XORs every byte of the plain application image with a 1024-byte per-model key: encrypted[n] = plain[n] XOR key[n mod 1024], n counted from the start of the image (address 0x0800C000). No other transformation, header or checksum. Keys (1024 bytes each, values not reproduced here; identify a key by its SHA-256):

The key tables are identified by hash only. A key is derived on the user's machine from the manufacturer's firmware file, or read from the radio's bootloader (below).

Derived from a firmware file, DM-1701. The key falls out of any DM-1701 firmware file from the manufacturer. The payload is plain XOR key[i mod 1024], and in a firmware image 0x00 is the most common plain byte in every key column, so the most common cipher byte of column j is key[j] for all but a few columns; those are settled by trying each close runner-up byte until the SHA-256 of the result matches the table above. On every firmware file in codec-dm1701.md ("Firmware files": V02.01, V02.02, V02.03 with and without CSV, V02.06 CSV and noCSV) this gives the key with hash d983ce95... in under 0.1 s, needing at most a few hundred hash checks. tools/rfoundry/rfoundry/stockfw.py (derive_key) does this on the user's machine; only the hash is in the repository. The same method should work for the other models' files (unverified: no MD-UV380, MD-380 or MD-9600 file was tried).

In the bootloader, DM-1701. The bootloader (sectors 0-2) holds the key as one plain 1024-byte block: in the bootloader exactly one 1024-byte window has the hash above. RadioFoundry can read those sectors (read protection level 1 doesn't stop code running from user flash, debuglink.md 3.10), so the web flasher (bootkey.js) and rfoundry (bootkey.py) read them over READ_MEM and take the block whose SHA-256 matches. Updating a radio that runs RadioFoundry therefore needs no firmware file. The search tries every offset (4-byte aligned first) and assumes no layout, so a bootloader version that keeps the key elsewhere works too. Unverified for the other models' bootloaders; when no block matches, both clients fall back to the firmware file.

Other loader facts:

• A manufacturer's firmware file is recognized by its first 16 bytes "OutSecurityBin" followed by two zero bytes; it must never be flashed as an application image.

15.4 Software entry to a bootloader

Goal: re-flash over USB without someone holding PTT + side key 1 at power-on (15.1). There are two possible routes, both reached from the running firmware through the debug link (docs/spec/debuglink.md 3.9-3.11).

Read protection. rfoundry_debug.py chip on a DM-1701 (2026-10-10) reads idcode 0x0009A413 (STM32F405/407), 1024 KB flash, FLASH_OPTCR 0x0FFF55ED: RDP level 1 (byte 0x55), no sector write protection, BOR off, user bits all 1. Assume every DM-1701 is at RDP level 1 until one reads otherwise. RDP level 1 does not stop the application from reading flash (only a debugger, RAM boot and system-memory boot are locked out), so the bootloader (sectors 0-2) can be read with rfoundry_debug.py dump. It is proprietary and is never committed.

Route 1: ST's ROM bootloader (USB DfuSe in system memory). Refused on this radio. The firmware has it: REBOOT mode 1 stores the flag 0xB007DF11 in RTC_BKP19R and resets. A backup register is used rather than RAM because the bootloader runs in RAM before the application. First thing in main(), stm32_sysboot_check() (platform/stm32f4/sysboot.c) finds the flag and then:

1. clears the flag and checks that it is clear, so a failed entry boots normally next time (and boots normally anyway if the flag won't clear);
2. sets the power-up pin levels (board_sysboot_prepare: power latch high, transmitter off, HR_C6000 powered down);
3. turns interrupts off, stops SysTick and clears every NVIC enable and pending bit;
4. returns RCC to HSI with HSE and the PLLs off at their reset values, sets FLASH_ACR to 0 and resets every peripheral except the GPIO ports;
5. checks that 0x1FFF0000 holds a plausible vector table, maps system memory at 0 (SYSCFG_MEMRMP), sets VTOR to 0, loads MSP from 0x1FFF0000 and jumps to the vector at 0x1FFF0004.

The firmware and rfoundry_debug.py both refuse this mode unless RDP is level 0. At level 1 the ROM bootloader refuses every flash access, and its only way out, the read-unprotect command, sets RDP to 0 by mass-erasing all of flash, the bootloader included. After that the radio could be reloaded only over SWD. At level 2 the ROM bootloader is disabled. On the bench unit (RDP 1) this route is closed. The code stays in the firmware because it is gated and does nothing unless the flag is set. If a unit ever reads RDP 0, the procedure would be: rfoundry_debug.py chip -> rfoundry_debug.py reboot --rom-dfu -> a DfuSe host that erases and writes only sectors 3-11 (0x0800C000 and up). No such host tool exists in tools/: stm32_dfu.py has no ROM mode.

Untested risks of route 1, found while writing it (they matter only on an RDP 0 unit):

• Power latch. The volume knob only breaks the battery-sense line (10.4); PA7 holds the supply. While the ROM loader runs, PA7 stays high, so the knob cannot turn the radio off. Getting out of a stuck ROM loader takes a DfuSe leave command or removing the battery. Because the flag is already cleared, the next start is normal.
• HSE clock. The board feeds an external clock in bypass mode (1.2), not a crystal. ST's ROM needs HSE for USB DFU on the F405 and may set it up in crystal mode. If that doesn't start, USB DFU never enumerates.
• Interface probing. The ROM also listens on USART1 (PA9 / PA10, wired to GPS power and GPS RX on GPS-fitted siblings) and on USART3 / CAN2. Activity on those pins can capture the loader before USB. The DM-1701 has no GPS fitted, so PA10 is idle on it.
• Leaving. Where the ROM's DfuSe leave command jumps, and with which memory mapping, is unverified. A battery pull always returns to the normal start (bootloader, then the application).

Route 2: a software entry into the bootloader's own DFU mode. This route would leave RDP alone and keep the XOR-keyed DfuSe path that tools/stm32_dfu.py already speaks (15.2, 15.3). It works only if the bootloader checks something besides the PTT + side key 1 combination that firmware can set before a reset: a RAM word it reads before clearing RAM, an RTC backup register, or a backup SRAM location.

There is no such flag. The bootloader decides once, after its own startup has cleared and initialized main SRAM, and there is no timeout. It stays in DFU when either of these holds; otherwise it loads MSP from 0x0800C000 and jumps to the word at 0x0800C004:

• GPIOE IDR bits 8 and 11 (PE8, keypad column 5 / side key 1; PE11, PTT) both read low, the power-on key combination.
• The application's initial stack pointer at 0x0800C000 fails (SP & 0x2FFE0000) == 0x20000000, so an erased sector 3 (0xFFFFFFFF) keeps it in DFU. The reset vector is not range checked.

It reads no RAM word, no RTC backup register or backup SRAM, and no reset-cause flag (RCC_CSR), and it doesn't set VTOR (the application sets its own). So nothing firmware can set before a reset makes it stay in DFU, except making the application look invalid. The least damaging way is a single flash word program that clears bit 29 of the word at 0x0800C000 (0x2001FFFC to 0x0001FFFC; programming can only clear bits, so no erase is needed). After that the radio boots into DFU every time until a full image is written again, which tools/stm32_dfu.py does. Sectors 0-2 are never touched, so the bootloader always stays reachable. This is not implemented; it is a candidate REBOOT mode 2 with the same gate plus an explicit confirmation in the tool.

Route 3: no bootloader at all, for updates. A build with CONFIG_STUB_ENTRY=y loads a RAM flash stub over the debug link and the stub writes the application sectors itself (stub-stm32f4.md). It uses the DFU check above as its safety net: it erases sector 3 first and programs the word at 0x0800C000 last, so an interrupted update leaves the radio in DFU at the next power-on with no keys held.

16. USB

USB gotchas found on the DM-1701:

• macOS aggregates back-to-back datagrams into one NTB; the NTB parser must walk every datagram pointer (not stop after a fixed count) and also bound the number of NDPs to avoid loops.
• macOS only brings the link up after a NetworkConnection notification is sent once the device is configured. On a cold boot in network mode macOS sometimes never activates the link; re-enumerating (soft disconnect/connect) about 5 s after boot when the link is still down fixes it.
• Reassemble OUT NTBs from 64-byte packets using the NTB block length rather than relying on a zero-length packet, and re-arm the OUT endpoint only after the NTB has been consumed (natural flow control).
• The reduced-power clock must not be entered while USB is configured (1.3).

17. Variants

Build variants: DM1701, RT84, MDUV380, MDUV380_10W_PLUS. The MD-2017 is not built: its pins are not defined.

Everything else (MCU pins for RF, HR_C6000, AT1846S, SPI flash, USB, clocks, flash layout, codec address) is the same across the family.

18. Gotchas summary

1. The bootloader rejects an initial stack pointer equal to the top of RAM; use 0x2001FFFC.
2. Set VTOR to 0x0800C000; the vector table is not at 0x08000000.
3. The bootloader leaves HSE/PLL running: switch to HSI before reprogramming HSE/PLL.
4. CCM RAM is not zeroed or initialized by default startup code and is invisible to DMA. RadioFoundry puts the RTOS heap (every task stack), the slot engine, the radio state machine and the big CPU-only buffers there; .ccmbss (RFOUNDRY_CPU_RAM) is zeroed before main by a .preinit_array entry in board.c, .ccmram (RFOUNDRY_CPU_RAM_NOINIT) is not. DMA buffers stay static in main SRAM, and each stream's set-up checks that (DMA_RAM_OK).
5. The codec must be at exactly 0x0807537C; the code budget is the space below it. Keep large constant tables above the codec end if the code grows.
6. PA13 is SWDIO; driving it as mic power breaks SWD (use connect-under-reset).
7. LCD data lines double as keypad columns: discharge them before reading keys, and leave them low after LCD writes.
8. HR_C6000 config SPI and AT1846S I2C are touched from ISRs and tasks: make transactions atomic, and never block on I2C in an ISR.
9. The PA is switched per burst in DMR; "transmitting" must come from the modem's slot state, not from the PA pins.
10. The HR_C6000 RF_RX_EN / RF_TX_EN pins are not wired to the MCU; RF switching is done by the MCU (I2C + GPIO), about 0.5 ms per switch.
11. The AT1846S TX frequency offset depends on the write sequence (about -3 kHz with the normal sequence, none with a direct switch); measure, do not copy.
12. DMR RX needs AT1846S AF gain at maximum (0x44 = 0x07FF) and reg 0x40 bit 0 set; FM needs bit 0 clear.
13. A volume-knob power-off looks like the battery dropping below 5.5 V; the firmware must then release the PA7 latch.

19. Datasheets

Public documents this page relies on: the AT1846S datasheet 0.3 and programming guide 1.4, the HR_C6000 datasheets, the W25Q80BV datasheet, ETSI TS 102 361-1 v2.2.1.

Not available for this radio: the STM32F405 datasheet and RM0090 reference manual; the LCD controller datasheets (ST7735S / HX8353-E, and the controller of panel types 2/3); the W25Q128 datasheet (the W25Q80BV covers the command set); schematics or a service manual; audio power amplifier, RF PA and TCXO part data; GPS module data.

20. Bench findings (RadioFoundry on a DM-1701, 2026-10-09)

Verified on one radio with the new firmware; they override the unverified notes above where they differ.

• Keypad: the 10.1 matrix is right. The two "function" keys are labeled P1 (row 0, D6) and P2 (row 0, D5). There is no orange key: the three black side keys are, top to bottom, row 2 D5 (the "top key" position), row 2 D7, row 2 D6; PTT is separate. A row released while still high stays charged and makes every key also read as the key below it: drive the row low before releasing it and keep idle rows pulled down.
• Encoder: clockwise counts up with the 10.3 rule, one count per detent.
• Panel: this radio reports type 2 (security register 3, byte 0x1D). Driving it with the type 2 MADCTL (0xE0) shows the picture mirrored top to bottom; treating it as type 3 with RGB order (as 9.2 says) is correct. The 8 hidden rows are panel rows 0-7 either way.
• Volume pot: raw 26 at the bottom, 2063 at the top.
• Battery: raw / 37.5 gives a plausible 7.1 V (not yet checked against a meter).
• Calibration: the working copy at 0x010000 carries the marker. The FM I gain rows (0x170 UHF, 0x179 VHF) are all 0x00 on both bands while the other gain rows hold values: an all-zero gain row is valid data.
• Soft volume: HR_C6000 4:0x37 (RX gain) scales FM feed-through audio as well as DMR audio; -31 dB is still audible, so the bottom of the knob must also mute the speaker path. It mutes the amp only: the feed-through (0x36) and the gain (unity at the bottom) stay as for any FM receive, because the I2S copy of the FM audio that APRS receive reads is gated and scaled by both. Before this, a knob at zero turned the feed-through off and APRS heard nothing.
• Volume override: because the MCU reads the knob and sets this gain itself, the debug link can set the level instead (RADIO op 30, radio-features.md 4.2): a step 0..16 maps to the same 0..100 % scale as the knob, in force until it is cleared (RAM only). The knob has no analog path around the gain, so the override fully takes its place (HW, not yet run on a radio).
• HR_C6000: 4:0x10 reads back 0x80 after FM RX set-up (the config port works with the 4.2 timing).
• FM TX (VFO 461.8625 MHz, 12.5 kHz, 1 W, measured with an RTL-SDR, 2026-10-09): with the TX sequence of radio_dm1701.c (frequency written with the receiver off, straight to TX) the carrier is within about 50 Hz of the channel, so no TX offset is added. Unmodulated carrier residual FM 41 Hz RMS, no hum or tone. Voice at normal level: 2.5 kHz peak deviation (99.5th percentile), 636 Hz RMS, about 7 kHz occupied at -26 dB. The FM I calibration row of 0 (Mod2 amplitude) does not stop voice modulation.
• DMR TX (Ch 1 467.375 MHz, cc 2, 1 W, SDR bench + an MMDVM_HS receiver, 2026-10-10): switching per burst from RX on straight to TX on the already-tuned frequency put the carrier 3.07 kHz low (an ADF7021-based receiver decoded nothing; a wide-AFC SDR decoder still did). Retuning with the receiver off before every burst (as FM TX does) brings it to about +65 Hz, and the MMDVM_HS receiver decodes headers, all superframes with the embedded LC and the terminator. Burst spacing 60.000 ms (sd 0.002 ms), 31 ms PA per burst.

21. Audio paths for USB audio (bench study)

Which audio paths reach the MCU, for the USB audio design (usb-audio.md). Measured with probe firmware: CONFIG_AUDIO_PROBE=y adds debug link command 0x10 (debuglink.md 3.14), which reads and writes HR_C6000 registers, runs the PCM stream with a test tone and reports both I2S channels' levels. tests/hil/test_audio_probe.py runs the experiments.

21.1 What the board has

From sections 2, 4.4, 8 and 11 and the HR_C6000 user manual (the vendor datasheet; register table and appendix A in its Chinese section):

The I2S link (SPI3 as I2S slave on PA15/PC10/PC11/PC12, the HR_C6000 driving the clocks): Philips, 16-bit data in 32-bit frames, both channels, 8 kHz, circular DMA on DMA1 streams 0 and 5 in 20 ms halves (platform/stm32f4/hrc/i2s_pcm.c, hal/hal_audio.h). This is the only audio data path between the MCU and the radio.

No other path exists on this board: ADC1's four inputs are the volume pot (PA0), battery (PA1), mic level (PA3) and the temperature sensor; DAC channel 1 (PA4) sets the PA power (APC); the DAC channel 2 pin (PA5) is the VHF receiver 5 V switch. The RX audio mux (PD9) chooses between the HR_C6000 line out and the AT1846S audio output toward the speaker amp only. A hardware modification (a wire from the AT1846S audio output to a free ADC pin) would work for receive but is not something users should need, and there is no equivalent for transmit.

21.2 DMR

The DMR voice path already moves PCM between the MCU and the codec in both directions (core/dmr/ambe/ambeVoice.c): decoded frames are played as 20 ms blocks, and microphone blocks are encoded while transmitting. For a USB voice endpoint the audio router (usb-audio.md 5.1) takes the decoded block for the host as well as (or instead of) the speaker, and feeds host PCM to the encoder instead of the microphone. CPU, codec stack and RAM are what a normal DMR call uses (the AMBE codec runs for one direction at a time; a DMR radio is half duplex). DMR on this board was verified on air in both directions (section 20).

21.3 FM

What the HR_C6000 manual says:

• The built-in codec's input mux takes MIC_P / MIC_N (differential) or LINEIN1 / LINEIN2 (single ended), then a gain stage, the ADC and a digital filter; its output path is a gain stage (page 4 0x37), the DAC and LINEOUT1 / LINEOUT2 (manual 4.5.1, figure 4.12).
• Register 0xE0 (manual register table, Chinese section): bit 7 MCU controls the codec, bit 6 LINEIN1 enable, bit 5 LINEIN2 enable, bit 4 LINEOUT1, bit 3 LINEOUT2, bit 2 MIC_N, bit 1 MIC_P, bit 0 I2S slave. Our 0xC9 (DMR, FM TX) is MCU control + LINEIN1 + LINEOUT2 + I2S; 0x89 (FM RX) the same without LINEIN1. So the microphone is wired to LINEIN1, and modem-hrc6000.md 2 calls bit 6 "mic input enable", which is right in effect. On a DM-1701 board photo, pin 8 (LINEIN2) has no trace and pins 6 (MIC_N) and 7 (LINEIN1) share a via; the bench agrees (21.3.1, LINEIN2 loop). FM receive audio plays with 0xE0 = 0x89, both line inputs off, and the HR_C6000 detects the sub-audio tones, so the receive audio reaches its FM chain through the baseband ADC (the path DMR uses), not the codec inputs: section 8's "line in" for FM RX is probably that. Pin 8 is the free analog input for a mod (candidate D).
• 0xE3 bit 0: "codec internal DAC and ADC pass-through enable, normally 0". The direction is not stated.
• The FM transmit chain takes the codec ADC's samples; the FM receive chain ends at the codec DAC (manual 6, figure 6.1). The I2S "vocoder interface" carries the codec ADC's samples to an external vocoder and the vocoder's PCM to the DAC (manual pin table, C_SDI / C_SDO; 0x22 bits 2-1 choose I2S and its master mode). Nothing says the FM chains can read from or write to the I2S interface.
• The chip has "FM data" RAM: two 512-byte buffers in the TX RAM ("can be written externally for FM send; voice data can also come internally from the codec") and two in the RX RAM (manual 5.3 tables), and FM-mode interrupts in 0x82: bit 7 "FM: sending data request", bit 1 "FM: receiving data". Register 0xD7 bit 1 (written 0xDB here before) selects "send FM voice" over MSK signaling. This looks like the MCU can exchange FM audio samples with the chip through its RAM pages, but the format, rate and control are not documented. Our FM RX set-up writes 0x81 = 0x19, which masks both FM data flags.
• The FM chain can use an external codec instead of the built-in one (0x06 bit 2, appendix A2), over a second I2S port on pins 17-20 with the chip as master. The MCU sits on the other one, the vocoder port (pins 34-37), so this only helps if pins 17-20 reach the MCU, which nothing we have shows. The block diagram's "I2S" next to the FM transmit chain is this port.
• A "prompt tone" path (0x06 bit 1, appendix A1) lets the MCU write DAC samples over U_SPI without I2S: speaker only, but with 0xE3 bit 0 it is another way into the ADC and so the FM transmit chain if the I2S clock stops in FM. modem-hrc6000.md 8.1 has the details of all of these.

21.3.1 Bench results (2026-10-12)

Probe firmware, tests/hil/test_audio_probe.py, NOAA WX3 (162.475 MHz) for receive, 467.375 MHz into the SDR bench for transmit.

| FM TX from the prompt tone FIFO | no. The FIFO (page 3 address 0, 32 samples when 0x88 bit 0 reads 0) drains at exactly 8000 samples a second whether 0x06 bit 1 is set or not, and a 1400 Hz tone through it never reaches the air: path open, with 0xE3 bit 0, either byte order | | Bit sweep while keyed | no. Each bit of 0x25, 0x26, 0xE1, 0xE2, 0xE3, 0xE5, 0x0D, 0x0E, 0x0F and 0x38 flipped for 0.5 s (80 flips, 10 key-ups) with a 600 Hz tone on I2S and a 1 kHz tone in the TX RAM: neither tone on air during any flip. LINEIN2's tone, used as the time marker, came at 2.59-2.61 kHz this time (2.49 kHz before): an oscillation on that input |

So the chip's FM chain takes audio only from its codec ADC (microphone, LINEIN1, LINEIN2) or the external codec port; nothing the MCU writes over U_SPI or I2S reaches it. MCU audio goes on air through the modulator's MOD1 offset (0x04) instead, with the MCU doing pre-emphasis, limiting and CTCSS, at about 6 bits; AFSK can use the chip's tone generator. Full quality needs candidate D (the PC11 to pin 19 wire). The register reference with the manual's details is hrc6000-registers.md.

Candidates, in order of preference:

A, B and C don't work (21.3.1). Receive uses the I2S stream or the RX RAM tap. Transmit uses E, or the MOD1 offset for content above the codec's band; AFSK can also use the chip's tone generator.

The probe experiments, in the order they were run:

1. Does the I2S clock run on an FM channel? (If not, no FM PCM at all without C. Beeps on FM depend on it too: beep.no_stream in radio-features.md 4 asks the same question.)
2. Receive: NOAA weather radio in the VFO with the squelch open, then a quiet frequency; for the register settings as set, A, LINEIN1 and B, the RMS of both I2S channels. A setting whose RMS rises clearly with the signal carries receive audio. It also tells which I2S channel the chip fills (audio_dm1701.c assumes the left one, unverified).
3. Transmit (opt-in RF, SDR bench): key FM with the microphone muted (0xE0 bit 6 off) while the probe sends a 1 kHz tone into I2S; for "no tone", "tone", B and A, the voice band deviation the bench measures.
4. Candidate C, receive: on NOAA and on a quiet frequency, the rate of the 0x82 FM flags with 0x81 as set and with bits 7 and 1 unmasked, whether the RX RAM buffers change, and their level read as 16-bit (both byte orders) and 8-bit samples.
5. Candidate C, transmit (opt-in RF): both TX RAM buffers hold a 1 kHz tone, a whole number of cycles in 256 samples, so a chip that replays them sends a steady tone without refills. Keyed with the microphone muted, for the likely source settings (FM flags unmasked, 0xDB bit 1 (meant: 0xD7 bit 1), 0x60 = 0x40 or 0xC0, 0x06 bit 0, big endian samples): the FM flag rate and the voice band deviation against a silent-RAM baseline.

21.4 Running the probe

With the AMBE codec merged as usual:

make BOARD=dm1701 CONFIG_AUDIO_PROBE=y BUILD=build/dm1701-probe   # flash build/dm1701-probe/rfoundry_dm1701.bin
python3 -m pytest tests/hil/test_audio_probe.py -v -s -rs          # stream in FM, the receive variants (NOAA), RX RAM
python3 -m pytest tests/hil/test_audio_probe.py -v -s -rs --allow-rf --allow-service-stop -k tx   # I2S and RAM TX variants

By hand (an FM channel or the VFO):

tools/rfoundry_debug.py aprobe start            # stream with silence out; then:
tools/rfoundry_debug.py aprobe status           # blocks counting up = the I2S clock runs in FM
tools/rfoundry_debug.py aprobe reg 4 0xE0       # 0x89 expected in FM receive
tools/rfoundry_debug.py aprobe wreg 4 0xE0 0xA9 # LINEIN2 on (candidate A); status / samples with and without a signal
tools/rfoundry_debug.py aprobe wreg 4 0xE0 0x89
tools/rfoundry_debug.py aprobe wreg 4 0xE3 0x53 # candidate B (0xE3 is 0x52 at init: bit 0 set); watch status
tools/rfoundry_debug.py aprobe wreg 4 0xE3 0x52
tools/rfoundry_debug.py aprobe samples -o /tmp/blk.raw   # one block of both channels, tone estimate printed
tools/rfoundry_debug.py aprobe stop
tools/rfoundry_debug.py aprobe wreg 4 0x81 0x9B # unmask the FM data flags (0x19 | 0x82)
tools/rfoundry_debug.py aprobe watch 1000 0x82 0x030   # FM flag rates, RX RAM word changes
tools/rfoundry_debug.py aprobe ram 2 0x030 64   # the start of the RX FM buffer

Expected readings: in FM receive with the defaults, both channels near silence (the microphone is off). A candidate works for receive if, with NOAA audible and the squelch open, one channel's RMS rises well above (4x or more) its value on a quiet frequency. For transmit, the SDR bench's voice band RMS deviation with the tone and the candidate setting is well above the "mic muted, no tone" row.

22. Facts moved from the shared specs

• Settings and storage: the core's map for the 16 MB SPI flash is settings 0x011000 (32 KB, 8 sectors), journal 0x019000, open-firmware EEPROM 0x000000, open-firmware flash 0x020000 up to 0xE00000, native area 0xE00000 (1 MB), TFTP staging 0xF00000 (256 KB), calibration window 0x010000 (512 B). The range 0x011000-0x01AFFF has never been checked on a used radio, for the foreign-region guard of settings-store.md 5.
• The board's hal_radio has tx_tone, so the MMDVM task keys the 1750 Hz burst (mmdvm-protocol.md).
• USB: the STM32F405 OTG_FS has three IN endpoints besides EP0, so serial and network are alternatives, not a composite (usb-network.md).
• board_rf_safe pins: PA_EN1 (TX supply) and PA_EN2 (APC loop) low, PA_BAND low, APC DAC (DAC1 channel 1) 0.
• GPS: USART1 RX on PA10, with PA9 as the GPS power switch.
• Crash log (crash-log.md): the backup SRAM kept the record through the bootloader. A trap test gave HardFault with CFSR UNDEFINSTR in the task host; a hang test ("CRASH TEST") was recorded at 3750 ms. The snapshots named radio_task, dmr_task, input_task, the UI task in input_next / ui_task and the USB task in tud_task_ext (2026-10-17/23, test_crash.py). The restart cause after a watchdog reset is watchdog.
• Roaming (dmr-roaming.md 3): a survey visit relies on the AT1846S RSSI plus HR_C6000 sync acquisition needing well under 100 ms on a continuous outbound (a burst every 30 ms), then four 25 ms readings.
• On air since 2026-10-10: receiver sleep (test_battery_save*: cycles when idle, monitor and a call wake it), the 1750 Hz burst, the roger beep and APRS AFSK (HIL). VOX was checked in silence only (test_vox_quiet).
• AFSK TX retunes the AT1846S tone generator per symbol. The AFSK RX audio comes from the HR_C6000 FM audio on I2S (squelch gated, 8 kHz, de-emphasized). DMR LRRP and UDT passed on air at 467.375 MHz, CC 2, 50 mW. An AFSK tone level of 0x1C gives about 3.1 kHz peak deviation (0x40 gave 7.2 kHz).
• REBOOT mode 1 enters the ROM DFU with a flag in an RTC backup register (15.4). The spare beep PWM pin is PC8 (TIM8 CH3, 72 MHz carrier, DMA2 stream 2), used by AUDIO_PROBE PIN_TONE / PIN_PWM at about 37,000 MOD writes a second.
• Release and flashing: application sectors 3-9 (720 KB), codec sectors 10 and 11 (1.4), keep supported, profile dm1701-v0206-csv-s11. Releases before the move linked read-only data into sector 9 as a second range, profile dm1701-v0206-csv. An interrupted update writes sector 3 (the vector table) last, so a cut before it leaves the bootloader in DFU; a later half application may crash but never bricks. Enter the bootloader by hand (PTT and side key 1 at power-on) and flash again.

View the source of this page