IPC between AppCore (ARM) and FLPR (RISC-V)

[Fridtjof]

Good day, Nordic staff!

We are working on a product using the FLPR for its intended peripheral-controlling purpose. For us, the best way to send commands to and receive responses from FLPR would be sending/receiving structs through some sort of IPC. Right now, we manage to send single values and strings without problem, using icmsg. However, sending structs between the cores runs into problems with struct packing between ARM and RISC-V.

Have Nordic thought of some smart way to handle IPC between App Core and FLPR, so that the struct packing issue goes away? Or do we have to find some way of serializing the data?

The struct we want to send is defined in a header file approximately 3000 lines long, so we would appreciate not having to write a matching protobuf (or similar) definition.

-Fridtjof

[Amanda Hsieh]

Hi, 

For IPC between AppCore (ARM) and FLPR (RISC-V), Enum size and bitfields are common sources of incompatibility. You can force enum size using a technique like adding a large value (e.g., EMP_CMD_FORCE_INT_SIZE = INT_MAX) to the enum, or enabling CONFIG_COMPILER_OPT="-fshort-enums". Avoid bitfields or ensure they are defined with explicit sizes and tested for compatibility. 

Using icmsg for big structs is not perfect from a performance perspective because icmsg involves data copying. If a structure is large, it is better to allocate a buffer in a shared memory pool (e.g., heap, slab) and pass the pointer through IPC. It's more complex to manage shared buffers in a pool, but it performs better.

Regards,
Amanda H.

[Fridtjof]

Thanks, Amanda! My colleague Raoul tested -fshort-enums, and it seems to work for us, although the struct is too complicated (lots of unions and sub-structs) to know if it works in all cases yet.

The total size of the struct is only 48 bytes, so we are comfortable using icmsg and copying it.