USB debug link

A small framed protocol on the radio's host port (USB CDC-ACM on radios with USB, a UART otherwise) for bench automation: read the firmware version, the diagnostics counters and the radio's state, reset counters, take screenshots, press keys, key PTT with a firmware time-out, send radio requests, read a log ring, read the chip's identity and option bytes, read internal flash and the other read-only memories, and reboot. It lives beside the MMDVM hotspot and the open-firmware CPS protocol on the same port (core/hostlink), and it never changes the host link's mode.

• Firmware: core/debuglink/ (switch CONFIG_DEBUGLINK, default on with CONFIG_HOSTLINK), key injection in core/input/input_task.c, the hook in core/hostlink/hostlink.c.
• Chip commands: the portable checks in core/debuglink/dl_chip.c (host tested), the platform side in hal/hal_system.h (board.system) and the platform's implementation (platform/stm32f4/sysboot.c, platform/hrc7000/system.c).
• Host: tools/rfoundry_debug.py (command line and Python module), tests/hil/ (pytest hardware-in-the-loop tests).

1. Coexistence on the host port

The host link sends each request to one protocol by its first byte (hostlink.h):

0xA5 is not printable ASCII and not 0xE0, so it can't start a request of the other two. A debug frame is recognized where a request may begin:

• Idle (no session): always.
• CPS session: only after the 3 ms of quiet that starts a new CPS request (bytes inside a CPS write may be anything).
• Hotspot mode: only between MMDVM frames, when the MMDVM framer is waiting for 0xE0 and would discard the byte as junk anyway. MMDVM frames before and after a debug frame in the same USB packet are handled as usual. The debug link answers in hotspot mode; its replies go out between MMDVM replies (one task writes both, so they never interleave). Debug frames do not count as MMDVM traffic: they don't keep hotspot mode alive and don't enter it. In practice only a test tool that speaks both protocols on one open port sees this (the port has one owner).

Once A5 5A has been seen, the following bytes belong to the debug frame until it is complete or until 200 ms pass without a byte (the partial frame is then dropped and counted as a time-out). If the byte after 0xA5 is not 0x5A, only the 0xA5 is consumed and the next byte goes to the normal dispatch.

Commands run in the host link task. Each is short: no command waits for another task (radio requests are queued to the radio core, key holds are timed by the input task), and a reply is at most 1032 bytes on the wire.

2. Framing

Both directions use the same frame:

The CRC is CRC-16/CCITT-FALSE (polynomial 0x1021, initial value 0xFFFF, no reflection, no final XOR; the check value of 123456789 is 0x29B1) over the bytes from the command to the end of the payload.

Every reply payload starts with a status byte:

A request that can't be decoded gets an error frame: command 0xFF, the request's sequence number as far as it was received, payload = status (5 or 6) and the command byte received. A request longer than 64 bytes is answered as soon as its length field arrives; the parser then resynchronizes on the bytes that follow (they are not skipped, since they may belong to another protocol).

All multi-byte numbers are little endian. Text is ASCII, lines end with \n.

3. Commands

3.1 VERSION

Example from an STM32F4 radio (<profile> stands for the codec profile id):

proto=1                 protocol version (this document)
view=2                  GET_VIEW record version (3.7)
git=5277f73a            firmware git hash
board=XR-100UV
features=FM,SUBTONE,DMR,DMR_PRIVACY,...,USB,HOSTLINK,DEBUGLINK
codec=<profile>-s11  the codec profile found in flash (below)
display=160x120x16      panel width x height x bpp
inset=5,5,5,5           safe area insets: top, bottom, left, right
uptime_ms=123456
req_max=64
reply_max=1024
inject_max_ms=10000     longest hold of an injected key, PTT included

codec= is the board's own check of the codec in flash, the same one that decides whether DMR voice runs: a profile id (<profile>-s11 on an STM32F4 radio: the descriptor is valid and the signature word and the CRC-32 of every codec window match the codec as the merge places it, code in sector 11, as codec-placement.md "STM32 radios" describes; <board id>-<build> on an HR_C7000 radio: the codec slot is valid, and the build is the version of the stock file it was carved from), absent (the board has a vocoder but the check failed: erased, another stock version, damaged), present (a valid codec whose board names no profile) or none (built without DMR). It describes flash, not whether voice can run at that moment: after the HR_C7000 stub entry has stopped the codec (its RAM is the stub's), the profile id is still reported. The first request after boot may take some 20 ms longer while the board computes the CRCs. It reads flash only. tools/rfoundry asks for it before flashing to decide whether the codec sectors can be left alone (docs/dev/release.md). A build from before the STM32 codec moved reports the stock id (the profile without -s11) for the codec at its stock addresses, so the flashing tools know the new layout doesn't hold it.

Unknown keys must be ignored by hosts; keys may be added without a version change.

3.2 GET_DIAG

The diagnostics as text lines, numbered from 0, with the firmware's millisecond clock at the time of reading, so a host can compute rates between two reads:

The reply holds as many whole lines as fit from first; next is the line to ask for next, 0xFF when the last line was sent. The board lines are each board's own. On the HR_C6000 boards they start with the slot engine counters (V<voice> H<headers> T<terminators> I<idle>, C<csbk> D<data> crc<errors> rc<rc>, ...) and end with the readings and the audio counters (aud blk ov dr).

3.3 SCREENSHOT

Request: none (header only), or offset u32 and length u16 (at most 1000 bytes per reply). Reply after the status:

A 16-color frame buffer (bpp 4) is converted through its palette as each chunk is read, so the host sees an RGB565 frame of width x height x 2 bytes. The chunks are read live from the UI's frame buffer, without a lock (the UI task owns it, and a 38 KB copy would not fit in RAM). A redraw while the host reads the chunks can tear the image. rfoundry_debug.py screenshot reads the whole buffer twice and repeats until two reads agree (--tries, default 4), which gives a consistent image unless the screen changes continuously (a running timer); it says so when it gives up.

While a capture is read the UI does not redraw: every SCREENSHOT request holds redraws for 1 s, and the request that returns the last chunk for 250 ms, long enough for the host's check pass to start. A key or radio request in that time changes the UI's state (ui.screen in GET_VIEW) at once, but its screen is drawn only when the hold lapses, so a host that captures a new screen waits for the hold to end (tests/hil/rfoundry_hil.py: Radio.screenshot and shot_until). Firmware before this rule held for 1 s after the last chunk too.

3.4 KEY

Injected keys go through the same path as the radio's own keys: their physical key bits are ORed into the input task's scan, so debounce, the gesture engine (PRESS / LONG / REPEAT), the PTT and MONITOR edges to the radio core, and the UI's idle and backlight time all behave as for a real key. input_last_source() tells the UI that the last activity came from the host.

Actions (hal_input.h): 1 up, 2 down, 3 left, 4 right, 5 select, 6 back, 7 quick, 8 context, 9-18 digits 0-9, 19 ptt, 20 monitor, 21 talk target, 22 emergency, 23 enc (encoder step), 24-27 user 1-4. Gestures: 0 PRESS, 1 LONG, 2 REPEAT, 3 DOWN, 4 UP.

Rate limit: one injected key at a time. While one is held, and for 40 ms after its release (two scans for the debounce to see it released), KEY answers busy (3). Every hold is capped at 10 s. Both also count key scans: a hold ends only after three scans have seen the key, and the next starts only after three scans have seen it released. A scan can run late (a key matrix on the LCD data lines is busy for a whole redraw), and a hold measured in ms alone ended before the debounce saw it: the press was lost.

3.5 PTT

down = 1 holds the PTT key, 0 releases it. The optional max ms (default and maximum 10000) is a time-out kept by the input task: the PTT is released when it expires even if the host never sends down = 0 (the host crashed, the cable was pulled). Sending down = 1 again while held re-arms the time-out. The reply carries the time-out applied. PTT goes through the radio core like the real key, so every transmit check applies (band, RX-only channel, TX time-out, hotspot mode). The PTT slot is separate from KEY's, so KEY presses work while PTT is held.

3.6 GET_LOG

Firmware code logs with dlog(fmt, ...) (core/debuglink/dlog.h: %d %i %u %x %X %s %c, width, 0 flag; no floats). Lines go into a 2 KB RAM ring as <ms> text; when it is full the oldest lines are dropped and counted. GET_LOG takes whole lines, oldest first (the read removes them), and reports the lines dropped since the last read and whether more remain. Built without the debug link, dlog() compiles to nothing.

3.7 GET_VIEW

The radio's state as key=value lines, one section per request, so each fits a reply. next is the following section, 0xFF after the last. Every section starts with section=<name>; a section cut short ends with truncated=1. Hosts ignore keys they don't know; keys may be added at any time, and view= in the core section (and in VERSION) is bumped only when a key changes meaning or goes away. Each request takes a fresh snapshot (radio_get_view()), so sections may be a few ms apart: compare serial= in the core section when that matters.

Value forms: numbers in decimal (temp, input.*keys in hex with 0x), states as lower-case words, tones as type:value (ctcss:1000 = 100.0 Hz, dcs:19 = D023), strings as they are with control characters replaced by ?. Built without DMR the DMR sections hold dmr.built=0; built without the DMR data features dmr_data holds data.built=0. The DMR sections are rendered in core/debuglink/debuglink_view_dmr.c, apart from the rest, so DMR work can extend them.

3.8 RADIO

Radio requests, queued to the radio core exactly as the UI sends them (core/radio/radio.h); the radio core may refuse them as it would refuse the UI (e.g. a bandwidth change on a DMR channel). Read GET_VIEW to see the effect. At most one per 20 ms (busy otherwise; the radio core's queue holds 16).

Ops 15-18 last until the channel changes (dmr.target_manual); in the DMR VFO ops 15 and 16 set the VFO's own target, which is kept. Unavailable ops answer UNAVAILABLE.

3.9 INFO_CHIP

INFO_CHIP, READ_MEM (3.10) and REBOOT (3.11) go through board.system (hal/hal_system.h). The fields, ranges and modes below are the STM32F4 platform's (platform/stm32f4/sysboot.c) unless the family byte says otherwise.

Read-only. Reply after the status (30 bytes in all; firmware before the family byte sent 29, and was STM32F4 only):

rfoundry_debug.py chip prints all of this (only the family and the UID for a family other than 0), and prints a note at RDP level 1 (the stock state: the ROM bootloader route stays closed) and a loud warning at RDP level 2 or when any application sector (3..11) is write protected.

Example (an STM32F4 radio on the bench): idcode 0x0009A413, 1024 KB, FLASH_OPTCR 0x0FFF55ED: RDP level 1 (byte 0x55), no write protection, BOR off, user bits all 1.

3.10 READ_MEM

Request: address u32, length u16 (1 to 1000). Reply after the status: the address u32, then the bytes. STM32F4 only (INFO_CHIP family 0): any other chip answers UNAVAILABLE. The whole range must lie inside one of these, otherwise the answer is refused (7):

RAM, CCM and peripheral addresses are always refused: a read there can have side effects (clearing a status flag, popping a FIFO). The UID and the flash size register come through INFO_CHIP instead.

RDP and reads: read protection level 1 does not stop the application from reading flash. Level 1 blocks flash access only while a debugger (SWD/JTAG) is connected and when the chip boots from SRAM or system memory (the BOOT pins). After a normal boot from user flash, user code reads every flash address, whether it runs from flash, as this firmware does, or from SRAM, as the flash stub does (stub-stm32f4.md 2; the stub's first bench run confirms it). So READ_MEM works at RDP level 1, and that is how the vendor bootloader is read.

The web flasher and rfoundry read the bootloader sectors this way to find the bootloader key by its SHA-256 so updating a radio that runs RadioFoundry needs no stock file. The bytes stay in memory; only the key is kept.

rfoundry_debug.py dump --addr A --len N -o FILE reads in 1000-byte pieces. It refuses to write inside any git work tree. The vendor bootloader is proprietary: a dump of it is never committed or published.

3.11 REBOOT

Request: mode u8, token u32. Reply: the status and a reason byte.

The token must be the low 32 bits of the chip UID (INFO_CHIP offset 7), so a stray frame can't reboot the radio. The checks, at the request and again just before the reset:

On OK the reply goes out first and the firmware resets 250 ms later. If a check fails at that point (a PTT came in), it logs debuglink: reboot ... aborted and stays up. Mode 1 stores a flag in an RTC backup register that survives the reset, and the start-up code jumps into the ROM bootloader when it finds it.

rfoundry_debug.py reboot [--rom-dfu] reads INFO_CHIP first, refuses --rom-dfu itself unless RDP is level 0, sends the token and prints the radio's reason when it refuses.

3.12 DMR_DATA

Requests to the DMR data service (docs/spec/dmr-data.md), through the same mailbox as the UI's (core/dmr/dmr_data_api.h): the radio task takes them at its next tick, so OK means queued, not sent. Follow the result in the dmr_data view section (data.sms_state, data.signal_state, the counters). IDs are u32 little endian (24 bits used). BUSY: one of the kind is still queued; UNAVAILABLE: built without the data features.

RESET_COUNTERS also zeroes the data service's counters. rfoundry_debug.py data sms|alert|check|settings|inbox|read|emergency|em-settings|ip-settings|ip-send.

3.13 STORAGE

The settings ring / journal region (settings-store.md 5): its state, a read-only SPI flash window for dumping it, and the claim of a foreign region.

rfoundry_debug.py storage info | dump | claim drives it; claim always dumps first, outside any git tree.

3.14 AUDIO_PROBE

A bench tool for the audio path, only in firmware built with CONFIG_AUDIO_PROBE=y (off by default, never for a release). It reads and writes registers of the chip that owns the audio path (board.audio_tap->modem_reg; on a board with an HR_C6000 the HR_C6000, pages and registers as in modem-hrc6000.md), runs the board's PCM stream with its own block callback, which sends a test tone, and measures both I2S channels (core/debuglink/debuglink_audio_probe.c, hal/hal_audio_tap.h). Only boards with an HR_C6000 whose audio path is open provide board.audio_tap today (one board at the moment); on other boards the ops that need it answer UNAVAILABLE. The page, register and RAM semantics in the table are the HR_C6000's.

WATCH polls the flag register about once a millisecond, counts each flag in the mask that it finds set and clears it by writing it to the clear register, and counts the changes of the two-byte RAM word at the address. It blocks the debug link for the whole time. On an HR_C6000 board in FM mode no handler serves the HR_C6000's interrupt lines, so it sees every flag (modem-hrc6000.md 8.1).

The probe borrows the stream: a beep or a DMR channel in the meantime may take it back (STATUS bit 0 then reads 0). Register and RAM writes change the chip under its driver; the radio's next mode change rewrites what it owns. rfoundry_debug.py aprobe status | reg | wreg | start | stop | samples | ram | wram | watch | music | mod drives it; tests/hil/test_audio_probe.py runs the experiments.

3.15 SPLIT

The split duplex repeater (split-duplex.md), built only with CONFIG_HOTSPOT_SPLIT (without it the command answers DL_ST_UNKNOWN_CMD as before; VERSION's feature list then lacks HOTSPOT_SPLIT). The number 0x15 leaves 0x10-0x14 to commands added meanwhile.

View keys: split.built, split.role (normal, tx, rx), split.offered (INFO byte 1), split.flags (INFO byte 9), split.variant, split.cach_method (none, ours, chip, unknown), split.keyed_s, split.lease_expiries, split.time_requests; TX half: split.buf1 / split.buf2 (bursts buffered per slot), split.underruns1 / split.underruns2, split.at_host (the host's AT mask now), split.at_on_air, split.cach (CACH bursts sent), split.idle, split.silence, split.closed, split.slc_taken, split.slc_bad; RX half: split.epoch_us, split.period_ns, split.epoch_age_s (65535 never), split.offset_us (the last phase residual), split.track_us (the anchor's correction), split.busy, split.labeled1 / split.labeled2, split.unlabeled; ALIGN and the scheduled stream (split-duplex.md 3.8, 3.9): split.stream, split.align (STATUS 46), split.phase_us (STATUS 42-45), split.snap_adj_us (the learned restart delay), split.cbase (ALIGN counter minus the driver's), split.sched_sent, split.sched_late, split.sched_refused, split.sched_replaced, split.sched_cooldown, split.slew_steps / split.slew_us (slot trims asked of the driver and their sum, µs), split.meta_sent (RX_META events, 3.10). No GET_VIEW section is added, so section numbers stay the same in every build. rfoundry_debug.py split view | variant N [REG=VAL ...].

3.16 APRS

Bench control of APRS (aprs.md 13). Built without CONFIG_APRS every operation answers DL_ST_UNAVAILABLE. The state is in the aprs and aprs_set view sections.

rfoundry_debug.py aprs send | status TEXT | msg CALL TEXT | call [CALL] | set FIELD VALUE | nmea SENTENCE.

3.17 SNMP

The SNMP agent's settings (snmp.md 6, 7). Built without CONFIG_SNMP every operation answers DL_ST_UNAVAILABLE. The state is in the snmp view section.

rfoundry_debug.py snmp status | set FIELD VALUE | read [TEXT] | write [TEXT] | trap (flags as a number or names: off,rf_off,rf_write,usb_traps_off,auth_traps,rf_call_traps).

3.18 STUB

Load the host's flash-access RAM monitor into a free RAM span and hand the SoC to it at run time, no power cycle (CONFIG_STUB_ENTRY, its own feature: stub-entry.md; a build without the debug link answers this command with its own listener, byte for byte the same). Two platforms have it: the HR_C7000 (the "C7 stub", stub-entry.md) and the STM32F4 (stub-stm32f4.md). Built without the switch, or on a board whose platform has no hal_system_t.enter_stub, every operation answers DL_ST_UNAVAILABLE. All u32 are little endian. The guard is a 32-bit magic key 'C7SB' (0x42533743) on BEGIN and ENTER, plus the exact length and a CRC-32 of the whole image checked before the jump.

The CRC-32 is the standard (zlib) CRC-32. Per-chunk integrity is the debug link frame's own CRC-16, so DATA carries no second checksum; the span is zeroed at BEGIN, so a dropped chunk leaves zeros that fail the ENTER CRC-32. After an ok ENTER the firmware sends the reply, draws a static banner on the display ("PC Loader Connected" / "Power-cycle to exit", flushed synchronously so the panel does not sit on a stale or hung frame while the monitor runs) with the backlight at full, then quiesces and jumps and stops answering; the host then speaks the monitor's own protocol (02 op len chk 03, the stub's PROTOCOL.md) on the same UART at the same baud. Recover the radio with a power cycle.

Where the image runs: INFO's load_addr is the address the image is linked for, and the host builds BEGIN's entry from it. On the HR_C7000 that is the span itself. On the STM32F4 the span is a staging buffer in RadioFoundry's own RAM and load_addr is the SRAM base (0x20000000, hal_system_t.stub_run_addr): enter_stub stops the DMA controllers, copies the buffer there and jumps with a handoff flag in r0 (stub-stm32f4.md 3). The STM32F4 stub then answers on the USB serial port, with the same framing as the C7 stub. ENTER is answered busy (3) while the radio transmits.

The monitor never touches the RF chips, so the transmitter stays as RadioFoundry left it for the whole session. ENTER is refused while the radio core is transmitting, the entry is dropped if PTT went down in the 100 ms between the reply and the jump, and the firmware calls board.radio->tx_off() just before the jump in every case.

On the HR_C7000 the host sends the universal monitor: its entry is position independent, copies the image from load_addr to its run address (0x30000) and runs there, with .bss and stack after it (stub/README.md, RAM placement). The firmware does not check where the image will run (it only checks the length, the CRC-32 and that entry lies inside the span); the host does: stubtool.py reads INFO first and refuses a span whose copy would overlap the run address or leave SRAM. The older position-dependent monitors (--legacy-stub, --rfoundry-stub FILE) must be linked for exactly load_addr; the host refuses one whose linked data and stack lie outside the span or that does not end its text and data at load_addr plus its length. On the STM32F4 the host checks instead that the image starts with the STM32F4 stub's entry code and that load_addr is the SRAM base. INFO is the whole discovery protocol, so firmware built before a board moved its span keeps working with the same tool.

3.19 CRASH

The crash log (CONFIG_CRASH_LOG, crash-log.md): forget the kept record, or crash on purpose so a HIL test can check the capture. Built without the switch, every operation answers DL_ST_UNAVAILABLE.

The token is 'CRSH' (0x48535243, little endian in the payload); another value, or a transmitting radio, is answered refused (7). The test is dropped if PTT went down between the reply and the crash. The record shows in view section 21 after the restart. rfoundry_debug.py crash [show|clear|test trap|test assert|test hang].

3.20 CODEPLUG

The fast codeplug protocol: the open-firmware codeplug image read and written in 4 KB blocks, with CRC-32 sums so only changed blocks move, blank blocks reported and not sent, LZ4 streams both ways, and a staged commit where the board has a staging area (cps-fast.md). CONFIG_CPS_FAST builds only, else status 4.

A refusal (DL_ST_REFUSED) carries a reason byte: 1 outside the image or a protected area, 2 the flash can't be written, 3 no staging area, 4 staging full, 5 staging busy, 6 out of order, 7 CRC, 8 bad stream, 9 flash failure. tools/cps_fast.py info | read | write | verify drives it.

3.21 WATCHDOG

The hardware watchdog's bench tests (CONFIG_WATCHDOG, watchdog.md 6). Every test ends in a watchdog reset. Built without the switch, every operation answers DL_ST_UNAVAILABLE.

The token is 'WDOG' (0x474F4457, little endian in the payload); another value, or a transmitting radio, is answered refused (7). A test is dropped if PTT went down between the reply and its start. During STARVE and LOAD the view's watchdog.starved_ms counts from the last feed; its last value before the link goes quiet bounds the timeout. rfoundry_debug.py watchdog [show|clear-gap|test starve|spin|irq-off|load H L [RST]].

3.22 RX2

The second receiver's SoC, on a radio with two (board.rx2, the GD-88; rx2-link.md). Always built. On a radio with one SoC, INFO answers no flags and the rest DL_ST_UNAVAILABLE.

The token is 'BRDG' (0x47445242, little endian in the payload); another value, or a transmitting radio, is answered refused (7). The bridge is dropped if PTT went down between the reply and its start. rfoundry_debug.py rx2 [info|restart]; stubtool.py --board gd88b uses BRIDGE.

4. Safety

• PTT: a firmware time-out on every injected PTT (10 s maximum); the host tool refuses longer holds; the radio core's own TX time-out and transmit checks still apply.
• Every injected key hold is capped at 10 s, one injected key at a time, 40 ms between them.
• Radio requests are rate limited (20 ms).
• INFO_CHIP and READ_MEM only read. READ_MEM reads flash, system memory, OTP and option bytes only, never RAM or peripherals. Nothing in the debug link writes or erases internal flash or the option bytes.
• STUB ENTER is refused while transmitting, and the transmitter is switched to receive before the jump (3.18).
• CRASH TEST needs its token and is refused while transmitting (3.19).
• WATCHDOG TEST and LOAD need their token and are refused while transmitting; each ends in a reset (3.21).
• RX2 BRIDGE and RESTART need their token and are refused while transmitting. The bridge keeps the transmitter off and ends in a restart (3.22).
• REBOOT needs the chip UID's low word as a token, is refused while transmitting, and the ROM DFU mode is refused unless RDP is level 0. The host tool checks RDP too.
• Memory dumps are never written inside a git tree (the vendor bootloader is proprietary).
• AUDIO_PROBE (diagnostic builds only) writes audio chip registers as asked; nothing else in the debug link writes chip registers.
• STUB (bench builds only) writes arbitrary RAM and then runs it, giving the host full control: it is gated by a magic key, the exact length and a CRC-32, loads only into the platform's declared free RAM span, is refused while transmitting, and never returns (recover by a power cycle). Off in a release. The stub, not the debug link, is what writes flash (stub-stm32f4.md 6 for the STM32 one's rules).
• CODEPLUG writes only codeplug blocks of the open-firmware image, never the settings ring, the journal, the native area, the staging area or the calibration window, through the journal or a staged commit (3.20).
• The debug link never enters hotspot or CPS mode, and never takes bytes that belong to an MMDVM frame or a CPS request (section 1).

5. Counters and resets

RESET_COUNTERS zeroes: the board's diagnostics counters (board.diag_reset, whatever the board counts; on a board with an HR_C6000 the slot engine counters, the RF switch counters and the DMR audio counters), the DMR call stack counters (dmr_call_reset_stats), the AMBE voice counters (ambeVoiceResetStats), the beep counters (beep_reset_stats) and the DMR data service counters (dmrDataServiceResetStats). States and "last" values (last CC, last sync, engine TX state) are kept. The resets are not atomic with respect to the tasks and interrupts that count: an increment racing the reset may survive it; a test that resets, waits a moment and then starts its traffic is not affected.

6. Adding a command

Add the number to debuglink_proto.h, a handler in core/debuglink/debuglink.c (short, non-blocking, reply at most 1024 bytes), a row here, and a method in tools/rfoundry_debug.py. New view keys need only the renderer and the table in 3.7.

View the source of this page