embassy-rs/embassy · error
APS6404L PSRAM verification not implemented for RISC-V
Error message
APS6404L PSRAM verification not implemented for RISC-V
What it means
read_aps6404l_kgd_eid performs PIO-based reading of the APS6404L PSRAM manufacturer/device ID; the assembly path exists for ARM Cortex-M0+, but on riscv32 targets it is unconditionally unimplemented. The function therefore always panics when compiled for RISC-V RP2350 boards.
Solutions
- Build for the Cortex-M33 target instead of riscv32 (e.g. thumbv8m.main-none-eabihf)
- Skip or gate PSRAM verification on RISC-V and implement your own ID read via QMI direct commands
- Contribute an riscv32 PIO/asm implementation for the KGD/EID read
- Patch the cfg to return a known-good fallback on riscv32 if verification is not essential
Example fix
// before # cargo build --target riscv32imac-unknown-none-elf // after # cargo build --target thumbv8m.main-none-eabihf
Defensive patterns
Strategy: type-guard
Validate before calling
#[cfg(target_arch = "riscv32")] compile_error!("PSRAM verification unsupported on riscv32; build for ARM"); Type guard
const PSRAM_VERIFICATION_SUPPORTED: bool = cfg!(not(target_arch = "riscv32"));
Prevention
- Build RP2350 PSRAM apps for thumbv8m.main-none-eabihf
- Gate PSRAM usage behind target_arch checks in your board support crate
When it happens
Trigger: Calling psram init/verification code (read_aps6404l_kgd_eid) on embassy-rp with target_arch = "riscv32" (RP2350 RISC-V core).
Common situations: Using the RISC-V (Hazard3) cores of the RP2350 with external PSRAM; the same code works when building for the ARM cores.
Understand the failure class
Background: "unsupported platform" / "not supported on this platform" errors: what they mean and how to fix them — this error's family across 47 libraries.
Related errors
- Direct CSR command sending is not implemented for RISC-V yet
- SYS not supported yet
- AUDIOCLK not supported yet
- Flexable pixels are not yet implemented
- Can only take the executor once
AI-assisted analysis of embassy-rs/embassy@463a07b963 (2026-09-10).
Data as JSON: /api/errors/df1b426fbbc06218.
Report an issue: GitHub.
Appendix: source
Thrown at embassy-rp/src/psram.rs:437
"movs {temp}, #0",
"str {temp}, [{qmi_base}]",
// Memory barriers
"dmb",
"dsb",
"isb",
qmi_base = in(reg) qmi_base,
temp = out(reg) _,
counter = out(reg) _,
kgd = out(reg) kgd,
eid = out(reg) eid,
reset_enable_cmd = const RESET_ENABLE_CMD as u32,
read_id_cmd = const READ_ID_CMD as u32,
options(nostack),
);
#[cfg(target_arch = "riscv32")]
unimplemented!("APS6404L PSRAM verification not implemented for RISC-V");
(kgd, eid)
}
/// Initialize PSRAM with proper timing.
#[unsafe(link_section = ".data.ram_func")]
#[inline(never)]
fn init_psram(qmi: &pac::qmi::Qmi, xip_ctrl: &pac::xip_ctrl::XipCtrl, config: &Config) -> Result<(), Error> {
// Set PSRAM timing for APS6404
//
// Using an rxdelay equal to the divisor isn't enough when running the APS6404 close to 133 MHz.
// So: don't allow running at divisor 1 above 100 MHz (because delay of 2 would be too late),
// and add an extra 1 to the rxdelay if the divided clock is > 100 MHz (i.e., sys clock > 200 MHz).
let clock_hz = config.clock_hz;
let max_psram_freq = config.max_mem_freq;
let mut divisor: u32 = (clock_hz + max_psram_freq - 1) / max_psram_freq;
if divisor == 1 && clock_hz > 100_000_000 {View on GitHub (pinned to 463a07b963)