This change needs to be made because TCP never guarantees boundaries within the byte stream, and the FPGA cannot expect them.

But it is peculiar that the actors-ics VM is sending more such data than we saw at CIT or ASRD. One non-disruptive example is both repeatable and peculiar. When sending back-to-back HK commands for all 84 boards, in the second such command set the 43rd board request packet is split into a 6- and a 2-byte packet. This is after 641*N packets and more interestingly, when crossing the N*1024 per-stream TCP sequence number. Odd, but that did repeat three times.

I can check, but it may well be that these (legal and OK) TCP fragmentations always happen at the 1024*N boundaries, but that the INSTRM-907 work fixed them in nearly all cases. Some quirk about how we are commanding the cobras causes more headers to be fragmented.

I'll play with the VM OS sysctl knobs to see if I can perturb things. And can imagine a peephole on the FPGA command stream to insert dummy commands over the 1024*N byte boundaries.

Bump.

The last move in /data/MCS/20230722_009 ended with an FPGA ERROR 10. This is an error which I added when doing the INSTRM-907 work, and which indicates that the command parser cannot get a full header. So I think this is the same problem.

Also, register error code 10 in the fpgaProtocol decoder as "EMPTY COMMAND HEADER"

Code changes pushed. Need to get access to a Kintex 705 online at Subaru to test, along with a USB-connected PC (Linux or Windows) running some reasonable version of the Vivado SDK (just the command-line SDK needed). See my notes at https://github.com/Subaru-PFS/ics_mps_fpga/blob/master/INSTALL.md

One of the spare KC705s has been connected to a Linux box in Hilo, and the new code uploaded (from a remote development system). I still need to run some tests just with that system.

Yoshida, Hiroshige will connect the us-mcs computer to the real FPGA USB port, so we can update that one in the same way.