https://e2e.ti.com/support/processors-group/processors/f/processors-forum/590205/dra745-dra745x
器件型号：DRA745我们将在单通道仅主模式下对 MCSPI 通道之一进行编程，因此我们不使用 SPI 总线的 MISO 或 Rx 侧。 我们将 MCSPI 编程为中断 FIFO 驱动。 因此、我们期望在 SPI FIFO 需要数据时触发中断、并且我们使用16位字大小对 SPI 器件进行编程。 我们看到 FIFO 中几乎为空的中断没有触发的情况，并且我们正在将我们的头划在这个中断上。 出于某种原因、MCSPI 模块不会将 TX FIFO 空/几乎为空的中断置为有效、即使该中断已完全为空。
我们发现、如果我们在 ISR 处理程序中人为地插入延迟、问题似乎就会消失、好像有某种硬件时序问题。 请注意，我们不是仅使用 DMA 中断驱动 FIFO。
这是手册中写得不好的部分之一。 这似乎意味着几乎为空的中断一旦被置为有效、直到发生"足够"的写入访问之后才会重新置为有效。 但是，我无法在我们的 ISR 处理程序中看到这是如何发生的。 一旦中断发生，我们将写入，直至 TX FIFO 已满(或我们已写入整个消息)。 因此，我看不出我们的代码怎么可能写得不够，无法使中断重新生效(一旦 FIFO 再次变为足够空)。 而且，一旦我们编写完最后一条消息，我们就不关心几乎为空的中断，因为当时我们真的在等待 OOW 中断。 (但是，当然，当 WCNT 没有达到零时，由于几乎为空的中断不会出现，我们也不会看到 OOW 中断。 因此，我们将经历超时。
因此，我看不到任何解释，为什么在失败时 MCSPI_IRQSTATUS[0] TX0_emtpy 不像它应该的那样再次置位。 我也看不到任何解释、说明在 ISR 末尾添加延迟似乎使它正常工作。 在良好(使用 for 循环延迟)和不良情况下、第二个或最后一个 ISR 至少写入30个字节、 应足以满足手册中的注释(关于执行正确的写入访问次数)、因此应将几乎为空的中断置为有效。 但有时确实如此，有时甚至不会这样做。
我们只会在大 SPI 传输和大512字节时看到这个问题。 如果我们发送的数据少于512、则永远不会由于缺少中断问题而进入该超时。 较小的传输大约为200-300字节。
另一个观察结果是、我们在 ISR 中的哪个位置添加了回路延迟似乎无关紧要。 (我在几个地方尝试过。) 只要存在“足够”的延迟，在某处，事情就能正常工作。 哦，还有 BTW，只要总延迟“足够”，导致延迟的原因似乎并不重要–简单的循环、使用我们的 JTAG 的高级调试日志记录或其中的某种组合。
另一项观察/测试：
因此、我开始想、当我们的代码到达 mcspiFifoTxFill 函数(我们在其中填充 FIFO)时、如果 FIFO 水平在开始向 FIFO 写入新字之前没有下降到足够远的接近空阈值(即、中断被置为有效时)、 这样可以防止生成下一个几乎为空的中断。 (可能是延迟使其足够下降、间接解决了问题。) 因此、我在 mcspiFifoTxFill 的开头添加了一个循环、以等待 FIFO 电平降至某个较低的阈值(我可以在调试器中设置该阈值)。 由于 FIFO 水平随着字的传输而不断下降，所以这并不是很精确，但我认为这会让我知道是否有这种理论的东西。
但我在本实验中发现、在 ISR 执行开始时、FIFO 水平通常远高于它本来应该生成中断的水平。
要说明的是，FIFO 的配置方式，TX 和 RX 都有64字节，尽管我们实际上只使用 TX FIFO。 TX 几乎空阈值设置为16字节(低于满字节)。 因此，在 FIFO 级别下降到48字节之前，不应发生中断。 但我发现、当 FIFO 电平高达62字节时、中断被置为有效！
因此，MCSPI 外设似乎不像手册“描述”那样运行。 它似乎经常过早地将几乎为空的中断置为有效。
