尊敬的 TI 团队：
我正在使用 TMS320C6424 PCI 模块。 我成功开发了能够读取 ADC 数据的 Linux 驱动程序和固件。 我只使用了6个条中的2个。 我用于通过 PCIBARnMSK = 0禁用棚舍。
我的固件在同一 PCI 总线上连接2个 TMS320C6424之前一直工作正常。 经过几天的调试后、我发现 PTRDY_N 信号由两个 DSP 反向驱动。 下面是总线信号的图片：
如果我启用所有条形图、问题消失。 到目前为止、通过将所有6个条形图配置为相同大小和相同位置、我可以在一条总线上使用两个 TMS320C6424。 看起来、如果至少有一个 PCIBARnMSK 寄存器设置为0、则 PCI 通信会中断。
能否确认这是否是 TMS320C6424中的错误？ 在 TMS320C6424中禁用条形的正确方法是什么？
此致、
基里尔
您好 Eric！
下面是我的设置图：
我在 Windows XP 和 Linux Ubuntu 上进行了测试：相同的双板问题。
我使用基于 FPGA 的电路板来监控 PCI 总线信号。 所有 FPGA 引脚均配置为输入将禁用上拉/下拉。 如果不使用此 FPGA 板、我也会得到相同的结果。 稍后我将通过信号分路器向您提供图片。
以下是6条固件板的 lspci 输出：
可以通过器件编号(本例中为0b 和0e)识别电路板。 对于特定 PCI 总线拓扑、这些数字是固定的。 要了解哪个器件编号对应于物理端口、我使用 JTAG：只需读取 PCIBARnTRL：
为了证明问题、我已将固件恢复为使用2条而不是6条。
以下是 Linux 中的 lspci 输出：
以下是信号分路器上的单个配置读取事务：
数据读取事务是假的：
我可以在 JTAG 连接中看到以下内容：
以及我怀疑地址解码机制的原因。 以下是 SPRUEN3C 第27页的屏幕截图：
如果 PCIBARnMSK =0和 PCIBARn =0、则任何 AD 都将匹配[n]=1。 如果此图与实际地址解码有关、则 C6424的 PCI 有问题。
基里尔
