search

vedderb / bldc

The VESC motor control firmware
2.14k stars 1.34k forks source link

COM_GET_VALUES truncates at 67th byte; thus excludes CRC and stop byte #93

Closed gitcnd closed 5 years ago

gitcnd commented 5 years ago

I have a suspicion that #63 is still a problem, but it's on the sending side, not the receiver - dumping out the raw bytes using an interrupt (so no buffers fill up on my side) the last 3 bytes are missing.

Assuming something in the firmware is limited to a ~ 64 byte buffer, this might indicate some internal corruption could be taking place too?

I recommend that COMM_GET_VALUES excludes some of the "less necessary" values (ie. set the default mask to something less than 0xFFFFFFFF ), so that the total packet length, including start+len and crc+end is 64 bytes or less. If anyone wants all the values, they can make 2 different calls to COMM_GET_VALUES_SELECTIVE

Alternatively - finding where big packets are getting corrupted might be useful - that's probably going to cause other problems elsewhere too.

My baud rate is 250000, not 115200, in case that's a clue/hint?

gitcnd commented 5 years ago

p.s. I traced the bldc source all the way to system function calls, and didn't see the problem - so if it really is a problem an the vesc side and not my side, it's someplace inside the OS buffering code I guess. I'm using hardware 410.

vedderb commented 5 years ago

This is working over both USB and UART with the NRF5x chips, even with the 400+ bytes mc_configuration. I haven't tested with a higher baud rate though, and will give it a try.

vedderb commented 5 years ago

I just gave it a try with a CP2102 USB-to-UART adapter, and 250000 works fine. 460800 also works perfectly, but 921600 is a bit unreliable.

Can you give it a try with a USB-to-UART adapter?

gitcnd commented 5 years ago

Thanks heaps for checking this (and sorry I wasted your time!!) - looks like the Arduino "serialEvent()" function is not really an event, but an end-of-loop-poll, so I expect the fault is on my side after all! At least this mistake found another bug that's now fixed though, right?

FYI - I'm building an open-source full-feature remote and motor-orchestrating-controller with emphasis on safety, so skate-board-riders (and others) in future can save battery by "phasing out" unused motors under light load, and not experience cut-outs or brake failures on low-battery or other faults, etc...

vedderb commented 5 years ago

No problem, and as you said it is good that you found the other bug which is fixed now :-)