您好！
SDK：8.5.0.4
我修改了 TI 的示例、以获得16字长、而不是初始8字长、我尝试将主 SPI 时钟速率从初始50MHz 降低到10MHz。 此外、我确实将"操作模式"更改为"多主器件"、以便 SPI0-IP 处理来自硬件而不是来自软件的片选确认/否定。 只要 SPI 为50MHz 或25MHz、这就可以正常工作。 如之前所述、降低 SPI 时钟10MHz、我确实会从 controlCARD 集线站在 SPI-HW 引脚接口上获得完美信号。 但是程序永远不会返回。 它永远"挂起"在那里。
深入挖掘并复制 SDK 的一些 MCSPI 驱动程序代码、以便更轻松地进行更改我能够跟踪"循环"、它绝不会留下、以防我们有10MHz 的时钟。 该循环位于函数中
int32_t SemaphoreP_pend (SemaphoreP_Object *对象、uint32_t 超时)；
在此函数中、while 循环正在等待信号量释放、即硬件资源被释放、依此类推。 当我在这个 while 循环的区域中执行一个断点时、我可以将信标添加到 TI-CCS 的表达式窗口中并单步执行代码、一旦这个信标的值从"0"恢复到"1"、代码就可以离开这个 在循环过程中、程序会继续执行并完成、就像在50MHz 或25MHz SPI 时钟版本中一样。
第2个。 我确实在这个演示程序的主中断处理例程中添加了一个断点、以验证是否正在处理所有中断。 该文件如下所示：
我能够记下正在处理的中断编号。 如果程序正常终止、则会出现三个中断、即 SPI 时钟为25MHz 或50MHz。 我能够捕获的中断编号为：
ISR intNum --> 84这是来自基本定时器 RTI0的数字
ISR intNum --> 56这是 EDMA 通道控制器0的数字
ISR intNum --> 38这似乎与 UART/Console 相关。
中断编号的含义摘自 TRM (修订版 C)表10.17 (第758pf 页)文档"SPRUJ17C–2022年3月–2022年11月修订版"。 如果 SPI 时钟为10MHz、则演示程序永远不会完成、我会得到 intNum 56永远不会被服务的印象。 在从"SemaphoreP_pend (SemaphoreP_Object * obj、uint32_t timeout"的 while 循环中添加断点我可以验证正在处理的 intNum 56、信标值被更改为返回"1" while 循环被保留、主程序按预期终止。 
在右上角突出显示的黄色、一旦信标计数恢复为"1"、程序将按预期终止。 我不知道这是否有道理。 它看起来是一个驱动程序问题、并且中断可能是这个问题的一部分。
BR
Markus
