Seems good to me ^^

I raised the number of bytes to wait for a bit more.

Why wait for the max size of a VPI command, not min size? (in the end the whole code is a bit sketchy since we might only have received half of a command until now, but that's not your fault)

Why wait for the max size of a VPI command, not min size?

Is there a minimum size? I was looking at that code and the corresponding JTAG VPI code I found around the net as well (OpenOCD, other projects that use VPI, etc.). Exactly because of the name MaxSize.... And as far as I can tell, each package consists of the full size. And the code following that also always loads the full size (readFully will always wait for enough data to fill the entire buffer array... which is sized at MaxSizeOfVpiCmd bytes).

You are right, misremembered the code when the last review, sry

What if openocd send less than MaxSizeOfVpiCmd ? seems it is a dead lock.

          while(inputStream.available() < MaxSizeOfVpiCmd) {
            sleep(jtagClkPeriod * 200)
          }

Seems like the whole implementation (include before this patch) assume that once there is something in inputStream, there is enough for a whole packet. Meaning the following would be fine :

          while(inputStream.available() > 0) {
            sleep(jtagClkPeriod * 200)
          }

?

@Dolu1990 "max size" is a bit of a misnomer it seems - from what I can tell (and what @rpls posted above) all VPI commands have the same length.
Since it's a TCP stream you can't rely on all bytes arriving at the same time, so there is a need to check for > MaxSizeOfVpiCmd

Ahhh ok ^^

Thanks !