go-serial

go-serial copied to clipboard

I'm using bugst/go-serial to send data from my computer to a embedded system. My current application uses some buffering and C-libraries to handle the data (framing) so I have to use the Write call byte-by-byte.

This results in very fast subsequent calls to .Write. While this was not a problem for a small amount of data on larger amounts (100+ Bytes) the write call produces invalid data:

• I am verifying that the data I pass to port.Write is indeed what I want to send (logging it)
• I am checking the return values of port.Write - no issues there
• the serial port does produce the correct number of bytes but the content is not correct (some 22 bytes have the wrong content)

a snippet of my function-call:

func goSerialTx(data C.uint8_t) int {
	byteData := byte(data)
	fmt.Printf(" 0x%02X\n", byteData)

	if Wire().serialPort == nil {
		return 1
	}

	// time.Sleep(1 * time.Millisecond)

	n, err := Wire().serialPort.Write([]byte{byteData})
	if (err != nil) || (n == 0) {
		log.Warning("call to serialPort.Write failed")
		return 1
	}
	// fmt.Println("n bytes written ", n)
	return 0
}

Here Wire().serialPort simply returns a reference to the singleton (port). I've tried lowering the baudrate but the problem is not on the wire: I am using a logic analyzer to check the logged data against what's really on the wire to make sure it's not the embedded device that's not working.

I've tried adding a time.Sleep call > this would resolve the issue (data is transferred correctly) but would cripple the communication.

Any ideas? Thanks!

happening on MacOS, additional information on stackoverflow

It may be a problem on the implementation of CDC-USB Stack of your target board, are you on the latest version of your SDK?

while i did monitor both UART connections (PC > board, board > PC) this only occurred in the direction PC > board, which is why i assumed that it must be on the PC side.

do you think that a bad USB stack on the target board can mess up the data on the PC > board UART line? what i mean is: the PC is supposed to operate the TX line, not the board. could the target board actually corrupt the data on this TX line?

this would explain why the number of bytes is correct but the content isn't. sadly right now i only have this board to verify the implementation, but i'll definitely try it with another target once i get my hands on one. this one is a preview-devkit (nRF52840 preview), the chip is an engineering sample so it might have some issues still.

If the board is this one https://www.nordicsemi.com/eng/Products/nRF52840-Preview-DK the USB connector goes directly to the SAM3U microcontroller, it probably runs an USB-stack that performs USB2Serial convertion. IMHO the odds are very high that problem is in that firmware.

BTW it's not the first time someone reports transmission errors, unfortunately I've been never able to reproduce the error. Let's keep this open for a while and see if Nordic release an update.

it is this one yes - issue might really be the conversion ...

happy to keep it open - should have a different MCU with a plain UART soon, will use a FTDI cable there which should not have those issues. will keep you posted!