Bug 62 - Starting an acquisition after the first acqusition is stopped fails
Summary: Starting an acquisition after the first acqusition is stopped fails
Status: RESOLVED FIXED
Alias: None
Product: libsigrok
Classification: Unclassified
Component: Driver: fx2lafw (show other bugs)
Version: unreleased development snapshot
Hardware: All All
: Normal normal
Target Milestone: ---
Assignee: mrnuke
URL:
Keywords:
: 75 (view as bug list)
Depends on:
Blocks: 45
  Show dependency tree / graph
 
Reported: 2013-02-08 20:43 CET by mrnuke
Modified: 2013-04-30 00:15 CEST (History)
2 users (show)


Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description mrnuke 2013-02-08 20:43:33 CET 
Running successive acquisitions with fx2lafw devices fails more often than not.

1) With PulseView, select any fx2lafw device, 1G samples, 1MHz rate, then start acquisition. I used a MCU123 USBee AX Pro clone.
2) Either wait for acquisition to finish, or click Stop.
3) Now click Start.

Expected result:
A new acquisition starts, and data is plotted by Pulseview.

Actual result:
Acquisition fails to start, and the terminal outputs:

 sr: session: sr_session_start: could not start an acquisition (-1)
 Failed to start session. 
 sr: fx2lafw: Device failed to renumerate.
 sr: session: sr_session_dev_add: dev_open failed (-1)
 Failed to use device.
Comment 1 mrnuke 2013-02-08 20:44:43 CET 
acquisition
Comment 2 Joel Holdsworth 2013-03-23 10:58:20 CET 
+1 I've seen this also. It's an important problem.
Comment 3 Joel Holdsworth 2013-03-23 19:24:04 CET 
For the same test conditions I get the error:

sr: usb: Failed to get device descriptor: LIBUSB_ERROR_IO.
sr: session: sr_session_start: could not start an acquisition (-1)

Both with a Saleae Clone and an AX clone.
Comment 4 Joel Holdsworth 2013-03-31 19:22:15 CEST 
*** Bug 75 has been marked as a duplicate of this bug. ***
Comment 5 Joel Holdsworth 2013-04-28 09:17:28 CEST 
This bug can be surpressed by commenting

g_slist_free_full(session->devs, (GDestroyNotify)sr_dev_close);

in sr_session_dev_remove_all in session.c

In PulseView the sampling session lasts the length of the sampling thread: from when the user clicks run, to when the sampling is complete.

sr_dev_open and sr_dev_close are called by pulseview in pv::SigSession::set_device when the selected device changes, so no need to do it in sr_session_dev_remove_all.
Comment 6 Joel Holdsworth 2013-04-28 09:19:16 CEST 
The above fix fixes the current problems running a second session, but not if the user clicks "Stop"
Comment 7 Joel Holdsworth 2013-04-28 09:26:29 CEST 
When the user clicks Start -> Stop -> Start, sampling fails to start because devc->submitted_transfers != 0. For some reason, it seems not all the submitted transfers get released.
Comment 8 Bert Vermeulen 2013-04-28 23:46:07 CEST 
(In reply to comment #5)
> This bug can be surpressed by commenting
> 
> g_slist_free_full(session->devs, (GDestroyNotify)sr_dev_close);
> 
> in sr_session_dev_remove_all in session.c
> 
> In PulseView the sampling session lasts the length of the sampling thread:
> from when the user clicks run, to when the sampling is complete.
> 
> sr_dev_open and sr_dev_close are called by pulseview in
> pv::SigSession::set_device when the selected device changes, so no need to
> do it in sr_session_dev_remove_all.

Fixed in 681803d
Comment 9 Bert Vermeulen 2013-04-30 00:15:18 CEST 
(In reply to comment #6)
> The above fix fixes the current problems running a second session, but not
> if the user clicks "Stop"

Fixed in 037286445116d0f4f