Brought up the firmware on the second USBTMC gadget. Ran a test script. Got an oopsie.
Looked like a buffer overrun, except that I was putting 53 bytes into a 512-byte buffer, so nope.
Then... it looked like a channel list with 32 characters between the parentheses might be the culprit. This made no sense whatsoever, given that the channel-list parser runs entirely on the fly, without maintaining any buffers of its own.
Moving extra whitespace around, I eventually figure out that the problem was a command line longer than 52 characters. Um...
That's right about a 64-byte packet minus a 12-byte header. And the gibberish that came after looked remarkably like the headers of following packets. A quick capture with the USB Beagle confirmed this.
So, some issue with my implementation of USB_DeviceTmcBulkOut, and the logic for determining when EOM has been processed and we should be looking for a new header.
I'll do some further tracking after dinner. Tomorrow should bring Real Work, as in for a paying client, so the gadget project will have to return to the back burner.
Update: Derrrrrr. This was a case I hadn't tested before, because the first gadget doesn't take any lengthy commands (unless one pads a command with extra whitespace, which I hadn't thought to do).
I'd tested multi-packet messages coming back from the gadget; *IDN? exercises that one nicely. I hadn't tested multi-packet messages going to the gadget.
And, surprise surprise, I'd neglected to update a byte counter, so the first message with a continuation packet (which is to say, message length exceeding 52 bytes) broke the logic.
I keep thinking that before any of this goes to production I should restructure the whole SCPI-parsing subsystem to suck directly from the input stream instead of buffering a command line. That'll be important when I start building things to which the PC will send waveforms (or other large data blobs).
Comments