我使用网口发送数据,core从2049号FDQ中弹出descriptor,之后发送并被回收。大部分时间可以正常运行。但是偶尔会发生以下错误:
在core从FDQ弹出descriptor的时候显示错误:
报错信息为Source queue 2049 descriptor is NULL,但是FDQ中的descriptor数量并不是0而是满的。
这种情况虽然并不是每次都会出现,但是影响了程序的稳定性,请问为什么会出现这种情况呢,是dsp的硬件原因吗?
This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
我使用网口发送数据,core从2049号FDQ中弹出descriptor,之后发送并被回收。大部分时间可以正常运行。但是偶尔会发生以下错误:
在core从FDQ弹出descriptor的时候显示错误:
报错信息为Source queue 2049 descriptor is NULL,但是FDQ中的descriptor数量并不是0而是满的。
这种情况虽然并不是每次都会出现,但是影响了程序的稳定性,请问为什么会出现这种情况呢,是dsp的硬件原因吗?
描述符数量应该没有问题,而且我只用一个core来操作FDQ,所以每个描述符应该不会重复使用。
请问有没有可能是:
我用的是网口发送数据给PC,没用TCPIP协议,每个包的大小为1024byte,包比较大,上位机接受时有时buffer满了,所以通知dsp延迟发送,所以dsp的pktdma没有及时的将descriptor返回到FDQ中,导致core0再次从FDQ弹取的时候出现descriptor数量为0的情况,程序中如果出现NULL的情况会随记进入对FDQ检查的函数中,但是因为进入函数需要时间,在这段时间pktdma正好又将descriptor返回了,所以检查得到FDQ中描述符数量又是满的。
就是这样一个时间差导致了pop出现错误。
程序运行几个小时都没有问题,所以我觉得应该不会是DSP软件上面的问题,所以怀疑是上位机通信时导致的这种不确定的现象。