Every host API operation returns a result or error code. The full catalog, both AXI and Classic, the numeric values, and the host-side recovery calls are on the SDK’s Error Codes page. Only the codes that point at your gateware or design appear below.

The gateware-related codes. Each one sends you to a specific part of your design.

• AXISlaveError (SLVERR): your Subordinate accepted the address, then returned an error response. Go to your Subordinate.
• AXIDecodeError (DECERR): the address decoded to no Subordinate. Go to your address map and interconnect.
• GatewareTimeout: the operation stalled past its timeout. The call form that omits an explicit timeout uses a 10 s default, uniform across the three interfaces. Read the returned counts first, under Diagnosing with the Counts, then re-issue the remainder or reset the interface.
• FrontPanelNotEnabled: okHost cannot be detected in the loaded bitstream. It is either not present or cannot be reached. Confirm that you built and configured the correct FrontPanel-AXI bitstream.

The okHost reporting behavior, that a Full read or write or a bulk AXI-Lite run reports the last non-OKAY response and OKAY never overwrites it, is documented once under Error Codes and Reporting.

Everything else. If a code that is not listed above appears, resolve it on the SDK Error Codes page, and contact Opal Kelly support if it persists.

The three per-interface resets are provided for recovery as well as bring-up. If an interface returns an error you cannot clear, or the bus hangs, issue that interface’s host reset to return its bus structure to a known state, then retry. The three are independent; see Resets.

For example, suppose an AXI-Lite Subordinate violates the protocol and never completes a transaction, leaving its handshake unfinished. The interface hangs and the operation times out. A hung bus cannot clear itself, so the AXI-Lite interface’s host reset is the fallback, letting you retry without reconfiguring the FPGA.

On a GatewareTimeout, the returned partial counts are your first debug step, before any hardware instrumentation. The full technique is on Diagnosing with the Counts.

Runtime error codes are on Error Handling above. IP Core and IP Integrator troubleshooting is in the IP Core Troubleshooting guide.

Smoke-test the board first. Confirm that the board and your FrontPanel install are healthy, independently of your gateware, with the FrontPanel health-check app on the FrontPanel SDK Troubleshooting page. Fix that before debugging your AXI design.

If Troubleshooting did not resolve your problem, or you want to give feedback, reach out to Opal Kelly technical support at [email protected].

In scope: okHost and the FrontPanel-AXI HDL, the SDK and Vivado IP Core delivery, okHost’s AXI behavior, our example designs, and the FrontPanel API and tooling. Out of scope: the AMD Vivado toolchain and the AXI protocol itself. For general Vivado usage, use the AMD documentation (Designing with IP, DH0003; Using IP Integrator, DH0009); for the AXI protocol, use the Arm AMBA specifications.

When you contact support, include your FrontPanel SDK version (and the IP Core Distribution version if you used it), your Vivado version, your OS, your board and bandwidth mode, a description of the problem, the exact errors or messages, and the steps to reproduce.

• System Design: diagnose with the counts, instrument with an ILA or the AXI Protocol Checker, and compare against PerfTest.
• Getting Started: get okHost onto your board. The delivered files are on Delivery and Files; the board notes are on okHost Core.
• okHost Core: the component facts (error-code mapping, counts, timeout).
• Simulation: drive these interfaces in simulation.
• FrontPanel API: drive okHost from host software.