The sequence of a scan/probe (which exchanges exactly one request and
response pair) before an acquisition (which requests another response,
then keeps re-requesting periodically) resulted in the transmission of
more requests shortly after a request was sent and before any response
started receiving at all. Which then resulted in unexpected lengths and
failed consistency checks for the receive data. This condition stuck
because rdtech-tc does not support the re-synchronization to the input
stream as rdtech-um does.
Defer transmission of requests until after receive data was seen (or
an acquisition start forces their transmission). Tested by repeatedly
running:
$ sigrok-cli -d rdtech-tc:conn=bt/dialog/$MAC --continuous
/*
* Don't send the request while receive data is being accumulated.
+ * Defer request transmission when a previous request has not yet
+ * seen any response data at all (more probable to happen shortly
+ * after connecting to the peripheral).
*/
devc = sdi->priv;
- if (!force && devc->rdlen)
- return SR_OK;
+ if (!force) {
+ if (devc->rdlen)
+ return SR_OK;
+ if (!devc->rx_after_tx)
+ return SR_OK;
+ }
/*
* Send the request when the transmit interval was reached. Or
return SR_ERR;
}
devc->cmd_sent_at = now;
+ devc->rx_after_tx = 0;
return SR_OK;
}
if (len == 0)
return SR_OK;
devc->rdlen += len;
+ devc->rx_after_tx += len;
}
/*
uint8_t buf[RDTECH_TC_RSPBUFSIZE];
size_t rdlen;
int64_t cmd_sent_at;
+ size_t rx_after_tx;
};
SR_PRIV int rdtech_tc_probe(struct sr_serial_dev_inst *serial, struct dev_context *devc);