Dear support team,
We are designing our custom board with an IMX9332C.
We chose not to use U-Boot as our bootloader, but Barebox instead, so sadly we cannot benefit from the work already done in uboot-imx. Our boot chain is as follows: TF-A → Barebox → Linux.
Versions: imx-atf lf-6.18.20-2.0.0, Barebox 2025.09.0 (custom board port), Linux 6.18.13.
We want to use the Cortex-M33 auxiliary core for our real-time-constrained features. The idea is to compile bare-metal code with the SDK, then load the resulting binary via the remoteproc framework from Linux.
I wrote and compiled a very simple C program that blinks an IO. When I load it with remoteproc, the framework reports that it has been loaded, but it does absolutely nothing. Whenever I stop it, it crashes.
My first guess was that the core wasn't correctly configured, so I dug into how u-boot prepares the M33 on NXP's FRDM reference board. I found that the M33 core has to be "prepared": its RAM must be zeroized, the watchdog configured, the TCM set up, etc. I ported some of these operations into my low-level initialization code in Barebox, but now when I load the code with remoteproc, it resets instantly.
At this point, I looked at the SRSR register to find the root cause of the reset, and the M33_REQ bit is set.
Looking at the documentation, this means a reset was requested by the Cortex-M33 itself.
I currently have no idea why this reset request is emitted; it isn't triggered anywhere in my own code.
Here are my questions:
Is there any documentation on the full requirements for "preparing" the M33?
What are the possible sources of a CM33_REQUEST reset ? Where could this come from?
Thank you.
image.png