Is it possible to see more verbose error codes for USB to Serial converters?

[rolfk]

VISA error -1073807252 respective 0xBFFF006C means: VISA:  (Hex 0xBFFF006C) An overrun error occurred during transfer. A character was not read from the hardware before the next character arrived.

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z00000159y9SAA

So the error description would indicate that it is on the hardware side of things. Yet this error description may have to be taken with a grain of salt. Error codes is always a bit of a tricky thing. On one hand you want to have as detailed error information as possible, so you want to have different error codes for every possible error. Yet you can always argue that any of the numerous buffers overflowing is pretty much the same error and allocating new error codes is a serious administrative task as it needs to be reserved, added to all the various headers, documentations, and error handler libraries, etc. etc. So there is always the thing about wanting to have very specific errors but not wanting to allocate zig thousand error codes for every new variant.

Therefore it is tricky to insist that this error code is related to exactly one buffer only and might not have been reused for another buffer a little higher up the driver stack. Still the error talks about hardware buffer so lets assume it really means the hardware buffer.

Your CP2102 chip has according to the datasheet that Santhosh posted in an earlier post, 512 bytes of FIFO for each of the two directions. You want to use 921kBaud, which is roughly 92Kb of data per second, so your 512 byte buffer is filled in about 5ms. There is usually an interrupt indication when the buffer is half full so the driver has about 2.5ms max to start reading data or the FIFO is run over.

Yet there are extra complications, this chip is not directly connected to the PCI bus. Instead there is an USB bus in between with its own latency. USB2 has an inherent 1ms latency for non isochronous transfer modes. The interrupt from the FIFO needs to be transformed into an USB message, goes to the Windows USB host controller, gets serviced by the USB driver then handed to the serial driver which then sees that it needs to start reading data from chip. So it is not really a hardware interrupt that can trigger the CPU to activate the according device driver directly.

Your last information seems to indicate that there are other potential trouble. Windows with pending updates indeed can tend to get very sluggish in many ways. The electrical hardware influence from connecting an oscilloscope sounds kind of weird but I have seen even more esoteric things, so not going to claim it is impossible. One issue would be to check the cable thoroughly. I had recently a system that was acting weird. It was connected through some FTDI based USB-RS232 interface to the computer. Some of the commands were working others not. I could get basic identification functionality through the LabVIEW driver, but the manufacturers own software couldn't even detect the connected device itself. When checking the cable it appeared that the Tx and Rx lines were connected, but the ground cable was not soldered onto the connector at all. So the Tx and Rx lines were basically floating against an undefined reference voltage. Some simple commands seemed to work but more complex commands with more data bytes were simply getting garbled and caused communication errors.

[BertMcMahan]

Thanks for the additional info! You basically called it, I couldn't say for certain where in the chain the error was, so hence the title "How do I get more detailed error codes" 🙂

I wish there was a way to ask VISA for more info on the error. I know the system is fast and must respond quickly, so figuring out exactly where the issue was occurring (RS232 layer, USB layer, OS layer, VISA layer, LabVIEW layer, etc) was going to be an annoying "trial and error" process.

Sounds like you've had some "fun" grounding issues as well. My system has been running with virtually no flaws for years, but apparently they only want to start showing up after many seconds of running.

I'm also not ruling out hardware issues at this point- maybe a connector has started to oxidize, or my serial converter is going bad, or an optoisolator on the board is giving up, etc.

We're getting ready to make our next generation of our serial converters. Hopefully I can find a chip with a larger buffer on it to reduce the potential for these errors and get it to our electronics team to implement.

Thanks again for your detailed posts. I really appreciate your time.