Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Capture hangs for some situations #81

Closed
jawi opened this Issue · 6 comments

2 participants

@jawi
Owner

From http://dangerousprototypes.com/forum/viewtopic.php?f=57&t=1198&p=31003:

Channel Groups Capture OK?


0 yes
1 yes
2 yes
3 yes
0, 1 no, upload hangs
0, 1, 2 no, upload hangs
0, 1, 2, 3 yes

It appears there's a off-by-one bug in the reading routines of the logic sniffer acquisition task. See also the detailed information in this topic: http://dangerousprototypes.com/forum/viewtopic.php?f=57&t=1198&p=31003#p31003.

@PataMat
Collaborator

I think the bug is in the file 'LogicSnifferAcquisitionTask.java' in the function 'readSample':

This line
read = this.inputStream.read( buf, offset, enabledGroupCount);
should be
read = this.inputStream.read( buf, offset, enabledGroupCount - offset);

Dependent on the CPU-speed one call of 'this.inputStream.read(...)' returns sometimes only a few data for all groups. So the loop must repeat again and now the function have to read only the rest of 'enabledGroupCount'.

@jawi
Owner

That, indeed, might be the underlying cause for this problem. I've to give this a test, or did you test it already, accidentally?

@PataMat
Collaborator

Yes, I've tested it. For me, it seems to work. But I have other problems with data transmission. Presumably this is due to the XON-XOFF protocol. Depending on the hardware (device driver) I need to activate or deactivate the protocol. Otherwise also occurs a loss of data - regardless of the number of groups.

I think, the problem with the XON-XOFF protocol is that the XON and XOFF code is not allowed to be present in the data stream. These codes must be replaced before and after transmission by an ESC sequence (byte stuffing).

@jawi jawi referenced this issue from a commit
@jawi Fixed(?) issue #81: in some situations the device acquisition keeps w…
…aiting for an indefinite amount of time. Problem is due to the incorrect reading of bytes from the stream.
d9099f3
@jawi
Owner

@PataMat: I don't know where your problems with flow-control come from. Which hardware are you referring to? I know the OLS hardware ignores/doesn't use the flow control characters...

@PataMat
Collaborator

@jawi: My own design is based on Jonas Diemer's Spartan 3E SUMP port with RLE support. As Hardware I use the Digilent Spartan 3E eval board and a LatticeXP2 Brevia development kit. The flow-control on the FPGA side is always enabled.

At home at my old Notebook and a newer Netbook I have to use the flow-control by software - otherwise data loss happens. I think, the PCs are too slow to handle 115200 / 230400 bit/s.

On my work I have a new and very fast PC - but there I must not use the flow-control by software - otherwise data loss happens. I think, the RS232 device driver 'eats' the received XON-/XOFF-characters if the flow-control is enabled. If I find time this week, I konvert in the FPGA the XON-/XOFF-characters into others characters before transmission and see what happens.

@jawi
Owner

@PataMat: if the problem regarding flow-control persists, could you open a new issue for it, so we can nail it down once and for all?

@jawi jawi closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.