6678 多核导航器 中断

都属于Acc channel中断事件，使用方式是一样的，需要注意的是在中断中需要clear system interrupt，写Acc 中断EOI寄存器保证下一个事件的可触发。

您好！

        核0向核1发消息(消息在描述符的buff里，在DDR中)，那么核0向721队列(使用的50事件)push进有效的描述符，

并使用两条mfence指令保证将描述符压进721队列，那么PDSP将该描述符的地址写到核1的List Address，

并向核1上产生一个中断，告知描述符的地址。不知道我这样理解对不对？

        中断的处理参考了论坛提供的Keystone1包里的Multicore_Navigator工程中断处理的代码，具体如下:

      1. /*read interrupt status*/ 通过读中断状态寄存器gpQM_INTD_regs->STATUS_REG0、2、4.

      2. /*clear interrupt status*/清除gpQM_INTD_regs->STATUS_CLR_REG0、2、4的状态

      3.在List Address里读取描述符的地址，打印出消息(测试用)。

      4. 遍历各通道，反复执行下面两步:

          gpQM_INTD_regs->INTCNT_REG[i]= 1 ; 写Interrupt N Count Register，一直没搞懂这个寄存器是干嘛的？

          gpQM_INTD_regs->EOI_REG= i+2;    写EOI寄存器，重新允许该通道触发下一个中断

       5.回收描述符

     在调试中，我发现以下问题，具体如下：

     1.PDSP写到List Address里的描述符地址有时候不是描述符真正的地址(一般为0)，这时往往导致消息的出错。

      请问怎么保证那个地址是准确的？或者有没有比较好的纠错或容错办法？

     2. 两条mfence指令紧跟在push描述符操作后面能否保证描述符确实入队了？如果不能该怎么保证？

     3. 除开中断处理的第三步和第五步，该中断处理流程有没有问题？会导致什么问题？

          Interrupt N Count Register具体作用是什么，应该怎么正确使用？

     4. 我根据中断处理第三步打印出的消息信息，发现部分消息出错，可能是什么导致的，该怎么处理？

     请各位专家帮我分析分析，不胜感激！

您好！ 

        最近调试进一步发现，8核同时给自己发消息或者会出现部分消息不准确，同时伴随着PDSP写到List Address里的描述符地址不准确。

   而同时我只要把8核发消息之前同步的代码(同步之后让8核同时给自己发消息)去掉后，就不会出现上述现象，或者8核同时给某一个核发消息

   也不会出现上述情况，请问这是什么导致的？

       1. 8核能不能同时给自己发消息，比如8个核上能不能同时产生4号中断并响应？

       2. 如果我不想使用PDSP来产生中断，能不能自己手动触发50事件产生4号中断？具体该怎么做,有没有参考的例子？

     谢谢！