Hi everyone,
I’m struggling with an OpenAMP / RPMsg problem on an STM32MP157 (M4 core).
When I compile exactly the same application with STM32 CubeIDE (GCC) everything behaves as expected – two virtual‐UART channels (ttyRPMSG0/1) come up on the A7 and messages flow both directions.
As soon as I switch the project over to IAR EWARM (v9.40):
Linux still detects the vrings, creates /dev/ttyRPMSG0 and /dev/ttyRPMSG1, and the kernel log shows
virtio_rpmsg_bus virtio0: rpmsg host is online
rpmsg_tty … new channel: 0x400 -> 0x0 : ttyRPMSG0
Writing from the A7 side blocks indefinitely:
echo "hello" > /dev/ttyRPMSG0 never returns.
On the M4 console I see no “Msg received…” printout – not even the IPCC interrupt fires (added a GPIO toggle inside HAL_IPCC_RX_IRQHandler for confirmation).
What I have verified / tried
Interrupt vectors – IPCC_RX1_IRQHandler and IPCC_TX1_IRQHandler are present in startup_stm32mp15xx.s, and the symbols appear in the EWARM map file.
Mask bits – explicitly call
- HAL_IPCC_EnableReceiveChannel(&hipcc, IPCC_CHANNEL_1);
HAL_IPCC_EnableTransmitChannel(&hipcc, IPCC_CHANNEL_1);ght after HAL_IPCC_Init(). Still no luck.
OpenAMP shared-RAM placement – added a dedicated region in the ICF (0x1004 0000, 32 KB) and marked it do not initialize to avoid zero-fill at reset.
Confirmed the M4 is up (printf over UART5 works) and OPENAMP_check_for_message() is called in the main loop.
My suspicion is that something in the IAR start-up (or the ICF) still wipes or misaligns the vring buffers before Linux gets a chance to poke the IPCC, but I’m out of ideas.
Has anyone hit this mismatch between CubeIDE/GCC and IAR before?
Any checklist I’ve missed (linker pragmas, section names, optimisation quirks …)?
Happy to provide:
Thanks in advance for any hints!
