IMPLEMENTING UPDI FROM SCRATCH
Post Stastics
- This post has 9076 words.
- Estimated read time is 43.22 minute(s).
Part VI โ The Complete Reference Design, Operating Guide, Troubleshooting Manual, and Resources
Updated for the finalized NANO UPDI PROGRAMMER Rev. 1.0.0 hardware
We began this series with one deceptively simple question:
What is UPDI?
Six parts later, the answer is considerably richer than:
โIt is Microchipโs one-wire programming interface.โ
UPDI is indeed a one-wire physical interface, but that single wire sits underneath an entire programming and debugging architecture.
We have seen:
electrical interface
โ
asynchronous 8E2 serial transport
โ
BREAK / SYNCH / ACK
โ
UPDI instruction set
โ
target address-space access
โ
NVM controller
โ
Flash / EEPROM / fuses / USERROW
and, on the debugging side:
electrical interface
โ
UPDI
โ
On-Chip Debug system
โ
halt / run / step
โ
registers / memory / breakpoints
โ
debug server
โ
GDB
โ
source-level debugging
We also learned that high-voltage UPDI is not a programming voltage in the old-fashioned sense. It is an interface activation mechanism, and there is more than one kind of it.
Microchipโs current documentation explicitly distinguishes three UPDI arrangements: older shared UPDI/RESET/GPIO pins using approximately 12 V recovery, dedicated UPDI pins requiring no HV recovery, and newer shared UPDI/GPIO arrangements with a separate RESET pin where the HV pulse is applied to RESET at approximately VDD + 2 V.
Now it is time to put everything together.
This final part is intended to serve as the practical reference chapter: the section you come back to when building the hardware, wiring a target, troubleshooting a failure, extending the firmware, or trying to remember which layer is responsible for what.
Final Hardware Baseline for the Reference Design
This final chapter assumes the completed NANO UPDI PROGRAMMER Rev. 1.0.0 hardware developed throughout Parts IโV.
The Nano assignments are:
| Nano pin | Function |
|---|---|
| D2 | ACT/status indication |
| D3 | HV/status indication |
| D4 | TARGET_RESET_CTRL |
| D5 | UPDI_RX |
| D6 | UPDI_TX |
| D7 | HV_ENABLE |
| D8 | TARGET_POWER_ENABLE |
| A0 | VTARGET_SENSE |
| A1 | HV_SENSE |
| A4/A5 | Optional IยฒC expansion |
| D10โD13 | Optional SPI expansion |
The finalized target connector is:
J2-1 TARGET_RESET J2-2 VTARGET J2-3 UPDI_DATA J2-4 GND
The target still sees one UPDI data conductor. Inside the programmer, that line is implemented through separate transistor TX and RX paths:
Nano D6 / UPDI_TX
|
R8 47k
|
Q4 2N3904
open-collector pull-down
|
+-------------------- UPDI_DATA -------------------- target UPDI
|
R5 47k
|
Q2 2N3904
receive translator
|
Nano D5 / UPDI_RX
Q4 has R24 = 47 kฮฉ from base to ground so the transmitter defaults OFF during Nano reset. Q2’s collector is pulled to +5 V through R2 = 47 kฮฉ.
The optional pull-up assist is:
VTARGET | D1 SS14 | R4 33k DNP | UPDI_DATA
R4 is DNP by default.
Voltage sensing is built in:
VTARGET -> R10 22k / R12 10k -> R11 1k -> A0 HV -> R13 33k / R15 10k -> R14 1k -> A1
Both ADC inputs include Schottky clamps to +5 V and 0.1 ยตF filtering.
The target RESET driver is:
D4 -> R18 4.7k -> Q6 2N3904 -> TARGET_RESET
|
R19 47k
|
GND
The finalized externally supplied HV switch is:
External HV
|
Q1 2N3906 PNP
|
R6 680ฮฉ
|
J4 HV route/arm
| | \--> HV_OUT
|
+-----> TARGET_RESET / RESET-HV route
D7 -> R7 4.7k -> Q3 2N3904 -> Q1 base through R3 4.7k
R1 = 47k biases Q1 OFF
R9 = 47k biases Q3 OFF
The optional target-power block is controlled by D8 and uses Q5 plus relay K1.
This is the authoritative hardware baseline for Part VI.
432. Our Reference Target
Our primary teaching target remains:
AVR16DU28-I/SP
The /SP part is a 28-pin SPDIP device, making it particularly useful for breadboarding.
Microchip currently lists the AVR16DU28 as an in-production AVR DU device with native USB and provides the current complete AVR DU data sheet from its product page.
Our alternative reference devices are:
AVR32DU28-I/SP
AVR16DD28-I/SP
The AVR32DU28 is particularly convenient because it preserves much of the AVR16DU28 architecture while increasing memory.
The AVR16DD28 gives us an important comparison target because it also uses UPDI but belongs to a different AVR family and does not use the same NVM-controller implementation as AVR DU.
Microchip likewise lists the AVR16DD28 as an in-production device.
The lesson should now be familiar:
โSupports UPDIโ does not mean โall programming details are identical.โ
433. Our Development Programmer
The teaching programmer remains based on:
Arduino Nano ATmega328P 16 MHz 5 V Arduino IDE
The Nano is deliberately not the ideal modern UPDI implementation.
It lacks:
- native USB;
- a modern hardware one-wire USART;
- multiple voltage domains;
- onboard programmable HV generation;
- large RAM.
But the finalized external circuitry solves the most important electrical limitations while keeping the system understandable.
The Nano now provides:
D6 = UPDI_TX D5 = UPDI_RX D4 = TARGET_RESET_CTRL D7 = HV_ENABLE D8 = TARGET_POWER_ENABLE A0 = VTARGET_SENSE A1 = HV_SENSE
and the target sees:
one UPDI conductor one RESET connection one VTARGET connection one GND connection
The design therefore remains simple enough for a hobbyist while being much more capable than the original one-resistor teaching circuit.
434. The Final Hardware Architecture
The reference tool is best understood as five hardware blocks.
Block 1 โ Nano control core
Arduino Nano / ATmega328P
handles:
- host serial communications;
- UPDI bit timing;
- protocol state;
- NVM operations;
- debug primitives;
- voltage measurements;
- reset/HV/power-control outputs.
Block 2 โ UPDI translator
D6 -> Q4 -> UPDI_DATA UPDI_DATA -> Q2 -> D5
provides:
- open-collector target drive;
- Nano/target voltage-domain separation;
- low-voltage target support by design;
- target-side HV tolerance for old shared-pin recovery;
- continuous RX visibility.
Block 3 โ Target reset control
D4 -> Q6 -> TARGET_RESET
provides ordinary low-voltage reset independently of HV.
Block 4 โ HV activation path
external bench HV
โ
Q1/Q3 high-side switch
โ
R6 680 ฮฉ
โ
J4 route/arm
โ
TARGET_RESET or HV_OUT
provides modern RESET-HV and deliberately routed older shared-pin HV experiments.
Block 5 โ Sensing and optional target power
A0 = VTARGET sense A1 = HV sense D8 = optional target-power relay
These blocks together form the complete reference programmer/recovery/debugger.
435. Final UPDI Interface Wiring
The authoritative UPDI wiring is:
ARDUINO NANO
D6 / PD6 UPDI_TX
|
R8 47k
|
base
Q4 2N3904
emitter ------------------------------- GND
collector
|
+----------------------------------- UPDI_DATA
| |
| +---- J2 pin 3 -> target UPDI
|
+---- R5 47k ---- base
Q2 2N3904
emitter ------------ GND
collector
|
+--------------- D5 / PD5 UPDI_RX
|
R2 47k
|
+5V
Q4 DEFAULT-OFF BIAS:
Q4 base
|
R24 47k
|
GND
OPTIONAL PULL-UP ASSIST:
VTARGET
|
D1 SS14
|
R4 33k DNP
|
UPDI_DATA
The target’s own UPDI pull-up remains the primary source of the idle-HIGH level.
R4 is not normally populated.
436. Final UPDI Connection Table
| From | Through | To | Purpose |
| Nano D6 / PD6 | R8 = 47 kฮฉ | Q4 base | UPDI transmit control |
| Q4 emitter | direct | GND | TX reference |
| Q4 collector | direct | UPDI_DATA | Open-collector target pull-down |
| Q4 base | R24 = 47 kฮฉ | GND | TX default OFF |
UPDI_DATA | R5 = 47 kฮฉ | Q2 base | Receive sensing |
| Q2 emitter | direct | GND | RX reference |
| Q2 collector | direct | Nano D5 / PD5 | UPDI receive |
| Q2 collector | R2 = 47 kฮฉ | +5 V | RX pull-up |
| VTARGET | D1 SS14 + R4 33 kฮฉ DNP | UPDI_DATA | Optional pull-up assist |
UPDI_DATA | direct | J2 pin 3 | Target UPDI |
| GND | direct | J2 pin 4 | Common reference |
This table is authoritative if an ASCII diagram is unclear.
437. Why the Old 4.7 kฮฉ Teaching Circuit Is No Longer the Reference Design
Earlier in the series we used the familiar:
Nano D6 ---- 4.7 kฮฉ ---- target UPDI
circuit to explain how minimal Arduino UPDI programmers work.
It remains useful historically and pedagogically.
It is not the final hardware.
The finalized two-transistor interface is preferred because it gives us:
- separate TX and RX GPIOs;
- target-referenced HIGH levels;
- improved support for 1.8 V, 3.3 V, and 5 V targets;
- better protection from old-style 12 V shared-pin activation;
- easier bus-state observation;
- no need to change one Nano GPIO repeatedly between input and output.
The 4.7 kฮฉ series-resistor circuit should therefore be treated only as a minimal teaching example, not as the recommended completed programmer.
438. Why the Final UPDI Interface Is Better for Multiple Voltages
Q4 only pulls the target line LOW.
It never drives target UPDI HIGH.
When Q4 is OFF, the target-side logic HIGH is established in the target’s voltage domain.
Therefore:
VTARGET = 1.8 V -> UPDI HIGH in the 1.8 V domain VTARGET = 3.3 V -> UPDI HIGH in the 3.3 V domain VTARGET = 5.0 V -> UPDI HIGH in the 5 V domain
The Nano’s D6 pin remains entirely in the 5 V logic domain.
Likewise, Q2 translates the target line into a Nano-safe 5 V collector signal on D5.
The receive path is inverted electrically, and firmware hides that inversion behind the UPDI PHY abstraction.
439. Why a Generic IยฒC Level Shifter Is Still Not Automatically Ideal
The classic BSS138 IยฒC translator is attractive because UPDI is also:
one wire bidirectional
But protocol topology alone does not make two electrical systems identical.
IยฒC is inherently open drain.
UPDI has its own timing, framing, autobaud, and turnaround behavior.
The final reference design therefore uses the simpler BJT arrangement that we have explicitly analyzed and can qualify on the bench.
Other translators may work.
They should be judged by measured waveform quality, not by visual similarity to an IยฒC schematic.
440. Final Target Connector
The finalized four-pin target connector is:
J2-1 TARGET_RESET J2-2 VTARGET J2-3 UPDI_DATA J2-4 GND
This pin order should be documented consistently on:
- PCB silkscreen;
- schematic;
- cable;
- user manual;
- tester documentation.
For ordinary UPDI, RESET may not be required.
For modern RESET-HV recovery, it becomes essential.
The connector itself does not determine the HV voltage or mode. The target profile, external bench-supply setting, J4 route selection, voltage sensing, and firmware interlocks do.
441. Final VTARGET Sensing
The completed VTARGET circuit is:
VTARGET | R10 22k | +---- R11 1k ---- A0 | R12 10k | GND
with:
C1 = 0.1 ยตF D2 = BAT54-02V clamp to +5 V
The nominal ratio is:
[
V_{A0}=V_{TARGET} rac{10}{22+10}=0.3125V_{TARGET}
]
so:
[
V_{TARGET}=3.2V_{A0}
]
Representative divider-node voltages are:
| VTARGET | A0 node |
| 1.8 V | 0.563 V |
| 3.3 V | 1.031 V |
| 5.0 V | 1.563 V |
| 5.5 V | 1.719 V |
| 12 V | 3.750 V |
| 15 V | 4.688 V |
The wide range gives useful abnormal-voltage headroom while preserving good resolution across normal AVR operating voltages.
442. Final VTARGET ADC Protection
The A0 network deliberately combines:
divider + R11 = 1 kฮฉ series resistance + external Schottky clamp + 0.1 ยตF filtering
The 1 kฮฉ resistor limits current into the ADC/clamp during abnormal conditions.
One operational caution follows from clamping to the Nano +5 V rail:
Power the Nano before applying external VTARGET whenever practical.
Otherwise the clamp network can partially back-power the Nano rail.
443. Final HV Sensing
The completed HV sense circuit is:
external HV | R13 33k | +---- R14 1k ---- A1 | R15 10k | GND
with:
C2 = 0.1 ยตF D3 = BAT54-02V clamp to +5 V
The ratio is:
[
V_{A1}=V_{HV} rac{10}{33+10}
]
or approximately:
[
V_{A1}=0.23256V_{HV}
]
Representative values:
| External HV | A1 node |
| 7.5 V | 1.744 V |
| 8.5 V | 1.977 V |
| 12 V | 2.791 V |
| 15 V | 3.488 V |
| 18 V | 4.186 V |
| 20 V | 4.651 V |
| ~21.5 V | ~5.0 V |
This gives comfortable headroom for both modern RESET-HV and old shared-pin 12 V work.
444. Modern RESET-HV Reference Values
For applicable modern RESET-HV devices, representative documented values are:
VHV minimum: VDD + 2 V VHV typical: 7.5 V VHV maximum: 8.5 V minimum pulse: 10 ยตs key window: approximately 65 ms
subject always to the exact device data sheet and absolute maximum ratings.
A practical laboratory pulse around:
100 ยตs
is a reasonable starting point where it matches the documented target sequence.
The programmer should evaluate the measured A0 VTARGET and A1 HV values before arming the pulse.
445. Final RESET-HV Switch
The finalized switch uses BJTs rather than a P-channel MOSFET:
Q1 = 2N3906 PNP high-side switch Q3 = 2N3904 NPN driver
Conceptually:
EXTERNAL HV
|
emitter Q1
2N3906
|
collector
|
R6 680ฮฉ
|
J4 route/arm
/ \
/ \
HV_OUT TARGET_RESET
Q1 is controlled by Q3:
Nano D7 | R7 4.7k | Q3 base | Q3 collector | R3 4.7k | Q1 base
Default-OFF biasing is provided by:
R1 = 47 kฮฉ around Q1 R9 = 47 kฮฉ on Q3 base
The Nano never generates or directly touches the HV rail.
446. Final RESET-HV Wiring Table
| From | Through | To | Function |
| External HV + | direct | Q1 emitter | HV source |
| Q1 emitter | R1 = 47 kฮฉ | Q1 base | Q1 default OFF |
| Q1 base | R3 = 4.7 kฮฉ | Q3 collector | Q1 pull-down control |
| Nano D7 | R7 = 4.7 kฮฉ | Q3 base | HV_ENABLE |
| Q3 base | R9 = 47 kฮฉ | GND | Q3 default OFF |
| Q3 emitter | direct | GND | Reference |
| Q1 collector | R6 = 680 ฮฉ | J4 common | Current-limited switched HV |
| J4 | selected route | TARGET_RESET or HV_OUT | Physical destination |
| External HV โ | direct | GND | Reference |
| Nano GND | direct | target GND | Common reference |
447. J4 Is the Physical HV Safety Interlock
The finalized design already includes:
J4 = HV route/arm selector
rather than a generic future JP1.
With no route selected:
firmware cannot deliver HV to the target
even if:
- D7 glitches;
- software crashes;
- a host command is malformed.
When armed, J4 also makes the HV destination explicit.
That matters because:
RESET-HV
and:
old shared-UPDI 12 V HV
are not interchangeable.
448. Hardware Defaults OFF
Safety-critical hardware states are established with passive biasing, not just firmware.
On Nano reset:
Q4 UPDI TX = OFF / target line released Q6 target RESET = OFF Q3 HV driver = OFF Q1 HV switch = OFF Q5 target power = OFF unless deliberately commanded
Relevant pull-down/default resistors include:
R24 = 47 kฮฉ Q4 TX default OFF R19 = 47 kฮฉ Q6 RESET default OFF R9 = 47 kฮฉ Q3 HV driver default OFF R17 = 47 kฮฉ Q5 target-power default OFF
and Q1 is biased OFF through R1 = 47 kฮฉ.
This is the correct behavior during bootloader execution, USB autoreset, firmware crashes, and power sequencing.
449. Old-Style 12 V Shared-Pin UPDI
Older compatible devices may require approximately:
12 V
on the same physical pin later used for UPDI communication.
The finalized hardware is much better suited to that case than the original one-resistor interface.
The Nano is not directly connected to UPDI_DATA.
Instead:
UPDI_DATA -> R5 47k -> Q2 base -> Nano D5 through Q2 collector
and:
Nano D6 -> R8 47k -> Q4 base -> Q4 collector -> UPDI_DATA
During a shared-pin HV event, the Nano GPIOs remain on the low-voltage sides of the transistors.
The optional pull-up branch is reverse-isolated by D1.
450. Keep RESET-HV and UPDI-12V-HV Distinct
The final hardware deliberately preserves two routes:
modern RESET-HV -> TARGET_RESET legacy/shared-pin HV -> HV_OUT -> deliberately wired to shared UPDI/HV target node
A universal programmer should never reduce those to one generic:
HV
button.
The safer logic remains:
identify target
โ
select HV method
โ
verify destination
โ
measure allowed voltage
โ
confirm J4 route
โ
pulse with target-specific timing
451. Device Descriptor โ Final Form
Our host/device database should ultimately contain something like:
@dataclass**(**frozen=True)
class DeviceDescriptor:
name: str signature: bytes flash\_size: int flash\_page\_size: int eeprom\_size: int nvm\_version: str debug\_version: str nvmctrl\_base: int sigrow\_base: int fuse\_base: int userrow\_base: int **|** None bootrow\_base: int **|** None min\_vdd\_mv: int max\_vdd\_mv: int hv\_mode: str hv\_pin: str **|** None hv\_typical\_mv: int **|** None hv\_max\_mv: int **|** None hv\_key\_timeout\_ms: int **|** None
NVM and debug versions should remain distinct.
AVRDUDEโs current serial-UPDI implementation explicitly parses separate NVM and DEBUG version strings from the SIB and selects its NVM backend accordingly.
452. Why the SIB Matters
The System Information Block can tell us more than merely:
โI am an AVR.โ
Current AVRDUDE source separates SIB fields for:
family
NVM interface
debug interface
PDI/UPDI oscillator
additional information
and currently recognizes multiple NVM generations, including types 0, 2, 3, 4, 5, and 6.
That is powerful evidence that a mature programmer should not assume:
one UPDI protocol
=
one NVM algorithm
The device tells us what backend it needs.
453. AVR DU NVM P:4
Microchipโs official pymcuprog source currently identifies P:4 as present on AVR DU and defines its key command values, including:
NOCMD 0x00
FLASH_WRITE 0x02
FLASH_PAGE_ERASE 0x08
EEPROM_WRITE 0x12
EEPROM_ERASEWRITE 0x13
EEPROM_BYTE_ERASE 0x18
CHIP_ERASE 0x20
EEPROM_ERASE 0x30
It also documents in code that this NVM version has no page buffer and writes Flash words directly.
That implementation is an excellent reference because it comes from Microchipโs own open-source programming software.
454. Final Firmware Architecture
The Nano firmware should remain layered.
A suggested organization is:
firmware/ | +-- NanoUPDI.ino | +-- updi_phy.h +-- updi_phy.cpp | +-- updi_link.h +-- updi_link.cpp | +-- updi_instruction.h +-- updi_instruction.cpp | +-- target_device.h +-- target_device.cpp | +-- nvm_backend.h +-- nvm_p4.cpp +-- nvm_p2.cpp +-- ... | +-- debug_backend.h +-- debug_v1.cpp +-- debug_v2.cpp +-- ... | +-- voltage_sense.h +-- voltage_sense.cpp | +-- target_reset.h +-- target_reset.cpp | +-- target_power.h +-- target_power.cpp | +-- hv_control.h +-- hv_control.cpp | +-- host_protocol.h +-- host_protocol.cpp | +-- selftest.h +-- selftest.cpp
The hardware-specific responsibilities are explicit:
updi_phy
D6/D5
Q4/Q2 inversion semantics
timing
BREAK
8E2
voltage_sense
A0 VTARGET
A1 HV
calibration
range checks
target_reset
D4 / Q6
hv_control
D7 / Q3 / Q1
J4 route policy
pulse timing
interlocks
target_power
D8 / Q5 / K1
The important rule remains:
physical layer does not know about Flash NVM backend does not toggle D6 directly debug backend does not parse Intel HEX host protocol does not contain bit timing
This isolation makes the project maintainable.
455. Final Host Architecture
The PC side should contain the expensive intelligence.
host/
|
+– nanoupdi/
| |
| +– serial_link.py
| +– protocol.py
| +– programmer.py
| +– debugger.py
| +– devices.py
| +– memories.py
| +– intelhex.py
| +– verify.py
| +– breakpoints.py
| +– gdb_rsp.py
| +– errors.py
|
+– tests/
The PC can comfortably handle:
device database
Intel HEX parsing
ELF metadata
GDB protocol
logging
page merging
backups
verification
breakpoint state
The Nano should not.
456. Why This Division Is So Effective
The ATmega328P has:
2 KB SRAM
The host may have gigabytes.
There is little value in consuming scarce Nano RAM on:
512-byte page cache
large device table
HEX parser
symbol resolver
breakpoint journal
when the PC can do those things easily.
So:
PC:
policy storage parsing UI tests
Nano:
timing electrical control UPDI primitives target transactions
is the right division.
457. Final Human Console
Keep the simple diagnostic console even after a binary host protocol exists.
Useful commands:
help
info
wake
break
status
sib
signature
read <address> <count>
write <address> <data>
enter-programming
leave-programming
erase-chip
erase-page <address>
read-flash
write-flash
read-eeprom
write-eeprom
fuses
vtarget
vhv
hv-info
hv-arm
hv-pulse
hv-enter
hv-disarm
power-on
power-off
dbg-enter
dbg-halt
dbg-run
dbg-step
dbg-status
dbg-pc
dbg-sp
dbg-sreg
selftest
A human-readable console remains invaluable for troubleshooting.
458. Suggested Startup Report
A mature Nano firmware might print:
NanoUPDI 1.0.0 -------------------------------- Firmware: Build: 2026-08-23 F_CPU: 16000000 Hz Host: Baud: 500000 UPDI: TX: D6 / PD6 RX: D5 / PD5 Interface: Q4/Q2 transistor bridge Baud: 225000 Pull-up assist: DNP Target control: Reset: D4 HV enable: D7 Target power: D8 Voltage sense: VTARGET: A0 HV: A1 HV: Route/arm: DISARMED Measured input: 0.00 V Target: VDD: 0.00 V READY
A tool should tell the user what hardware and state it actually has.
459. First-Time Hardware Commissioning Procedure
Before using a target MCU:
Step 1 โ Inspect
Check:
- shorts;
- transistor orientation and pinout;
- R8/R5/R2/R24 values;
- Q4/Q2 orientation;
- ground continuity;
- ADC divider wiring;
- Q1/Q3 HV wiring;
- R6 = 680 ฮฉ;
- J4 route/arm wiring;
- target connector polarity;
- relay/flyback orientation if target-power hardware is fitted.
Step 2 โ Power only the Nano
Do not connect a target or external HV.
Confirm:
firmware starts Q4 TX defaults OFF Q6 RESET defaults OFF Q1/Q3 HV path defaults OFF target-power relay defaults OFF
Step 3 โ Test the Nano-side TX signal
Transmit:
0x55 0x00 0xFF 0x01 0x80
and inspect:
Nano D6 / UPDI_TX
Step 4 โ Test the target-side UPDI waveform
Provide a safe target-domain pull-up or connect a normal powered target.
Probe:
UPDI_DATA
Confirm the Q4 stage produces the expected inverted open-collector waveform.
Also observe D5 to confirm the Q2 receive stage tracks the target line with the expected electrical inversion.
Step 5 โ Test VTARGET measurement
Apply known values:
1.8 V 3.3 V 5.0 V
through a current-limited source and compare A0-derived readings with a DMM.
Step 6 โ Test HV sense
Apply a safe known voltage to the HV input with J4 disarmed.
Verify A1 measurement.
Step 7 โ Test the HV switch
With no target attached:
set bench HV arm appropriate J4 route scope switched output issue controlled pulse
Confirm:
- correct amplitude;
- correct pulse duration;
- output returns OFF;
- Q1/Q3 default-OFF behavior.
Step 8 โ Test physical RESET control
Verify D4/Q6 can assert and release TARGET_RESET without involving HV.
Step 9 โ Test target-power control if fitted
Verify relay operation and flyback behavior.
Step 10 โ Test interlocks
Verify HV refuses to fire when:
- J4 route is not armed;
- measured voltage is too low;
- measured voltage is too high;
- selected target profile is incompatible.
Only then attach the AVR for destructive or HV testing.
460. First Ordinary-UPDI Target Test
With AVR16DU28-I/SP at nominal 5 V:
1. Connect VDD.
2. Connect GND.
3. Connect UPDI through R1.
4. Leave RESET/HV disconnected initially.
5. Power system.
6. Run status.
7. Read SIB.
8. Read signature.
Expected identity:
AVR16DU28
If identification works repeatedly:
100
1000
10,000 times
without errors, the physical link is likely healthy.
461. First Programming Test
Use a sacrificial or backed-up target.
Procedure:
1. Read signature.
2. Backup Flash.
3. Backup EEPROM.
4. Backup fuses.
5. Enter programming mode.
6. Read Flash.
7. Chip erase.
8. Verify erased bytes = FF.
9. Program a known small image.
10. Read back.
11. Compare every byte.
12. Reset.
13. Confirm application executes.
Do not begin with fuse changes.
462. Recommended First Firmware Image
Use something obvious.
For example:
LED toggles at 1 Hz
or:
UART prints a counter
A tiny known program gives us two verification mechanisms:
Flash byte verification
+
visible functional behavior
Both should agree.
463. Intel HEX Workflow
The host should perform:
HEX file
โ
validate record checksums
โ
build sparse image
โ
check against target Flash size
โ
construct Flash pages
โ
skip completely erased pages
โ
send blocks to Nano
โ
read back
โ
compare
Microchipโs own pymcuprog CLI supports writing Intel HEX files, explicit erase, and verification, and warns that chip erase may preserve EEPROM depending on the targetโs EESAVE setting.
That is a useful reference for our own host behavior.
464. Backups Before Experimentation
A convenient command should be:
nanoupdi backup backup-20260823/
producing:
device.json
flash.bin
eeprom.bin
fuses.json
userrow.bin
bootrow.bin
where applicable.
Do this before:
fuse experiments
software breakpoint development
HV recovery experiments
security experiments
Backups turn many mistakes from disasters into inconveniences.
465. Fuse-Write Procedure
A safe fuse workflow is:
read target identity
โ
read current fuse
โ
decode current fields
โ
validate requested field
โ
preserve unrelated fields
โ
apply reserved-bit rules
โ
show old value
โ
show new value
โ
show consequences
โ
explicit confirmation
โ
write
โ
reset as required
โ
read back
โ
verify
Never implement:
fuse address + arbitrary byte
as the normal user interface.
Keep that only as an advanced engineering command, if at all.
466. Security Settings Need a Different UI
Normal fuse:
BOD threshold
and security setting:
disable programming/debug interface
should not look equivalent.
Especially on devices supporting PDID, Microchip warns that UPDI cannot be restored through the RESET-HV mechanism after PDID is activated.
Security operations should therefore be placed under commands such as:
security …
rather than ordinary:
fuse-write …
and should require strong confirmation.
467. First HV Test on a Target
Do this only after ordinary programming has been proven.
Procedure:
1. Backup device.
2. Identify target.
3. Verify target’s HV mode.
4. Measure VDD.
5. Measure HV.
6. Confirm physical ARM jumper.
7. Scope RESET/HV.
8. Perform one HV activation.
9. Immediately establish UPDI.
10. Deliver valid key.
11. Confirm key acceptance.
12. Confirm programming mode.
13. Restore normal configuration if intentionally altered.
14. Power-cycle.
15. Confirm ordinary UPDI operation.
Microchipโs current documentation says that newer RESET-HV activation temporarily overrides the relevant pin configuration and requires target-specific sequencing; it also warns about damage to other circuitry attached to RESET.
468. Why RESET Networks Can Break HV
Suppose target RESET has:
1 ยตF to GND
and our HV switch has:
1 kฮฉ series resistance
Then:
ฯ = RC = 1 ms
A:
100 ยตs
pulse is far shorter than one RC time constant.
RESET may never reach the HV detection threshold.
So if:
switch output looks correct
but:
target RESET does not
inspect the target reset network.
Always scope the actual MCU pin.
469. Removable Jumpers Are Often Better Than Clever Protection
If RESET is shared with application circuitry that cannot tolerate:
7.5โ8 V
a removable jumper may be the best design.
Likewise, if an old shared UPDI/GPIO pin has external circuitry that cannot tolerate 12 V:
disconnect it during HV recovery.
Microchip explicitly cites removable isolation as an appropriate approach where connected circuitry may be damaged.
Simple is often safer.
470. Debugging Workflow
Once OCD support is proven:
compile target with debug symbols
โ
obtain ELF
โ
connect Nano
โ
identify device
โ
enter debug mode
โ
start Python GDB server
โ
launch avr-gdb
โ
target remote :3333
โ
set breakpoint
โ
continue
โ
inspect state
GDBโs remote-debug architecture is designed specifically for this kind of separation between the full debugger and a small remote target/stub.
471. GDB Server Responsibilities
The PC server handles:
GDB RSP packets
register layout
memory reads/writes
breakpoint policy
ELF awareness
symbol information
software breakpoint journal
target-state management
The Nano handles:
halt
run
step
PC read
SP read
SREG read
register access
hardware breakpoint primitive
UPDI memory access
This is an excellent separation.
472. Keep OCD Knowledge Tagged by Confidence
Because not all low-level OCD details are published as openly as NVM programming details, documentation should tag claims.
Use:
SPECIFIED
for information stated in Microchip documentation.
Use:
REFERENCE-IMPLEMENTED
for behavior found in trustworthy open-source tools.
Use:
OBSERVED
for repeated analyzer captures.
Use:
INFERRED
for experimentally deduced semantics.
Use:
UNKNOWN
where the evidence remains insufficient.
This makes the project much more useful to engineers.
473. The Nano UPDI Sniffer / Analyzer
Our companion analyzer is intended to observe:
raw UPDI traffic
8E2 framing
SYNCH
BREAK
ACK
instructions
memory addresses
NVM sequences
eventually OCD/debugging traffic
The repository address supplied for the project is:
github.com/Monotoba/Nano_UPDI_Sniffer/
At the time I checked this final installment on August 23, 2026, that public URL returned a 404 through public web access. Before publishing the article, verify that the repository is public and that the URL is correct.
That is worth fixing because the analyzer is an especially valuable companion to this article: it lets the reader compare theory, source code, and actual wire traffic.
474. Suggested Analyzer Architecture
The analyzer can decode in stages:
Level 0
electrical transitions
Level 1
8E2 characters
Level 2
BREAK / SYNCH / ACK
Level 3
UPDI instructions
Level 4
address/data interpretation
Level 5
UPDI register names
Level 6
NVM programming operations
Level 7
OCD/debug transactions
Level 8
semantic summaries
For example:
12.000000 BREAK
12.025100 SYNCH 55
12.025300 KEY
NVMPROG
12.027100 ASI_KEY_STATUS
NVMPROG accepted
12.028400 RESET ASSERT
12.029000 RESET RELEASE
12.030100 ASI_SYS_STATUS
PROGSTART = 1
That is dramatically more useful than a plain hex dump.
475. Test Firmware Is Part of the Toolchain
One of the broader lessons of this series is that small test firmware is not โthrowaway code.โ
It is an embedded-development measurement instrument.
When we wonder:
Does this bit really clear on read?
How long does target release take?
Is the address byte order little endian?
Does this baud actually work?
Does BREAK recover the interface?
Is the second breakpoint independent?
write the smallest possible experiment.
Run it repeatedly.
Measure it.
That is often faster than debating an ambiguous paragraph of documentation.
476. The Three Test Front Ends
Our test firmware can be driven through:
Arduino IDE Serial Monitor
Best for:
initial bring-up
manual commands
quick tests
General Serial Terminal
Such as:
picocom
minicom
screen
PuTTY
Tera Term
CoolTerm
Best for:
logging
terminal convenience
repeatable configuration
Python + PySerial
Best for:
automation
repetition
statistics
regression testing
manufacturing
All three belong in a serious embedded-development toolbox.
477. Reliability Qualification
Do not report:
โIt works.โ
Report:
Target: AVR16DU28-I/SP
VDD: 5.03 V
UPDI baud: 225000
UPDI TX: Q4 2N3904 / R8 47 kฮฉ
UPDI RX: Q2 2N3904 / R5 47 kฮฉ
Pull-up assist: R4 DNP
Cable: 10 cm
Transactions: 100000
Success: 100000
Timeout: 0
Parity errors: 0
Frame errors: 0
Bad ACK: 0
That is meaningful.
478. Baud Qualification
Test something like:
31,250
57,600
62,500
115,200
125,000
225,000
and, with more capable hardware, higher rates within the targetโs documented limits.
Microchipโs current serial-UPDI tools expose baud rate as a configurable parameter, and official pymcuprog serial-UPDI support defaults to 115200 while allowing the user to choose another rate.
The right answer is not always:
fastest theoretical baud.
It is:
fastest rate with adequate margin on the actual system.
479. Troubleshooting Philosophy
When something fails, identify the layer.
Do not immediately change random parameters.
Ask:
Power problem?
Electrical-level problem?
Physical UPDI timing problem?
Framing problem?
Instruction problem?
Security state?
NVM problem?
Host protocol problem?
Debugger problem?
Then test that layer directly.
480. Troubleshooting: UPDI Line Is Stuck LOW
Possible causes:
- Q4 being held ON;
- D6 stuck HIGH;
- Q4 installed incorrectly;
- short to ground;
- target actively holding the bus;
- external target circuitry pulling UPDI low;
- Q2/Q4 wiring error;
- UPDI activation in an unexpected state.
Procedure:
- Disconnect the target.
- Verify D6 is LOW when the firmware releases UPDI.
- Verify Q4 base is near its OFF state.
- Confirm Q4 collector is not shorted to ground.
- Reconnect a powered target.
- Observe
UPDI_DATA. - Compare
UPDI_DATAwith D5 through the receive translator.
If Q4 is OFF but UPDI_DATA remains LOW, the pull-down is on the target/external side.
481. Troubleshooting: UPDI Line Is Stuck HIGH
Possible causes:
- D6 not switching HIGH when a LOW should be transmitted;
- wrong Nano pin;
- R8 open;
- Q4 installed incorrectly;
- Q4 damaged;
- Q4 emitter not grounded;
- firmware TX routine never called.
Transmit repeated:
0x55
and scope in this order:
D6 Q4 base Q4 collector / UPDI_DATA
If D6 toggles but Q4 collector never goes LOW, the problem is in the TX transistor stage.
482. Troubleshooting: SYNCH Gets No Response
Check:
- target powered?
- common GND?
- correct UPDI pin?
- measured VTARGET plausible?
- UPDI disabled by fuse?
- target in a strange state?
- BREAK required?
- correct 8E2?
- LSB first?
- even parity correct?
- two stop bits?
- Q4 releasing the line?
- Q2 receiver operating?
- D5 inversion handled correctly?
- optional pull-up really needed at this baud/voltage?
Probe both:
UPDI_DATA D5 / UPDI_RX
so target-side signaling can be distinguished from receiver-stage faults.
483. Troubleshooting: Works at 62.5 kbaud but Not 225 kbaud
This is good diagnostic information.
It suggests:
protocol semantics are probably correct
while:
timing / electrical margin is poor.
Check:
software timing error
interrupt jitter
long wires
breadboard capacitance
slow level shifter
slow transistor release
target pull-up too weak
Q4/Q2 transistor switching delay
optional pull-up DNP when extra rise-time help is needed
rise time
target VDD
This is why slow-mode bring-up is so valuable.
484. Troubleshooting: Parity Errors
Likely causes:
parity calculation wrong
sampling point wrong
bit timing wrong
noise
line contention
incorrect direction turnaround
Test known bytes:
00
01
03
55
AA
FF
and compare calculated parity manually.
485. Troubleshooting: Framing / Stop-Bit Errors
Check:
receiver sample timing
target/programmer baud relationship
interrupt latency
stop-bit implementation
bus released too late
target begins transmission while Nano still drives
A logic analyzer that understands 8E2 is extremely helpful here.
486. Troubleshooting: Device Signature Is Wrong
If you expect:
1E 94 39
and receive stable but wrong bytes, suspect:
wrong SIGROW address
wrong family memory map
address endian error
wrong LDS form
If the bytes change randomly between reads, suspect:
physical communication problem
Stable wrong data and unstable data are very different symptoms.
487. Troubleshooting: Device Identifies but Programming Mode Fails
This is an important narrowing of the problem.
It proves much of UPDI already works.
Now inspect:
NVMPROG key bytes
KEY byte order
ASI_KEY_STATUS
reset request
reset release
PROGSTART
LOCKSTATUS
Current AVRDUDE serial-UPDI code follows exactly this sort of sequence: reset/key handling, key-status inspection, reset toggle, then waiting for NVM programming state.
Compare your sequence.
488. Troubleshooting: NVMPROG Key Rejected
Check:
correct 64-bit key?
correct KEY instruction?
LSB-first payload?
correct target state?
HV activation required?
target locked?
Do not proceed to erase/write commands until the key/status sequence makes sense.
489. Troubleshooting: NVM Busy Never Clears
Possible causes:
wrong NVM backend
wrong command
bad address
target voltage problem
command collision
write-protect condition
Read the NVM status register.
Microchipโs P:4 implementation explicitly checks its error field as well as Flash/EEPROM busy bits rather than waiting blindly.
That is what ours should do.
490. Troubleshooting: Flash Programs but Verify Fails
First determine whether the error pattern is systematic.
Examples:
Every pair swapped
expected:
12 34 56 78
read:
34 12 78 56
Likely:
word endian problem
Every second byte wrong
Likely:
word-write implementation
alignment
First 64 bytes right, then wrong
Likely:
host block/chunk boundary
Failure at 0x0200
Likely:
512-byte page boundary bug
Random isolated failures
Likely:
signal integrity
timing
supply
Pattern recognition matters.
491. Troubleshooting: Flash Address Appears Offset by 0x8000
Remember:
Flash image address
and:
UPDI data-space Flash mapping
can be different representations.
For our AVR DU examples, Flash is mapped into the data space beginning at the appropriate mapped region.
Use named conversion functions.
Do not let:
HEX address
UPDI address
GDB address
instruction word address
collapse into one untyped integer.
492. Troubleshooting: EEPROM Gets Erased Unexpectedly
Check:
chip-erase behavior
EESAVE fuse
host assumptions
Microchipโs programming software explicitly warns that a chip erase does not necessarily erase every memory and that EEPROM may be preserved when EESAVE is set.
Therefore:
chip erase
must not be treated as:
set every nonvolatile byte to FF.
493. Troubleshooting: HV Pulse Is Correct but Recovery Fails
Measure at the actual MCU pin.
Then check:
target VDD
HV threshold
pulse timing
POR state
key timing
correct HV destination pin
target device profile
RESET loading
target security state
Microchip notes that the actual HV threshold depends on VDD, and that a valid key must arrive within the documented timeout.
494. Troubleshooting: RESET-HV Never Reaches the Required Voltage
Possible causes:
- large RESET capacitor;
- external reset supervisor;
- strong pull-down;
- J4 on the wrong route;
- Q1 installed incorrectly;
- Q3 not pulling Q1 base low enough;
- wrong R3/R7 values;
- bench current limit too low;
- excessive load after R6;
- wrong common ground.
Measure in this order:
external HV input Q1 emitter Q1 base Q1 collector after R6 J4 selected output target RESET
If the source rail is correct but the target pin is low, the voltage is being lost in the switching/load path.
495. Troubleshooting: HV Works Once but Not After Reset
This may be completely consistent with the targetโs override behavior.
Some HV overrides persist until:
Power-on Reset
rather than an ordinary reset.
Microchip documents cases where only POR restores the fuse-defined pin function after an HV override.
Distinguish:
CPU reset
UPDI reset
power cycle
in both firmware and documentation.
496. Troubleshooting: 12 V Recovery Damages Other Circuitry
That is exactly why 12 V shared-pin recovery must be designed into the target.
Anything attached to the shared node must either:
tolerate the voltage
or:
be disconnected
during recovery.
The same principle applies to RESET-HV on newer devices. Microchip explicitly warns that circuitry attached to RESET can be damaged and recommends provision for disconnection when necessary.
497. Troubleshooting: GDB Connects but Register Values Are Nonsense
Suspect:
wrong GDB register packet layout
wrong byte order
wrong OCD generation
register index mismatch
PC address-unit mismatch
Compare one register at a time against:
known assembly
known test firmware
known-good debugger
Do not debug the entire register block at once.
498. Troubleshooting: Breakpoint Address Is Doubled or Halved
This is almost certainly an address-unit issue.
You may be confusing:
byte address
with:
word address
For AVR code:
byte address 0x0200
can correspond to:
word address 0x0100
depending on the interface.
Centralize conversion.
499. Troubleshooting: Single-Step Jumps โToo Farโ
Possible causes:
instruction is multiword
interrupt occurred
GDB source-level step performed multiple machine operations
PC unit incorrectly interpreted
temporary breakpoint involved
Compare:
PC before
machine disassembly
PC after
rather than relying only on source-line movement.
500. Troubleshooting: Software Breakpoint Corrupts Flash
Check:
page preservation
original instruction size
instruction alignment
BREAK opcode
erase granularity
word endian
stale breakpoint journal
firmware digest
Software breakpoint support should come after ordinary Flash programming is proven.
Reuse the same tested NVM routines.
501. Troubleshooting: Debugger Stops but Application Restarts
You may be resetting rather than halting.
Test using a persistent SRAM counter:
counter increments continuously
Halt.
Read it.
Resume.
Halt again.
If it returns to its startup value:
debug stop path is causing reset
which is not equivalent to OCD halt.
502. Troubleshooting: Analyzer Changes the Behavior
That means the analyzer is not sufficiently passive.
Possible causes:
input capacitance
pull-up enabled accidentally
GPIO configured as output
level shifter loading
long probe lead
A protocol sniffer should ideally be:
high impedance
receive only
unless deliberately participating.
503. A Full Test Matrix
A serious project should test at least:
| AreaTest | |
| Physical | Q4 default OFF / line released |
| Physical | Q2 receive inversion |
| Physical | Idle HIGH |
| Physical | BREAK duration |
| TX | D6-to-UPDI known 8E2 patterns |
| RX | UPDI-to-D5 known 8E2 patterns |
| Link | 1000 LDCS reads |
| Link | Double-BREAK recovery |
| Identity | Signature |
| Identity | SIB |
| Memory | SRAM R/W |
| Flash | Erase |
| Flash | Program |
| Flash | Verify |
| EEPROM | R/W/restore |
| Fuses | Read/decode |
| HV | Voltage |
| HV | Pulse width |
| HV | Interlock |
| HV | 1000 pulse test |
| HV | Actual recovery |
| Debug | Halt |
| Debug | Run |
| Debug | Step |
| Debug | PC/SP/SREG |
| Debug | Hardware BP 1 |
| Debug | Hardware BP 2 |
| GDB | Memory read |
| GDB | Registers |
| GDB | Continue |
| GDB | Breakpoints |
This makes the project testable rather than anecdotal.
504. Git Workflow
Use Git from the beginning.
A useful history might contain:
Initialize Nano UPDI project
Implement 8E2 transmitter
Implement 8E2 receiver
Add BREAK and SYNCH
Implement LDCS/STCS
Implement direct memory access
Add device identification
Implement AVR DU P4 NVM backend
Add Flash erase/write/verify
Add EEPROM support
Add fuse decoder
Add D6/D5 transistor UPDI interface
Add VTARGET and HV sensing
Add D4 target-reset control
Add Q1/Q3 RESET-HV switching
Add J4 HV route/arm interlock
Add optional D8 target-power control
Qualify AVR16DU28 HV activation
Add debug backend
Implement halt/run
Implement step
Add hardware breakpoints
Add Python GDB server
Small commits make regressions traceable.
505. Recommended Tags
Important milestones can be tagged:
v0.1-updi-link
v0.2-memory-access
v0.3-programmer
v0.4-hv-recovery
v0.5-debug-primitives
v0.6-gdb
v1.0
If debugging suddenly breaks after an HV refactor:
git bisect
can be more useful than hours of speculation.
506. Tests Should Accompany Every Code Change
Firmware changes should have tests where practical.
Host changes should definitely have automated tests.
Examples:
parity
endian conversion
instruction encoding
device lookup
memory geometry
HEX checksum
page assembly
block splitting
verification mismatch
fuse masks
HV-profile selection
GDB packet checksums
breakpoint bookkeeping
Hardware-in-the-loop tests can be run separately.
507. A Project Release Should Include Known-Good Captures
An especially useful release artifact would include captures such as:
ordinary-connect
signature-read
enter-programming
flash-page-erase
flash-write
chip-erase
reset-HV activation
halt
step
hardware-breakpoint
Then future contributors can compare new firmware against known behavior.
508. Resource: Microchip AVR16DU28
The AVR16DU28 product page should be the primary source for the current device data sheet and device-specific documentation.
Microchip AVR16DU28 product page
Always prefer the latest PDF linked from the product page when checking:
absolute maximum ratings
HV levels
fuse definitions
NVM behavior
memory map
timing
because online extracts and old locally saved PDFs can become stale.
509. Resource: Microchip AVR16DD28
For our comparison target:
Microchip AVR16DD28 product page
The DD family is important because it demonstrates that UPDI transport compatibility does not imply identical NVM or memory-layout behavior.
510. Resource: Microchip UPDI Documentation
Microchipโs current UPDI documentation is the primary source for:
one-wire physical interface
UPDI configurations
HV classes
RESET-HV requirements
The current summary explicitly distinguishes the older 12 V shared-pin architecture from newer RESET-HV devices.
It should be considered authoritative over random forum posts claiming that:
โall UPDI is 12 Vโ
or:
โUPDI never needs HV.โ
Both statements are overgeneralizations.
511. Resource: Microchip pymcuprog
Microchipโs open-source pymcuprog project is one of the best implementation references for modern UPDI programming.
It supports serial-UPDI operation through a UART-style adapter and exposes program, erase, verify, high-voltage modes, and device/tool support.
Microchip pymcuprog repository
The AVR DU P:4 backend is particularly valuable to this project.
pymcuprog NVM P:4 implementation
512. Resource: AVRDUDE SerialUPDI
Modern AVRDUDE contains a native SerialUPDI implementation derived in part from the same ecosystem.
Its source provides useful examples of:
link initialization
SIB decoding
NVM-version selection
NVMPROG entry
reset sequencing
locked-device handling
USERROW access
This is an excellent independent implementation to compare against Microchipโs tool.
513. Resource: pyupdi
The original pyupdi project is historically important because it demonstrated direct UPDI programming from an ordinary UART adapter.
Its repository now explicitly says it is deprecated and recommends the SerialUPDI implementation incorporated into pymcuprog.
It remains useful educationally, but new software should generally study current maintained implementations first.
514. Resource: jtag2updi
jtag2updi demonstrated that an ATmega328P-class Arduino can successfully bridge host programmer protocols to UPDI.
It is historically important to our Nano implementation.
However, modern device families and NVM generations have continued to evolve, so it should be treated as:
valuable reference
rather than:
complete specification of every present AVR.
Modern community cores increasingly prefer SerialUPDI/pymcuprog-style approaches for programming newer parts. For example, megaTinyCoreโs current documentation recommends SerialUPDI over its older jtag2updi path.
515. Resource: Arduino Tooling
Arduino IDE remains our assumed source-development environment.
For automation and debugging integration, Arduino CLI is also important because it exposes build and debug-oriented commands programmatically.
The final toolchain can therefore use:
Arduino IDE:
editing
Arduino CLI:
reproducible builds
our Python host:
UPDI programming/debugging
avr-gdb:
source-level debugging
This is often a better architecture than asking the Arduino IDE itself to perform every development function.
516. Resource: GNU GDB
The GDB Remote Serial Protocol is the bridge between a full symbolic debugger and a small remote target or stub.
GDBโs documentation explicitly describes this model for debugging small systems that do not themselves run a full debugger.
This is exactly our situation.
The AVR target does not know about:
C++
Arduino sketches
source lines
symbols
It knows:
addresses
registers
machine instructions
memory
GDB adds the source-level interpretation.
517. Resource: Existing UPDI Debugging Work
Open-source UPDI debugging work is especially valuable because low-level OCD details are not published as completely as normal UPDI programming.
When studying these projects:
compare claims with Microchip documentation
capture actual transactions
label inferred behavior
test across target generations
Do not elevate community findings automatically to guaranteed silicon interfaces.
They are often excellentโbut their confidence category differs from a documented electrical limit in the data sheet.
518. Resource: Nano UPDI Sniffer / Analyzer
Companion project address supplied for this article:
github.com/Monotoba/Nano_UPDI_Sniffer/
The intended project includes:
firmware
host software
hardware/wiring documentation
schematics/diagrams
PCB
and should become the articleโs practical protocol-analysis companion.
As noted earlier, the public URL returned 404 when checked on August 23, 2026. Verify/publicize the repository before the article is published.
519. Resource Hierarchy
When sources disagree, use this rough hierarchy:
1. Current target PDF data sheet
2. Current Microchip programming/debug documentation
3. Current Microchip reference implementation
4. Mature independently maintained implementation
5. Repeatable analyzer measurements
6. Community documentation
7. Forum/blog claims
A forum answer can be correct.
A data sheet can contain errata.
No single source is infallible.
But not all sources have equal evidentiary weight.
520. Read the Errata
For any target used seriously, check:
data sheet
errata
silicon revision
tool notes
If an operation behaves differently from the data sheet, it may be:
our bug
or:
a documented silicon issue.
Do not assume the former without checking the latter.
521. Keep Device Facts Separate from Protocol Facts
This is perhaps the most important documentation rule for the whole project.
Protocol fact
UPDI uses one-wire half-duplex asynchronous communication.
Device fact
AVR16DU28 uses a particular NVM generation.
Tool implementation fact
our Nano starts at 62.5 kbaud during development.
These should never be written as though they are the same kind of statement.
522. Keep Recommended Values Separate from Specifications
Likewise:
Microchip minimum HV pulse = specification
while:
we use 100 ยตs = implementation recommendation
and:
bench supply current limit 10โ20 mA = cautious lab practice
are different categories.
A technical article should tell the reader which is which.
523. Do Not Confuse โWorksโ with โWithin Specificationโ
A circuit may work at:
5 V Nano
3.3 V target
4.7 kฮฉ
for years on one bench.
That does not prove it obeys the targetโs specified input-voltage limits.
Likewise, a UPDI rate above the documented maximum might function on a cool sample.
That does not make it a robust design.
Engineering asks both:
Did it work?
and:
Was it within specified limits?
524. Final Recommended Build Path
For someone following this article from scratch, the safest sequence is still incremental even though the final schematic contains all of the hardware.
Phase 1 โ Build and verify the Nano core
Confirm:
Nano powers correctly serial console works safety-critical outputs default OFF
Phase 2 โ Build the Q4/Q2 UPDI interface
Implement and test:
D6 TX D5 RX 8E2 BREAK SYNCH LDCS status signature
Use the final transistor interface from the beginning rather than reverting to the old one-resistor circuit unless the latter is being used strictly as a teaching experiment.
Phase 3 โ Add memory access
Implement:
SIB memory read SRAM write
Phase 4 โ Add NVM programming
Implement:
NVMPROG Flash erase Flash write verify EEPROM fuses USERROW
Phase 5 โ Add the Python host
Implement:
Intel HEX backup verify device database
Phase 6 โ Calibrate A0/A1 sensing
Verify:
VTARGET HV input
against a DMM.
Phase 7 โ Commission D4/D7/D8 support hardware
Verify:
target RESET HV switching J4 route/arm optional target power
before attaching a device for HV recovery.
Phase 8 โ Develop OCD primitives
Implement:
halt run step PC/SP/SREG hardware breakpoint
Phase 9 โ Add GDB server
Phase 10 โ Integrate into Arduino IDE or other IDEs
This order keeps the finalized hardware architecture while still minimizing simultaneous unknowns.
525. What Not to Do
Avoid the following development sequence:
design universal multi-voltage hardware
add 12 V HV
add RESET-HV
implement all NVM generations
implement GDB
implement GUI
then try first UPDI byte
That creates too many failure dimensions.
Begin with the smallest known-good experiment.
Then expand.
526. What We Have Learned About UPDI Electrically
UPDI is fundamentally:
single wire
bidirectional
half duplex
asynchronous
with UART-like framing.
That simplicity makes tiny connectors possible.
But it also means:
bus ownership matters
turnaround matters
voltage domains matter
rise time matters
contention matters
The one-wire interface reduces pins.
It does not eliminate electrical engineering.
527. What We Have Learned About the Protocol
The core instruction vocabulary is compact:
LDS
STS
LD
ST
LDCS
STCS
REPEAT
KEY
Yet that small set provides access to:
UPDI control state
memory
peripherals
NVMCTRL
protected modes
The targetโs memory-mapped architecture does much of the heavy lifting.
UPDI does not need hundreds of commands because the AVR already represents so much of itself through addresses.
528. What We Have Learned About Programming
Programming is not:
UPDI write byte to Flash
in the simplistic sense.
It is:
UPDI
โ
target address space
โ
NVM controller
โ
target-generation-specific command
โ
Flash/EEPROM/fuse operation
That is why modern AVRDUDE and Microchipโs own software parse NVM-generation information and select different implementations.
529. What We Have Learned About High Voltage
โ12 V UPDIโ is incomplete terminology.
The correct question is:
Which UPDI physical arrangement does this target implement?
Older shared pin:
approximately 12 V on shared UPDI/RESET/GPIO
Dedicated UPDI:
no HV required for UPDI availability
Newer UPDI/GPIO with separate RESET:
HV on RESET
approximately VDD + 2 V
Microchipโs documentation explicitly makes these distinctions.
530. What We Have Learned About Debugging
The target MCU does not understand:
breakpoint on line 42
It understands:
stop execution at machine address X
The host debugger translates between:
source language
and:
machine state.
UPDI/OCD merely gives us access to the machine state and control mechanisms.
That separation is why:
Nano + Python + GDB
is such a natural architecture.
531. Why This Is Such a Good Hobbyist Protocol to Study
UPDI sits in a particularly interesting middle ground.
It is sophisticated enough to expose:
programming
security
memory access
debugging
high-voltage recovery
but simple enough electrically that a hobbyist can observe it with:
Arduino Nano
breadboard
oscilloscope
logic analyzer
Python
That is unusual.
It makes UPDI a very good protocol for learning how professional development tools actually work.
532. The Programmer Becomes a General AVR Laboratory Tool
Once complete, our project is no longer merely:
an AVR programmer.
It can become:
programmer
debugger
UPDI analyzer
NVM explorer
fuse inspector
memory viewer
HV recovery tool
target power controller
voltage monitor
protocol research platform
all built around a remarkably inexpensive core.
533. A Possible Final Hardware Front Panel
A permanent enclosure for the reference tool might expose:
USB
TARGET connector:
1 TARGET_RESET
2 VTARGET
3 UPDI_DATA
4 GND
HV INPUT
HV route/arm selector
optional target-power connector
status LEDs:
PWR
ACT
VTAR
ERR
test points:
UPDI_DATA
TARGET_RESET
VTARGET
HV input/switched HV
GND
The more potentially destructive a function is, the more obvious it should be physically.
534. Useful Status LEDs
PWR
The programmer itself is powered.
ACT
Host/UPDI activity is occurring.
VTAR
A target voltage has been sensed and judged acceptable for the selected operating profile.
ERR
A persistent error or unsafe condition has occurred.
The LEDs should never be the only diagnostic interface.
The serial/host application should still report the exact error state and measured voltages.
535. Future Upgrade: Replace the Nano
A later hardware revision could move to a newer AVR or another MCU with:
native USB
larger RAM
modern USART one-wire mode
open-drain output
faster timers
better ADC
while preserving:
host protocol
device database
NVM architecture
GDB server
tests
because we kept the Nano physical layer isolated from those components.
This is one of the biggest benefits of layering.
536. Future Upgrade: Automatic HV Supply
Our current design assumes an external bench supply.
A self-contained version could add:
boost converter
programmable regulator
feedback divider
HV ADC sensing
automatic discharge
Then the host could request:
Target profile requires RESET-HV
Generate 7.5 V
and the programmer could verify the voltage before applying it.
That is an excellent later enhancement.
It should not be part of the first learning build.
537. Future Upgrade: Electronic Target Power Switching
The current reference hardware already reserves:
D8 = TARGET_POWER_ENABLE
and includes an optional relay-controlled target-power stage.
That is sufficient for:
- automated power cycling;
- POR sequencing;
- HV recovery experiments;
- fixture control.
A future PCB could replace the relay with a fully electronic high-side load switch or MOSFET stage to add:
- faster switching;
- lower power consumption;
- silent operation;
- current limiting;
- programmable soft start;
- integrated current sensing.
The firmware and host API need not change if the hardware abstraction remains clean.
538. Future Upgrade: Current Measurement
If the programmer eventually supplies target power, adding current sensing gives:
Target VDD: 5.00 V
Target current: 18.4 mA
and allows automated detection of:
short circuit
unpowered target
unexpected consumption
That moves the tool toward a small production fixture.
539. Future Upgrade: Production Test Protocol
After programming, the host might:
reset target
wait for self-test
read UART response
exercise GPIO
check current
record serial number
and log:
PASS
or:
FAIL
with diagnostics.
UPDI then becomes only one subsystem of a manufacturing test station.
540. Final Software Command Layers
The complete tool might expose three user levels.
Beginner
info
program firmware.hex
verify firmware.hex
backup
restore
Advanced
read-memory
fuses
eeprom
userrow
hv-enter
Engineering
raw-ldcs
raw-stcs
raw-lds
raw-sts
key
nvm-command
debug-register
trace
This prevents ordinary users from needing to understand every low-level primitive while preserving full engineering access.
541. The Documentation Should Mirror These Layers
User manual:
How do I program my AVR?
Engineering manual:
How does NVM P:4 programming work?
Tester manual:
How do I qualify UPDI at each baud?
Protocol reference:
What does this byte sequence mean?
Hardware guide:
How is RESET-HV switched?
Research notes:
What do we know about OCD register X?
One enormous README should not try to serve every audience.
542. Final Safety Rules
Before concluding, these deserve a compact permanent list.
- Never assume all UPDI targets use 12 V HV.
- Never apply HV until the exact target family has been identified.
- Never rely on the old single-series-resistor teaching interface as a universal level translator.
- Never apply HV directly to a Nano GPIO.
- Never let HV default ON during reset.
- Never write a fuse without reading and decoding it first.
- Never assume chip erase erases every NVM region.
- Never use undocumented OCD behavior without labeling its confidence.
- Never trust a programming operation without readback verification.
- Never debug hardware by changing five variables simultaneously.
Those ten rules will prevent a remarkable number of problems.
543. Final Engineering Rules
And ten more positive ones:
- Identify the target first.
- Read before writing.
- Use volatile memory tests before NVM tests.
- Start slow, then qualify higher baud rates.
- Use timeouts everywhere.
- Log exact error states.
- Use a scope/analyzer early.
- Automate repetitive tests with Python.
- Keep device-specific behavior in data/backends.
- Commit each known-good milestone to Git.
These are not UPDI-specific habits.
They are good embedded engineering habits.
544. Final Perspective
At first glance UPDI seems almost implausibly simple.
One wire.
No clock.
No separate transmit and receive lines.
No six-wire ISP connection.
No four-signal JTAG TAP.
Yet behind that one signal lies enough machinery to:
identify a microcontroller
inspect its memories
erase it
program Flash
write EEPROM
configure fuses
recover certain disabled interfaces
control reset
halt execution
single-step code
inspect CPU state
set breakpoints
support symbolic debugging
That simplicity is not an accident.
Microchip moved complexity away from the external connector and into the microcontroller.
The programmer therefore needs very little physical access:
UPDI_DATA GND VTARGET
and for the complete reference connector:
TARGET_RESET VTARGET UPDI_DATA GND
RESET is available for ordinary target control and for modern RESET-HV recovery where the selected device requires it.
The same tiny connection that loads the first firmware image can later diagnose why that firmware crashed.
That is the real meaning of:
Unified Program and Debug Interface.
545. And Then Some
We set out to answer:
What is UPDI?
But answering it properly required us to learn about:
UART framing
half-duplex buses
parity
autobaud
break recovery
memory mapping
endianness
Flash architecture
NVM controllers
protected keys
fuse safety
high-side transistor switching
BJTs
voltage dividers
ADC protection
high-voltage activation
security states
embedded testing
protocol analyzers
Python automation
Intel HEX
ELF
DWARF
breakpoints
GDB
reverse engineering
hardware-in-the-loop testing
Git
That may seem like a very long journey from one wire.
It is.
And that is exactly why UPDI is such a good subject.
Understanding a technology deeply almost always means eventually understanding the systems around it.
546. The Entire Stack in One Diagram
We can finally draw the whole thing:
USER / ENGINEER
|
v
+--------------------------+
| Arduino IDE / CLI |
| Python Host / GDB |
+-------------+------------+
|
| USB Serial
v
+--------------------------+
| Arduino Nano |
| |
| Host Protocol |
| Programmer State |
| Debug Primitives |
| NVM Backend |
| Device Database |
| UPDI Instruction Layer |
| UPDI Link Layer |
| UPDI Physical Layer |
| |
| D6 = UPDI_TX |
| D5 = UPDI_RX |
| D4 = TARGET_RESET_CTRL |
| D7 = HV_ENABLE |
| D8 = TARGET_POWER_ENABLE |
| A0 = VTARGET_SENSE |
| A1 = HV_SENSE |
+-------------+------------+
|
+-------+-------+
| Q4/Q2 UPDI |
| translator |
+-------+-------+
|
| one-wire UPDI_DATA
|
v
+--------------------------+
| Target AVR |
| |
| UPDI PHY |
| UPDI Data Link |
| ASI / System Access |
| |
| +---------+ +---------+ |
| | NVMCTRL | | OCD | |
| +----+----+ +----+----+ |
| | | |
| v v |
| Flash/EEPROM CPU |
| Fuses/Userrow Registers |
+--------------------------+
Additional hardware:
TARGET_RESET
^
|
Q6 transistor driver
^
|
Nano D4
External HV
|
Q1/Q3 high-side switch
|
R6 680 ฮฉ
|
J4 route/arm
/ \
/ \
HV_OUT TARGET_RESET
VTARGET ---- protected divider ----> A0
HV input --- protected divider ----> A1
D8 ----> optional Q5 / relay target-power control
Measurement and analysis:
oscilloscope
logic analyzer
Nano UPDI Sniffer / Analyzer
There is the whole project.
One UPDI data conductor at the center.
Many useful systems built around it.
547. Closing Comments
If you merely need to program a modern AVR, you do not need to build any of this.
Buy a supported programmer.
Use Microchipโs tools.
Use AVRDUDE.
Use pymcuprog.
Use SerialUPDI.
Those are perfectly good answers.
But if your goal is to understand how the interface worksโand how a programmer itself worksโthen building one changes UPDI from a black box into an understandable engineering system.
You stop seeing:
Upload
as a magic button.
You begin seeing:
identify
KEY
reset
enter NVM mode
erase
write
poll
read
compare
reset
You stop seeing:
Breakpoint
as an IDE feature.
You begin seeing:
ELF source mapping
โ machine address
โ breakpoint request
โ OCD comparator
โ CPU halt
โ PC read
โ GDB stop packet
โ source line
And you stop seeing the single UPDI wire as something mysterious.
It becomes exactly what it is:
a carefully engineered communication path into the internal machinery of a modern AVR.
That is all you ever needed to know about UPDI.
And then some.