Hello, I am having a communications issue between the simtrace2 firmware & simtrace2-tool. It appears that only the first invocation of simtrace2-tool after reset of the Atmel processor works. Subsequent invocations of simtrace2-tool fail (to be specific, the simtrace2 firmware never calls usb_refill_from_host() nor dispatch_received_msg() for the lost message, according to additional debugging I added). We have confirmed this behavior on a stock simtrace2 board and stock simtrace2 firmware.
As an experiment: With the Atmel processor in this state, I modified simtrace2-tool to send two commands back to back: a dummy message, followed by the real message. When I do this, the first dummy message is dropped, as described above, but the second is executed successfully! For some reason, you cannot get it to work by simply invoking simtrace2-tool twice at the shell— critically, you have to send both messages without closing and re-opening libusb in-between. The root cause is probably some kind of message framing or USB stack receive processing race condition in the simtrace2 firmware, relative to when the USB port is opened on the 2nd and subsequent times. Or, maybe some kind of race condition with usb_refill_from_host() that primes the receiver for another packet? Honestly, I’m not sure. Do you have any suggestions? Are you aware of this issue? Regards, James James Tavares Lead Software Engineer KVH Industries, Inc. 50 Enterprise Center | Middletown, RI 02842 Direct Tel: +1 401.845.2416 Tel: +1 401.847.3327 | Fax: +1 401.845.8149 [email protected]<mailto:[email protected]> http://www.kvh.com<http://www.kvh.com/>
