Roboclaw not sending last byte

[JetForMe]

It seems I have two different Roboclaws that are both failing to send the last byte of a response when connected via USB. I can't seem to get packet serial working with a TTL connection, but it almost works with a USB connection.

I tried a loopback test of my code and I get back all the bytes I send, so I'm pretty sure my code is working correctly (app running on macOS).

When I run IonStudio in a Win 7 VM, it fails to see either Roboclaw.

My two Roboclaws are a 2x60 v3.1.5, and a 2x45A whose version I can't determine right now. Both exhibit the same behavior. Any suggestions? Thanks.

[Basicmicro Support]

Your firmware is years out of date which is why it doesnt have the return byte. If your units have USB connectors force them into bootloader mode(hold the mode button on power up) and conenct them to a PC(you will need to unstall the Windows USB driver), then use Ion Studio to update the firmware.

Using a VM may cause problems with USB devices but it could be you just dont have the driver installed.

[JetForMe]

Yup, that does seem to be the issue, thank you. I'm now receiving a 2-byte CRC at the end of the string. But it's not the CRC my code computes for the packet. I'm receiving sending:

Code: Select all

80 15 59 0c

and receiving:

Code: Select all

55 53 42 20 52 6f 62 6f 63 6c 61 77 20 32 78 34 35 61 20 76 34 2e 31 2e 32 33 0a 00 87 80

The CRC I compute for the first 28 bytes (i.e. not including the last two bytes) is

Code: Select all

0xb416

I use the same code to compute the CRC I send to Roboclaw, and it seems to be accepting what I send (above). Any chance you could check my math on that result? FWIW, here's the Swift code (it's going to look unusual if you're not used to Swift):

Code: Select all

	var
	validationCRC16: UInt16
	{
		let count = self.count
		let crc = self.withUnsafeBytes
		{ (inBytes: UnsafePointer<UInt8>) -> UInt16 in
			var crc: UInt16 = 0
			let nBytes: Int = count - 2
			for byte in 0 ..< nBytes
			{
				let b = UInt16(inBytes[byte])
				debugLog("CRC adding \(String(format: "0x%01x", b))")
				crc = crc ^ (b << 8)
				for _ in 0 ..< 8
				{
					if crc & 0x8000 != 0
					{
						crc = (crc << 1) ^ 0x1021
					}
					else
					{
						crc <<= 1
					}
				}
			}
			debugLog("Got CRC \(String(format: "0x%02x", crc))")
			return crc
		}

Thanks!

[Basicmicro Support]

Have you updated your firmware to the current release? If not please do so. We cant support the older firmware.

1. Ya, it looks wierd. I dont know swift though it looks like it has some aspects from VB.
2. On commands that return data you do not SEND a CRC checksum, just the address and command byte. So basically you are sending 2 garabage bytes the Roboclaw has to deal with now. Remove them from the command sent.
3. It looks like you are only calculating the CRC across the returned bytes. You have to include the two sent bytes as well(the 0x80 and 0x15). The Roboclaws CRC is there to check for errors in both the received address/command bytes as well as the data sent back.

[JetForMe]

Yes, I updated to the latest firmware, thanks for the bootloader instructions. This behavior was with that.

I didn't realize that only some requests sent to the controller needed the CRC. I see that now in the examples. That explains what I'm seeing. My test code now passes! Thank you!