Dear NXP team,
we're working on a QNX driver for the LLCE CAN firmware, currently using firmware version 1.0.1.
We've got sending and receiving mostly implemented, but right now we're facing a problem with interrupt routing for BLR-OUT_FIFO interrupts.
Interrupts are working just fine for e.g. the RX-OUT_FIFO, which tells us there's a received frame available.
The issue we're hitting is that when we want to send several frames faster than the hardware is able to transmit CAN frames, eventually the BLR-OUT_FIFO is going to run out of empty indexes for the transmission descriptor table. At this point we need to wait until new indexes become available, and we'd like to use an interrupt for this.
The issue is that we're not seeing an interrupt being triggered on the A53 for the BLR-OUT-FIFO.
We've configured the BLR-OUT_FIFO for our channel to route the FIFO not empty interrupt line to interrupt line B, we've enabled the interrupt, and we can see that there are entries available on the FIFO again (FNEMTY set in FIFO status register 1). The ICSR20 register reads 0x1, and the interrupt router register IRSPRC48 is configured to route that interrupt to all cores (0xf), just like all the other interrupts.
From the documentation it's not really clear what the path from the ICSRn register to the GIC looks like. There's a table in the RM chapter 54.13.2 that talks about a IRCM (interrupt routing configuration module) that lists the interrupt concentrator status registers ICSR0..27 and the IRSPRCn registern responsible for routing those interrupts. The table also seems to indicate which of those interrupts go to a host or one of the LLCE internal cores. From that we've assumed that "A line" interrupts are for routing to "LLCE internal cores" and "B line" interrupts are for routing to "host cores", but we're not sure whether that mapping is configurable.
The term "IRCM" is only mentioned within the LLCE chapters, but the IRSPRCn registers are apparently part of the MSCM. These registers are all set to 0xf in our case, and should thus route all the interrupts to all the cores.
The Linux driver and the driver sources that come with the LLCE firmware don't appear use interrupts to be informed when new entries are available on BLR-OUT_FIFOs. I'm guessing they assume that when a TXACK has been delivered, it can be assumed that there's going to be a descriptor available on BLR-OUT again, too, but a) we don't need the TXACK, since we don't care about the TX timestamp, and b) we don't know if there's any timing guarantee between TXACK indicating a transmission and a new entry being available on BLR-OUT.
It seems that the LLCE firmware configures "something" to make the connection from ICSRn to the A53 GIC interrupt, because if we just configure RX-IN_FIFO to trigger an interrupt in ICSR14 (ICSR14 reads 0x1) without loading/initializing the LLCE firmware, we don't get an interrupt at the GIC. Later, when the LLCE firmware is running, we get an interrupt whenever ICSR14 is != 0x0.
Regards,
Dominic
Hi,
There are 2 parts of IRSPRC that you have to configure: one from LLCE and one from MSCM. You have to configure both of them for routing interrupt to host core. IRSPRC48 belongs to LLCE, it isn't MSCM_IRSPRC. It seems that you configured this register in the wrong way
Hi,
thanks a lot for your reply.
Okay, so that "LLCE-side" IRSPRC is probably the one mentioned in the RM §54.13.2. Unfortunately these registers are undocumented. The RM only documents the MSCM_IRSPRC registers (§8.4.23), and it calls them just "IRSPRC". Thanks for the clarification that these are separate registers.
The "LLCE IRSPRC" registers are apparently configured by the LLCE firmware, so I guess the following questions remain:
Best Regards,
Dominic
This issue has been resolved through a private ticket.