|
ra8-firmware 0.1.0
Bare-metal firmware for the Renesas RA8 family (RA8D2 / RA8P1)
|
Directories | |
| inc | |
| src | |
Runs a full ThreadX + USBX CDC-ACM self-loop entirely inside the Non-Secure image (#60), layered on the Non-Secure-Callable CGC veneer wall. Both USB controllers are delegated to the NS world and the chip enumerates and echoes against itself over a J7-to-J11 loop cable – no PC, no manual cabling.
It is a two-project build (#96): a Secure ELF carrying the secure boot and the NSC CGC veneers and emitting a CMSE import library, plus a separate Non-Secure ELF, merged into one flashable hex. NS-to-Secure calls bind to the Secure-Gateway stubs through that import library.
Two Non-Secure ThreadX threads share the core. USBFS on J11 is the CDC-ACM device, driven by polling ra8_usb_dispatch, with Chapter-9 and bulk auto-echo running inside the dispatch. USBHS on J7 is a polled host built on the first-party ra8_usb_host_* primitives: bus reset, GET_DESCRIPTOR, SET_ADDRESS, SET_CONFIGURATION, open the CDC bulk pipes, then bulk round-trip a deterministic pattern and byte-check the echo forever. The host's polling windows are far longer than the thread time-slice, so the device dispatch gets serviced inside them without any USB interrupt at all.
g_tz_usb_host_rounds_ok advances only once the whole chain works – veneers, NS ThreadX, NS USBX device bring-up, NS host enumeration over the loop, and a verified OUT/echo/IN round-trip – so a climbing counter is end-to-end proof. DSCSR.CDS reading 0 confirms the CPU really is Non-Secure while it happens.
The expander error is tracked separately from the pin-configuration error for a reason. On a cold boot the single host-mode I2C write lands; after a J-Link/SYSRESETREQ warm reset RIIC1's BBSY can still be set and the write reports k_ra8_err_busy. The external PI4IOE latches its host-mode output regardless, so the USBHS host role persists across the warm reset and the loop still enumerates – a busy expander write here is not a failure.