IPCF on Linux doesn't work if using only channel

[kawin]

I haven't tested all cases but if I use only one unmanaged channel to communicate between A53 Linux and M7 firmware apps, interrupt on the Linux doesn't get triggered more than once.

• IPCF User Space 4.3 on A53 Linux
• IPCF 4.3 on M7 firmware
• Interrupt-based

Below is my initialization function for IPCF

static int setup_ipc_instance(void) {
    // IPC channel configuration
    const int number_of_channels       = 2;
    struct ipc_shm_channel_cfg channel = {
        .type = IPC_SHM_UNMANAGED,
        .ch =
            {
                .unmanaged =
                    {
                        .size   = CHANNEL_SIZE,
                        .rx_cb  = rx_irq_callback,
                        .cb_arg = &app,
                    },
            },
    };

    // This is due to a bug in the driver which requires more than one channel.
    // Without this, rx_irq_callback wouldn't get triggered after the first interrupt
    struct ipc_shm_channel_cfg dummy = {
        .type = IPC_SHM_UNMANAGED,
        .ch =
            {
                .unmanaged =
                    {
                        .size  = 1,
                        .rx_cb = rx_irq_callback,
                    },
            },
    };

    struct ipc_shm_channel_cfg channels[] = {channel, dummy};

    // IPC shared memory configuration
    struct ipc_shm_cfg shm_cfg[] = {
        {
            .local_shm_addr    = LOCAL_SHARED_ADDR,
            .remote_shm_addr   = REMOTE_SHARED_ADDR,
            .shm_size          = IPC_SHARED_SIZE,
            .inter_core_tx_irq = INTER_CORE_TX_IRQ,
            .inter_core_rx_irq = INTER_CORE_RX_IRQ,
            .local_core =
                {
                    .type  = IPC_CORE_DEFAULT,
                    .index = IPC_CORE_INDEX_0,
                    .trusted =
                        IPC_CORE_INDEX_0 | IPC_CORE_INDEX_1 | IPC_CORE_INDEX_2 | IPC_CORE_INDEX_3,
                },
            .remote_core =
                {
                    .type  = IPC_CORE_DEFAULT,
                    .index = IPC_CORE_INDEX_0,
                },
            .num_channels = number_of_channels,
            .channels     = channels,
        },
    };

    struct ipc_shm_instances_cfg instance_cfg = {.num_instances = 1u, .shm_cfg = shm_cfg};
    return ipc_shm_init(&instance_cfg);
}

[Bio_TICFSL]

Hello Kawin,

I am asking the IPCF development team whether this issue has been previously seen and may also attempt to replicate the issue with my setup. Before doing that, I wanted to clarify some points to make sure that I properly understand the question.

Overall, the behavior that you is encountering is that whenever you setup a single unmanaged channel between two cores, the first message will successfully transmit over that channel. Any subsequent messages that are transmitted will not result in the RX interrupt going high, causing the remote core to not receive the message. In order to mitigate the issue, an additional unmanaged channel was added (i.e. the "dummy" channel in the code above). Once this second channel was added, there were no longer any issues in messages being transmitted and received. Is this understanding correct?

Assuming that it is, can you provide further clarification on the following:

• When only one channel is setup, has it been verified that the RX interrupt is not going high?
  • Ex. If an M7 core is the recipient, then you can verify whether its RX interrupt is going high by attaching a debugger and looking into the NVIC Interrupt Active Bit Registers corresponding with the RX interrupt to determine if it is becoming active. The following ARM M7 documentation provides more details about these registers:
    • M7 NVIC Documentation
    • M7 Interrupt Active Bit Registers
• If you have an existing project without any customer proprietary information that produces the error, can it be provided?

Thanks in advance for any details that you can provide.

Regards

[Bio_TICFSL]

In addition, do you mind clarifying the following as well:

• Which core and associated interrupt is the RX not occurring with?
• Is this issue only being encountered with uni-directional data flows through the unmanaged channel or is it also happening with bi-directional (i.e. A53 -> M7 and M7 -> A53) data flows?

Regards