Private embedded register-map preflight

CMSIS-SVD Register Map Inspector & Overlap Audit

Turn a CMSIS System View Description into a readable peripheral and register map before using it in a debugger or header generator. Resolve common inheritance and arrays, calculate absolute addresses, and expose register, field, reset, address-block, enumeration, and interrupt conflicts without uploading device files.

Local XML source

Open or paste a CMSIS-SVD file

No local file selected.

Input is limited to 5 MiB, 100,000 XML elements, 10,000 expanded peripherals, 100,000 expanded registers, and 500,000 expanded fields. DTDs and external entities are rejected.

Choose a CMSIS-SVD file, paste XML, or load the teaching sample.

Device names, addresses, register descriptions, and XML stay in this browser tab. Nothing is uploaded, fetched, generated, or connected to hardware.

What this CMSIS-SVD inspector resolves

The page reads device-level register defaults, peripheral base addresses, address blocks, interrupts, nested clusters, register fields, and enumerated values. It expands bounded peripheral, cluster, register, and field arrays, applies common peripheral and register derivedFrom inheritance, and calculates absolute byte addresses plus effective field bit ranges.

Overlap and range checks

Expanded registers are checked against register address blocks and against their neighbors using the inherited register width. Explicit alternateRegister aliases are distinguished from accidental collisions. Fields are checked for valid range syntax, fit, and overlap; enumerated values and reset values or masks are checked against their effective widths. Peripheral address-block and interrupt-number collisions remain visible.

Validation boundary

This is a readable preflight, not the CMSIS schema validator. It does not apply the complete XSD, reproduce every SVDConv diagnostic, generate C headers, connect to a target, prove hardware accuracy, evaluate debugger expressions, or fully expand inherited cluster children. Vendor extensions and unfamiliar elements remain outside its semantic checks. Validate release files with the current official schema and SVDConv, then compare important addresses with the silicon reference manual.

Frequently asked questions

Why are there more peripherals or registers than XML templates?

dim, dimIncrement, and dimIndex describe arrays. The inspector expands them so each effective address can be reviewed independently.

Why can two registers share an address?

Some devices intentionally provide alternate views of the same storage. An explicit alternateRegister relationship suppresses the accidental-overlap error; unrelated overlaps remain findings.

Does a clean result prove the SVD matches the chip?

No. A structurally coherent description can still contain the wrong addresses, reset values, access modes, or prose. The reference manual and hardware remain authoritative.

Authoritative references

The hierarchy and inheritance model follow the Open-CMSIS-SVD format specification, including the official peripheral and register and field definitions. Use the official SVDConv utility for full validation and header generation.

Analyze a linker map · Compare firmware memory maps · Browse electronics tools