0x55556666 padding in the middle of receiving a TLP? about pcileech-fpga

[andreiw]

More precisely, I was seeing 0x55556666 after reading the status word. I don't actually have proof of seeing 0x55556666 in the middle of a TLP.

[ufrisk]

the format is 1 status dword + 7 data dwords = 1 octa-dword. filler dwords (0x55556666) may appear outside the octa-dwords.

(they may appear inside the octa-dwords as well by chance if the actual data being read contains this byte pattern).

The filler dwords are there to deal with some quirks of the FT601 USB chip when aborting transfers early.

If you have issues with the filler-dwords appearing in the middle of your data-carrying octa-dwords please let me know, but I have not seen this behavior.

Regardless I hope this will clear up things a bit.

[andreiw]

So far I am seeing filler dwords occasionally after the status dword, which I suppose counts as "in the middle of the octa-word".

How to reproduce: generate a steady stream of CfgRd0 traffic from the host to the card.

[ufrisk]

That should never appear inside the octa-dwords. But it may appear "inside" the TLP under some circumstances.

If you spam the device with a lot of CfgRd messages while at the same time have it so that it's forwarded to the USB (i.e. no filter) and you don't drain any data from the USB (or don't do it fast enough) the internal buffers will fill up and new data from the FPGA will be discarded (sometimes in the middle of a TLP packet).