Interrupt Triggering Condition on the IMX8MP's M7 Firmware on an RX register write on the Messaging Unit

We are facing an issue where the QNX 8.0 Kernel does not detect any interrupt to be delivered from the Messaging Unit. Assuming the RIEn Bit for RX 3 has been been correctly set on the Control Register of the Messaging Unit’s A core side, Is there anything explicit that needs to be done on the M core side (running firmware), besides writing to the TX 3 register (To trigger an interrupt once RF3 bit on the A core’s Status Register)?

Below is the snippet of the firmware attempting to write to the TX3 register:

int main(void)
{
 \
    BOARD_InitMemory();

    /* Board specific RDC settings */
    BOARD_RdcInit();

    BOARD_InitBootPins();
    BOARD_BootClockRUN();
    BOARD_InitDebugConsole();

    PRINTF("====\nMessaging Unit test -- C-M7====\r\n");
    uint32_t ticker = 1U;

    MU_Init(MUB);

    int trigger_interrupt_counter = 200;
    while (1)
    {
        delay();

        if (ticker % trigger_interrupt_counter == 0) {

                MU_SendMsg(MUB, 3U, 128);

                        PRINTF("TX3 - Message sent to trigger interrupt\r\n");
                        ticker = 1;
                        trigger_interrupt_counter = 25;
        }

        PRINTF("Ticker: %d , SR: %X, CR: %X\r\n", ticker++, MU_GetStatusFlags(MUB), MUB->CR);
    }
}

Hi, I’m the Toradex AI Assistant.

I might make mistakes. Our support team will step in if needed. If I answered your question, please tick the “Solution” checkbox. For follow-up questions to me, please use @ToradexAI in your post.

Did you like my answer? :+1: :-1:


Messaging Unit Interrupt Configuration Requirements

Based on the Messaging Unit documentation for i.MX processors, there are several key requirements that must be met for proper interrupt delivery from the M-core to the A-core.

Required Configuration on M-Core Side

Besides writing to the TX3 register, you need to ensure:

1. Transmit Interrupt Enable (TIE3) Configuration

The TIE3 bit in the M-core’s Control Register (MUB->CR) must be set to enable transmit interrupts. This allows the M-core to receive confirmation when the A-core reads the message.

2. Verify Transmit Empty Status Before Writing

Before writing to TX3, check that the TE3 bit in the Status Register is set (indicating the transmit register is empty):

// Check if TX3 register is empty before writing
if (MU_GetStatusFlags(MUB) & kMU_Tx3EmptyFlag) {
    MU_SendMsg(MUB, 3U, 128);
    PRINTF("TX3 - Message sent to trigger interrupt\r\n");
} else {
    PRINTF("TX3 register not empty, skipping write\r\n");
}

3. Proper MU Initialization

Ensure the Messaging Unit is properly initialized on both sides with compatible clock configurations.

A-Core Side Verification

Confirm on the QNX A-core side that:

  1. RIE3 bit is set in the A-core’s Control Register
  2. RF3 bit status is being monitored in the A-core’s Status Register
  3. The interrupt handler is properly registered for the MU interrupt line

Debugging Steps

  1. Monitor Status Registers: Check both MUB->SR (M-core) and MUA->SR (A-core) registers
  2. Verify Clock Synchronization: Ensure both cores’ MU clocks are properly configured
  3. Check Event Pending (EP) bit: Monitor the EP bit in the Status Register for synchronization issues

Additional Considerations

The Messaging Unit has specific timing requirements:

  • Minimum event latency: 1 clock (sending side) + 2.5 clocks (receiving side)
  • Maximum event latency: 6 clocks (sending side) + 6.5 clocks (receiving side)

If the issue persists, verify that the QNX interrupt controller is properly configured to handle the MU interrupt line and that no other system-level interrupt masking is occurring.

Best regards, Toradex AI Assistant.

image

Toradex has no Verdin modules based on iMX6 SoCs. NAD iMC6 SoC has no M cores.
I assume you are talking about Verdin iMX8M plus. All Verdin BSP development was done by QNX company so we don’t have deep knowledge about it internal. So I’d recommend to use QNX support channels for such question .

In general please double check

  • if the MU peripheral clock enabled via CCM and releasing from reset via CCM or RDC.
  • RDC (Resource Domain Controller) permissions are properly set for the M7 to access MU_B
  • The i.MX8MP has MU_A and MU_B.
  • Confirm that QNX is listening on RX3 of MU_B, not MU_A.
  • The MU interrupts must be routed correctly through the GIC (GICv3 in 8MP) to QNX.
  • Enable RX3 interrupt bit in MU_B_CR on A53 side
  • Attach and unmask the GIC IRQ in QNX
  • If a previous message filled RX3 before interrupts were enabled, RF3 may already be set. Read RX3 once to drain it, then re-enable/unmask and try again.

Thank you for the update. It’s great to know that your issue has been successfully resolved.

Alexander Samutin
Toradex