Problems with ADCREAD in external script

Hi Colin!

I am trying to perform an acquisition from outside the Chipwhisperer Capture software.

To do this , I send serial commands to Chipwhisperer through a standalone script based on cwCapture sw. Every read/write command to different addresses work fine except for ADDR_ADCDATA which throws the error “usb_reap: reaping request failed, win error: a device attached to the system is not functioning”

This happens whether i use python (importing usb, same as cwCapture sw) or Java (importing libusbjava). I am simply replicating your commands which are …
a) To trigger immediately, I raise ‘trigger now’ bit high, then mask the trigger now bit
b) Read how many bytes in the ADC fifo (~130K Bytes)
c) Read that number of bytes +1 from ADDR_ADCDATA

I am rather puzzled as the same trigger forced process works fine in cwCapture SW with the same parameters.

Do you have any hints as to why this is happening? Am i missing some integral part of the setup? (My setup process involves resetting the settings register, set the number of samples, set the advclk register and ensure it is locked, set the trigger registers)

Hmm… can you send me your python script? I’ve got a USB analyzer here which makes troubleshooting those problems a lot easier - can see what stage it got to before having issues! If it’s easier just email to me, or try adding as an attachment here.

I experienced the “usb_reap” error during my rewrite of the OpenADC code in python.
(The rewrite is to gain a better understanding of what was going on).
When this occurred I had to do a physical unplug/replug to get the device working again.

In my case it came down to setting the “trigger presamples” value. I forget what I did to fix it (if indeed I did), but I found an email to Colin about it at the time, so it may provide clues for you. (I trust that Colin won’t mind me sharing his reply to help others):

My Email:
"
I came across an issue where if you set a trigger presamples amount and then attempt to flush the adc sample data it will put the device into an unresponsive state where it needs to be unplugged and replugged again to work. So some kind of crash I guess.

When testing I am setting the pre-sample amount to 123 at a high level (so it is then divided by 3 and has 24 added to it at a low level before sending to the device.)

So at a low level it writes the 32bit value 39 00 00 00 as the presample amount.

When flushing the adc sample data it attempts to do a read of 65000 (0xFDE8) bytes of data.
This is a weird value to use, but it works fine without crashing as long as you haven’t set a pre-sample amount.

As a fix I tried first checking the amount of data in the fifo and only reading that amount out, but that also causes a crash.
"

Colin’s response:
"
Hmm – I’ve seen that as well before. My work-around was I think to only use a higher pre-sample level.

It’s a bit of a side-effect of the kludgey pre-sample code in the FPGA. Will need to look into that more specifically…
"

Thanks Colin and Cipherstream for your replies. After investigating Colin’s code more carefully, I discovered my mistake.

What happened was:
a) I was only trying to capture an acquisition by forcing a trigger. So the flow of code was like this:
- setup cw by writing to the relevant registers
- arm and force trigger
- read from bytesToRx and ADDR_ADCDATA registers (without checking the status register for ARM or FIFO status)
- *USB error occurs

b) If i use the while loop from the capture() function in openadc.py (re-pasted below), i capture correctly, even though the reported bytesToRx is identical to the situation described above. Perhaps the error comes from reading from the fifo prematurely.

while ((status & STATUS_ARM_MASK) == STATUS_ARM_MASK) | ((status & STATUS_FIFO_MASK) == 0):
    status = self.getStatus()
    time.sleep(0.05)

    diff = datetime.datetime.now() - starttime

    if (diff.total_seconds() > self._timeout):
        self.log("Timeout in OpenADC capture(), trigger FORCED")
        timeout = True
        self.triggerNow()

Glad you found the error! And of course @cipherstream yes please post anything useful :wink:

The whole USB data dump is a little dangerous as you can see. Some of this comes back to backwards-compatibility with the original version (which I’ve tried to still support for now) that uses a serial-port, and I tried to dump the FIFO as fast as possible. I’ve designed a new USB interface firmware which should be more reliable in this regard without killing backwards compatibility, but it uses a different USB chip (Atmel) which requires different hardware setup.