How to recover from a crash
Posted 04 February 2009 - 02:00 PM
I use a LabJack U3-LV in my application to stream some data. Since my application is in developpement, it
sometimes crash in the middle of a manipulation.
For some reason, I get the following problem: if I open the U3 port, then read the calibration information and
crash, I am unable to read the calibration again (when I relaunch my application) until I unplug the and replug the U3.
This is an issue for me as the U3 connection might not be easy to access on my system.
I am using the Mac OSX driver. I can reproduce with this test application (See end of post). Run it once and it crashes. Run it again and it
just hangs forever. Is there a way to force a reset to the U3? Or is there a time out to which the read method can return?
int main(int argc, char **argv)
//Opening first found U3 over USB
HANDLE hDevice = LJUSB_OpenDevice(1, 0, U3_PRODUCT_ID);
int success = (hDevice != NULL);
printf("Open USB: %d\n", success);
//Getting calibration information from U3
uint8 cU3SendBuffer, cU3RecBuffer;
int sentRec = 0;
int i = 0;
/* sending ConfigU3 command to get hardware version and see if HV */
cU3SendBuffer = (uint8)(0xF8); //command byte
cU3SendBuffer = (uint8)(0x0A); //number of data words
cU3SendBuffer = (uint8)(0x08); //extended command number
//setting WriteMask0 and all other bytes to 0 since we only want to read the response
for(i = 6; i < 26; i++)
cU3SendBuffer[i] = 0;
sentRec = LJUSB_BulkWrite(hDevice, U3_PIPE_EP1_OUT, cU3SendBuffer, 26);
sentRec = LJUSB_BulkRead(hDevice, U3_PIPE_EP1_IN, cU3RecBuffer, 38);
// Force crash
int* ptr = 0;
*ptr = 123;
Posted 04 February 2009 - 07:16 PM
Posted 05 February 2009 - 10:51 AM
There is no timeout for the read in the current driver, though in the next release I will add one. To stop the read you can disconnect your device as you know already, or perform the LJUSB_AbortPipe call on pipe U3_PIPE_EP1_IN/U3_PIPE_EP2_IN in a different thread.
Through our driver the only way to reset our device is through low-level commands. You may be able to re-enumerate the U3, which would reset the device, through the USB host. This would be an operating system operation, so if you want try this you will need to search online to see if this is possible on the Mac and how to do it.
would you know by any chance when the next release is planned?
Posted 05 February 2009 - 03:09 PM
Posted 12 April 2012 - 01:19 PM
Posted 13 April 2012 - 02:16 PM
A LJUSB_AbortPipe type command is not needed as it was meant to abort a stalled read. The timeout takes care of this now, and you have the option to set a specific timeout time. If you do want to try toying around with the libusb API it is documented here:
I did notice that the Exodriver on Linux, which has the same source code for Mac OS X, does not have this issue after a crash. It seems to be either a libusb and Mac OS X, or Mac OS X operating system USB layer issue. I'll check into this further and see if there is something we can do in the Exodriver to prevent this issue. I will point out though that if your program crashes in the middle of a command/response, you will need the dummy write/reads to resolve the issue in software, or a power cycle.
Posted 05 September 2013 - 11:22 AM
I'm revisiting this again... :)
The dummy read works, but now I have another problem.
To recap: I start streaming and all is well, then my process crashes, then I relaunch it, then I try to connect to the device, it times out, so I do a ConfigU3 again ("dummy read"), and I get back all the expected values. Then I do my usual sequence: ReadCal, StreamStop, Feedback, StreamConfig, StreamStart. I've checked all the returned values and everything is as expected. Streaming starts, but the samples seem to be all garbage (or maybe there is a pattern that I have yet to discern).
One thing I noticed: when everything's working properly, after starting streaming, the first streaming sample I receive has a 'PacketCounter' field value of 0, which makes sense as it's the first sample. However, when things aren't working, and I get the garbage samples, the first one has a 'PacketCounter' field value of 1 instead of 0. So I wonder if everything is 'shifted' somehow…
Should the first 'PacketCounter' always be 0 after starting streaming?
Posted 05 September 2013 - 12:19 PM
Try upgrading your U3 firmware to the latest and see if that helps:
Looking through the firmware history, a while ago there was a fix for an issue that was corrupting Stream data channels. I'm not sure if this is the issue you are seeing.
As for the PacketCounter, it should always start at 0 after starting a new stream.
Posted 06 September 2013 - 09:15 AM
I can reproduce this with the newest firmware (1.46) and also with 1.32 and 1.04, and with two different devices.
Thanks for confirming that PacketCounter should always start at 0. As it doesn't, does it seem I've found a firmware bug? I would be great if you could try to reproduce this on your end, how can I help? I've added logs everywhere I call LJUSB_* functions so you can see exactly what I'm sending receiving:
When things work fine (first line is sent, second line is received):
Posted 06 September 2013 - 03:53 PM
Doing some tests on both a Mac OS X and Linux machine, it looks like this occurs when a StreamData packet is partially read and then the stream is restarted. A crash is not necessary to reproduce the problem, and your crash is most likely interrupting a StreamData read.
If you run into the problem of the packet counter starting at 1 after a crash, in your program you can account for this by calling StreamStop to stop the current stream and then StreamStart to start a new stream. This should start your new stream with a correct PacketCounter starting at 0. I'll check if this is something that can be fixed in firmware.
Posted 09 September 2013 - 03:34 PM
Great, thanks for looking into this so promptly. I think what I'll do is always do a dummy LJUSB_Stream() after starting streaming mode, then stop streaming mode, then start it again. A quick test here suggests that 'fixes' the problem. Does that seem reasonable?
Posted 11 September 2013 - 03:02 PM
Sounds reasonable. Alternatively, you can also detect the error if the first PacketCounter is not 0 after StreamStart and restart when needed.
Posted 10 January 2014 - 12:01 PM
As it's been a few months, I just wanted to ping this issue… Any news on a firmware fix for this?
Posted 10 January 2014 - 12:44 PM
Sorry for not updating on the firmware side. The current suggested solution is through software like we mentioned a couple of posts ago. Firmware wise we have this on our list of things to look into but have no timeline on when that will be as we are focusing on T7 development at the moment.
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users