For an XC7Z020-2CLG400C board that will not start, corrupts memory or stalls at a PL register access, first identify the last stage that demonstrably worked. The steps below are diagnostic hypotheses and checks, not reports of a measured failure on your board.
Record a reproducible failure before changing the design
- Board revision and full device marking, power source, boot medium and strap settings.
- Hardware export, bitstream, FSBL and application build identifiers; tool versions and debugger messages.
- Cold-start versus reset behavior, the last UART/debug message and whether the failure follows a load or temperature change.
- Expected versus measured rails, reset and clock; instrument setup and probe location.
1. No JTAG device or unreliable identification
- Check the board is powered correctly and the debug connector has the expected ground and target-reference voltage. Inspect orientation, cable continuity and chain wiring against the schematic.
- Measure the relevant supplies, PS_POR_B behavior and PS reference clock. Compare startup and shutdown with DS187; do not infer a valid sequence from steady-state voltages.
- Verify the board’s boot/JTAG chain configuration and the permitted debug state. Secure-boot or lockdown behavior can affect access; JTAG is not unconditionally available.
- Try a conservative cable clock supported by your setup and record whether detection becomes repeatable. A successful lower rate is evidence to investigate signal quality or timing, not proof that a particular resistor is wrong.
- Separate cable/host-driver problems from target problems by checking known-good equipment where available. Do not alter boot-security fuses as a trial-and-error recovery step.
For -2 operation, use DS187 rather than the DS191 specification for other Zynq-7000 devices. DS187 also constrains PS_POR_B release relative to the PL supply ramp. A reset circuit that merely waits for a nominal delay may miss that requirement.
Manufacturer references: DS187: Z-7020 electrical and switching specifications, Tables 2, 17 and power/reset requirements; UG585: Zynq-7000 Technical Reference Manual.
2. JTAG connects, but no boot output appears
A detected scan chain proves much less than a functioning boot path. Establish whether code reaches BootROM handoff, the FSBL, the next loader or the application. In normal memory boot, BootROM loads the FSBL into OCM; the FSBL then performs board-specific PS initialization and loads later components. JTAG boot uses a different debugger-controlled flow.
| Check | Interpretation and next action |
|---|---|
| UART instance, pins, voltage and terminal settings | No text can mean the console is routed elsewhere. Confirm the software console configuration against the schematic before diagnosing a dead CPU. |
| Boot straps sampled at reset | Compare the actual MIO strap functions and levels with UG585. Check that connected peripherals do not override the strap state. |
| Boot medium and image | Verify image generation, placement and supported device mode. Read back the programmed image and compare it with the intended file. |
| Consistent hardware/software exports | Rebuild FSBL and software from the correct hardware definition after changing clocks, DDR or peripherals. A stale initialization file can produce a valid-looking but incorrect boot image. |
| FSBL diagnostic output or debugger location | Use the observed stage to narrow the failing dependency. Preserve the error code; a hang near DDR initialization is not, by itself, proof of a routing fault. |
Manufacturer references: UG1283: Zynq-7000 boot and configuration; UG821: first-stage bootloader responsibilities.
3. Memory test fails or software crashes under load
- Verify the installed DDR part, geometry, bus width, controller settings and clock against the actual board. Recheck any copied evaluation-board preset.
- Run an appropriate memory diagnostic on a reserved region that excludes the program, stack, heap and active DMA buffers. Record addresses and patterns that fail. A test overwriting its own execution area is not a valid DDR diagnosis.
- Compare failures across addresses, data patterns, cold starts and the intended operating range. Separate reproducible bit/lane failures from failures caused only by concurrent software or DMA.
- Review supply/reference voltages, termination and routing constraints using UG933 and the memory vendor’s documents. Probe with a suitable technique; excessive probe loading can change the interface.
- If a reduced, supported memory rate changes the symptom, retain that observation as a clue. It does not certify the production-rate design or distinguish signal integrity from configuration on its own.
- For failures limited to DMA, inspect buffer ownership, transfer bounds, cache maintenance and driver use before blaming the memory traces.
Do not assign a percentage of failures to PCB layout without a measured dataset. A memory problem can come from configuration, power, timing, software or several of these together.
Manufacturer references: UG933: Zynq-7000 PCB Design Guide; UG585: Zynq-7000 Technical Reference Manual.
4. A PL register access hangs or returns unexpected data
- Confirm the expected bitstream is configured and the peripheral exists at the address used by software. Check the address map against the hardware export.
- Check the AXI clock is running and the peripheral/interconnect resets are released in the intended sequence. Verify crossings between unrelated clocks are handled correctly.
- Start with a small, known register transaction before enabling bursts, interrupts or DMA. Confirm access width, alignment and register side effects.
- Use an ILA or other suitable instrument to observe the address, valid/ready and response channels. Capture the stalled transaction and the relevant reset/clock signals together.
- Compare the hardware observation with the driver operation. A missing response, a decode error and a stale cached read require different fixes. Do not repeatedly write undocumented registers.
5. DMA completes but the application sees stale data
Define who owns each buffer before and after a transfer. Check allocation, alignment, length, completion handling and whether the driver uses the platform’s DMA/cache APIs correctly. A normal HP-port transfer does not automatically make CPU caches coherent; selecting ACP also requires correct transaction and system configuration. Do not use “disable all caches” as a production fix without understanding the design.
Create a small test with identifiable input patterns and a checked output length. Log descriptor state, completion/error status and data at each ownership transition. Increase traffic only after the simple transfer is repeatable. Separately test interrupt acknowledgment and recovery from an aborted transfer.
Manufacturer references: UG585: Zynq-7000 Technical Reference Manual.
Close the issue with a regression test
Change one cause at a time and repeat the original reproducer. Record the corrected schematic or software revision, measurements before and after, and the operating conditions tested. Then repeat cold boot, memory, peripheral and application tests together. A single successful restart is not evidence that an intermittent fault is resolved.
For a sourcing or replacement request, provide the complete part suffix and the relevant evidence. A different speed or temperature grade is not a substitute for diagnosing a board fault; engineering must approve any part change.
Continue your design review
- Device specifications and ordering checks
- Board design-in and bring-up checklist
- Three-axis motion-control planning
- Machine-vision bandwidth planning
For a sourcing request, include XC7Z020-2CLG400C, quantity, required delivery date and any lot or documentation requirements. Request a quotation. Availability, price, delivery and other commercial terms are confirmed in each written quotation.
Technical content reviewed against the linked manufacturer documents on 8 October 2026. Application calculations are planning examples, not measurements from a tested WWDParts board.