Hi everyone,
I'am using MSDK 2.1.2.6, custom board with C6670 processor.
This post is related to my previous one. 
My gues is that I'am having problems with Packet accelerator setup. If we go back and look into pdk_C6670_1_1_2_6\packages\ti\drv\pa\example\emacExample\ cppi_qmss_mgmt.c file, we can find a CycleDelay (10000) line (#753) in the SendPacket() function. What does that delay stends for? I know that comment said "Give PA some time", but what exactly is PA doing at this time? How does PA determine the type of CRC polynom he supoosed to use if none was specified during setup?
The reason I'am asking is following: If I will remove completely this delay and DSP will keep pushing packets one by one the PA starting to generate wrong CRC. You can find screenshot 1.tif from Wireshark. Packet numer 2 is a comand from Host application to DSP (CRC generated by network card so it's the case of CRC offload). 3rd packet is a response from DSP. Due to it's small length Everything is fine. But strating from packet number 7 when DSP transmitting large data packets the PA generating wrong CRC and this packets discarded by the Host application. The last one 22 packet has a correct generated CRC, as I see it bacause PA was not interrupted some time by the DSP and has enough time, like in the case of Delay.
After this I have increased Delay to CycleDelay (8000), but still not 10000 as it was before. The result you can find on the Screenshot 2.tif. In that case wrong CRC calculation apper randomly. It could fail on 74th big packet, or it can be on 200 packet. Everytime before pushing packet into PA queue, I'am checking Qmss_getQueueEntryCount(gvTxQ[8]) for 644 queue and number of entry count is always 0, so no packets truncated in the queue.
So as i understand the PA should be a pipeline device and if it can handle taking out packets out of queue is should handle the CRC calculation properly. Any idea for the reason of such behavior?
Best regards,
Pavlo!