Other Parts Discussed in Thread: OMAP-L138
We're running an application between two OMAP-L138 processors on different boards over a serial connection. The serial connection runs at 460800bsp. On one side we have an FPGA-based UART, and on the other we are using the OMAP UART from the DSP core. We're using the UART in interrupt mode, not DMA interrupt mode.
We are able to communicate most of the time, but occasionally on the OMAP UART we'd notice it stop transmitting.
After a while, we realized that if we manually poked the UART's THR with a byte while it was in this "stuck condition", we could "jump start" the UART and it'd start transmitting again.
I took a look through the biospsp_03_00_01_00/drivers/uart/src/Uart.c. One thing struck me as odd. In the SWI for handling receive/transmit I/O that is kicked off by the HWI, there's the following:
static Void uartIntrHandler(Uart_ChanObj *chanHandle)
{
...
/* If this is called from SWI(Tasklet) context */
if (Uart_OpMode_INTERRUPT == instHandle->opMode)
{
EventCombiner_enableEvent(instHandle->deviceInfo.cpuEventNumber);
}
... (handles events here)
/* If this is called from SWI(Tasklet) context */
if (Uart_OpMode_INTERRUPT == instHandle->opMode)
{
EventCombiner_enableEvent(instHandle->deviceInfo.cpuEventNumber);
}
}
I think the first call to EventCombiner_enableEvent (in red) really should be a call to EventCombiner_disableEvent. I have modified the code and no longer see the UART transmitter stopping as before.
Logically, it makes sense. While the SWI is running the interrupt should be disabled. But in the code the way it originally is it isn't disabled so a new HWI could interrupt the SWI and cause confusion.
