Requesting help debugging the PCIe root port example on another board than the devkit

The CPU-freeze symptom on an HPS2FPGA/LWHPS2FPGA access is almost always a stalled AXI transaction — the HPS issues the access and waits indefinitely for a response. The most common causes in a ported design are below.
1. Bridge clock not running in the FPGA fabric (most likely culprit)
The H2F bridge accepts its clock from the FPGA fabric via hps2fpga_axi_clock. HPS-to-FPGA Bridge Similarly, the LWH2F initiator interface operates in the lwhps2fpga_axi_clock clock domain, which is provided by custom logic in the FPGA fabric. Lightweight HPS-to-FPGA Bridge Clocks and Resets If the PCIe example design derives these clocks from a PLL that itself depends on the PCIe reference clock or some other source that isn't yet stable when Linux first touches the bridge, the bridge will never complete the AXI handshake and the CPU stalls. Use Signal Tap to verify both hps2fpga_axi_clock and lwhps2fpga_axi_clock are actively toggling at the moment you attempt the access — not just that PLLs are locked in a "steady state" test.
2. Reset not wired correctly
The h2f_reset signal must be connected to hps2fpga_axi_reset for proper bridge operation. HPS to FPGA Manager Similarly, h2f_reset must be connected to lwhps2fpga_axi_reset for the LWH2F bridge. Lightweight HPS to FPGA Manager In a ported design this connection is easy to accidentally break if you regenerated the Platform Designer system. Confirm both are wired in your .qsys / Platform Designer view.
3. Bridge not enabled from the HPS software side
The bridges must be explicitly enabled in software. From Linux, read back the bridge manager enable register to confirm the H2F and LWH2F bridges are actually released. A quick sanity check is to confirm with devmem2 that the enable bits are set before the offending access. For full FPGA configuration the documented procedure is to disable and then re-enable the bridge before and after sending the bitstream. Table 2. Configuration versus Partial Configuration — SDM EL3 EL3 HPS EL2 If your u-boot or boot script does not re-enable them after FPGA configuration, the bridges remain gated.
4. No connected subordinate in the FPGA fabric
If the HPS2FPGA or LWHPS2FPGA AXI port in your Platform Designer system is exported (not connected to any subordinate IP), the transaction will hang waiting for a response. Confirm the bridge output is connected to at least one subordinate (even just an on-chip memory or a loopback) in the design you compiled for the Comet board.
5. Address range
The LWHPS2FPGA window base address is 0x00_2000_0000, size 512 MB. 10. Address Map > 10.2. Total Address Spaces > 10.2.2. Total Address Map Tabular > Table 311. Tabular Total System Address Maps Example — Hard Processor System Technical Reference Manual The HPS2FPGA window base address is 0x00_4000_0000, size 1 GB. 10. Address Map > 10.2. Total Address Spaces > 10.2.2. Total Address Map Tabular > Table 311. Tabular Total System Address Maps Example — Hard Processor System Technical Reference Manual Confirm your Linux devmem or driver access targets these ranges, not some other address.
6. NOC privilege enforcement
The LWHPS2FPGA target socket has a default privilege level of Privileged, enforced by the NOC, and the setting is programmable. 13. System Interconnect and Firewalls > 13.4. System Interconnect and Firewalls Functional Description > 13.4.3. Transaction Privilege > Table 373. Target Privilege — Hard Processor System Technical Reference Manual The HPS2FPGA target socket is likewise Privileged and enforced by the NOC. 13. System Interconnect and Firewalls > 13.4. System Interconnect and Firewalls Functional Description > 13.4.3. Transaction Privilege > Table 373. Target Privilege — Hard Processor System Technical Reference Manual If the NOC firewall is misconfigured, the transaction can be blocked silently. Check whether you have any custom firewall or NOC settings in your BSP that differ from the default.
Recommended debug sequence:

1. Signal Tap: probe hps2fpga_axi_clock and lwhps2fpga_axi_clock while the CPU is frozen — confirm they are toggling.
2. From Linux, read the bridge manager enable register and confirm both bridges are enabled before attempting the write.
3. In Platform Designer, verify h2f_reset → hps2fpga_axi_reset and h2f_reset → lwhps2fpga_axi_reset are both connected.
4. Temporarily connect the bridge output to a simple on-chip memory in the FPGA design to rule out a missing subordinate.
5. Try a read from a known-safe address in the bridge window (e.g., the base address) first rather than a write, to see whether both directions stall equally.

The fact that you see no traffic at all on the bridge strongly points to either the FPGA-side clock not running or the bridge not being enabled in software — those two should be your first checks.

Note: To continue using AI Responder, please start your next inquiry with ai_responder

Disclaimer: AI-generated responses may contain errors or omissions. Please verify technical guidance with official Altera documentation before implementation.

Thank you very much.