I am developing an android (Android 4.2) project in which I read data from devices connected through usb. On the connected sensor board I have an FTDI chipset, so I am using their d2xx drivers.
Everything works fine to begin with: I am able to acquire data through the usb connection and do my processing. I do this in a loop running in and AsyncTask in which I write an acquisition command to the sensor board to tell it to acquire data. Once all data has been received, it is processed. Then the acquisition command is written again to the sensor board and new data is acquired and processed.
However after a while (it does not seem to be a fixed time) the device is unable to read any other data from the sensor board. Note that the sensor board is not at fault here, because I have been able to thoroughly test it using a program doing the same processing but running on my laptop.
If I go to check in the DDMS logs I always find, right when my application becomes unable to receive data, the following debug messages:
Tag: extractReadData::
Text: written != totalData, written= 16384 totalData=196
(the numbers in the text are not always the same). And
Tag: ProcessBulkIn::
Text Buffer is full, waiting for read....
After those messages, besides seeing logs a couple of processing threads that end, the only Log I get (repeatedly and until I stop the application) is:
Tag: UsbRequestJNI
Text: init
During normal operation I receive Log messages from the different parts of my application (acquisition, data processing and so on), but these do not appear anymore once I get those messages i reported.
I know that the log message tagged UsbRequestJNI appears during normal operations when I communicate through the USB connection, specifically when I perform a write command (sending to the sensor board the command to acquire and send some data). So it would appear that after receiving those two messages my application is stuck attempting to write to the sensor board.
I don't know where those other two messages come from. My best guess is that they come from either the d2xx FTDI driver or from some underlying USB host library.
Can anyone help me understand:
Thanks a lot to anyone that can pitch in.
Best, Matteo
I later found out (by discussing this with the support team at FTDI) that the issues I was facing were caused by bugs in the FTDI drivers for Android. Something about locks in their threads.
As of today (October 22nd, 2014) these bugs have not been solved yet. Moreover, similar bugs affect the Windows CE7 ARM version of the drivers.