Hello Ti Folks,
I think I have found a possible bug in how PKTDMA seems to be working.
Here is a summary of what I am trying to do. I have 80 bytes packets (not including all the headers Eth/IP/UDP etc) coming into an EVM via Ethernet and the PA and stored in DDR3. I then copy them on the core's L2 memory . An object instance then takes that input and packages them in a buffer which is in L2) which is then passed on to a second object at a given time interval. This second object copies the data in the buffer passed amongst the objects into its local buffer. This local buffer is originally in DDR3 but the problem still happens if it is in L2. Then when the second object is ready to send out the packet, it pops a descriptor of the free Tx queue and pushes the descriptor to the switch to send out through Ethernet. I repeat this process for two other channels so in total I have 3 channels operating simultaneously sending packets out in a purely loopback mode so the data portion of the incoming packets suitably delayed through the system should match the data portion of the outgoing packets. What I find is that when I just have a snigle channel running, I do not see any data corruption. However as I go to 3 channels, I see smoe corruption.
To investigate further, I produced canned messages such that each channel has an incoming 80 byte packet that is different from the other channels so for example channel 1 may use char values 0xff, 0xfc, 0xf8 etc but channel 2 may only use 0xfe, 0xfb, 0xf7 and so on. Then I fed that the canned messages as input for each of the channels. I then compared the buffer passed between objects for channel 1 against the expected input of channel 1 and repeated for the other channels and setup a breakpoint to be triggered if their was any difference. I found none. I then repeated this step for the local buffer being used by the object that will be sending the packets and found again that the data in the buffer, before popping a descriptor and pushing to send out, matched the channel expected input. I then looked at the output and I was observing that occasionally I was seeing data from other channels in the expected channel data so it would point to some cross coupling happening in the PKTDMA engine.
I then set up the queue to push the pkts back to the core 0 using the infrstructure pktdma so that it would be received by the same core and I could compare the actual output received packet with the expected packet. I made use of the psinfo words to send info about the descriptor and buffer used in the TX process so that when I received the packet I could check the tx buffers or descriptors had been corrupted and they do not seem to be. This seems to point to some internal software error within the PKTDMA drivers that is causing this coupling or worse still some issue in silicon in the PKTDMA hardware blocks.
I have tried looking at the Errata for the chip as well as the PA LLD and CPPI lld in particular and I do not see anything glaring. I am using cppi lld 1.0.1.5 and PA lld c6678_1_0_0_19 and mcsdk 2_00_07_19. The EVM is using rev 1.0 of the silicon I believe.
This is a critical issue for us to resolve and am looking forward to TI's assistance in this regards.
Thanks, Aamir