• 0
Jonas

AD2: ERC: 0x2 with Raspberry Pi 4

Question

Hi,

I'm using the Analog Discovery 2 with a Raspberry Pi 4 with the WaveForms Beta 3.13.12 to continously log the Scope. After some time I get the ERC: 0x2 (see screenshot for error and used setup). I've tried with and without external powering of the AD2. The AD2 is plugged to the USB3.0 port of the RPi4. Also tried different Micro USB cables.

Do you have any idea how to fix this?

grafik.thumb.png.07edc6b7c7b3d736a130bf9a1a888142.png

Share this post


Link to post
Share on other sites

24 answers to this question

Recommended Posts

  • 0

Yes, I have seen that thread. But I need high rate sampling. What other solutions exist? Could there maybe the option to supress the error and resume operation after a USB packet is lost?

Share this post


Link to post
Share on other sites
  • 0

Hi @Jonas

There is no reconnect in the software, yet.
You could do such reconnect with custom application or script using WF SDK.

Share this post


Link to post
Share on other sites
  • 0

Hi @attila,

when do you plan to add this feature?

How can I do it using the scripts in WaveForms? I want to use the WaveForms GUI for the logging for easier use (setting the parameters etc.)...

Share this post


Link to post
Share on other sites
  • 0

Hi @Jonas

I'm working on it now...
It takes time to reproduce the issue. I have to test what level or reset/reconnect needs to be performed to recover.

Share this post


Link to post
Share on other sites
  • 0

Hi @attila,

that sounds amazing! Would it help to have my workspace? With my settings I get the error quite quickly (between 200-6000 samples)...

Share this post


Link to post
Share on other sites
  • 0

Hi @Jonas

I managed to reproduce once after several 100K captures, but the first simple reconnect solution didn't help. 
Now it is running again, waiting for failure with another way of reconnect method.

Share this post


Link to post
Share on other sites
  • 0

Hi @Jonas

The RPI SD card I used got damaged.
I have flashed another card with the latest Raspbian image the error occurred first after a half day then after more than a day, after 8M captures...
Unfortunately the 2nd and 3rd automatic reconnect methods didn't work.
Now I will try Ubuntu 20 32bit.

image.thumb.png.c081593f01ee46abbb4951a1d5c53658.png

Share this post


Link to post
Share on other sites
  • 0

Hi @Jonas

I've tried with TDMS export, that is when the SD card got damaged.
I can reproduce the communication failure. Unfortunately the automatic reconnect to the device does not help, there is no system error logged.

At this point I have no idea what else to try.
It may be a minimum required time for reconnect to work. I will try other solution as comes in mind but testing it will take again days.

Sorry but it is an issue between FTDI and RaspberryPI-4. The RPI1-2-3 are unusable and we have no control in these.
With other single board computer there is no such problem noticed or reported.

Share this post


Link to post
Share on other sites
  • 0

Hi @attila,

mmh, ok, seems to be tricky. How many samples can you do with the TDMS export? At the end I would be happy with 30min sampling at a time...

What other single board computers do you know to work well with the AD2?

Thanks!

Share this post


Link to post
Share on other sites
  • 0

I've now tried it on a ThinkPad L380 with ubuntu 16.04 LTS 64 bit with WaveForms 3.12 64bit. I also get the 0x02 error there.

IMG_20200604_112118.jpg

Share this post


Link to post
Share on other sites
  • 0

Error code 0x2 means the transfer was cancelled due to timeout. It would be helpful to understand how large the DptIO calls by Waveforms are, the frequency at which they are made, and how to easily reproduce this on my end. I have an old PC that I could load desktop Ubuntu on and try this. Being able to use the USB packet Anlayzer to log what's happening on the bus when this error occurs would be really useful. However, if it requires hours or days for the error to occur then it's going to be very difficult to correlate the failure with a specific point in the log.

I remember we had some sort of problem on Raspberry Pi before with an older version of the FTDI driver where the driver stopped issuing IN tokens on the bus. If that's what's happening here then that's a bug in the FTDI driver and I can't fix it and unless we can come up with an easy way to reproduce the symptoms then FTDI won't fix it either.

Share this post


Link to post
Share on other sites
  • 0

Hi @malexander

With RPi4B I have tried automatic reconnect.
On timeout calling DmgrClose/Open or DptiDisable,DjtgEnable,DjtgDisable,DptiEnable and retry the DptiIO transfer.
The later solution also resets the FIFO transfer control of FPGA logic by toggling the OE_JTAG.
The transfer retry has also failed with timeout. It looks like it needs more time before retrying the transfer, since when you OK the error message the communication recovers.
The statistic is about 1 of 1M transfers failing.

With RPi1-2-3B the received data is altered (0 bytes inserted data shifted...) and this occurs very often.
I have tried reducing the FIFO rate, like read/write 1 byte wait 16 cycles of the 60MHz FIFO clock.
I have also implemented data transfer over JTAG BSCAN USER1 to be used instead the Dpti/FIFO.
The failure rate was a bit reduced but still unusable.
The problem is not only with the FIFO transfers but also with the MPPSE.

Share this post


Link to post
Share on other sites
  • 0

Hi @Jonas

I just remember that I'm getting such errors with vbox virtual machine.
Are you running the Linux natively?

Share this post


Link to post
Share on other sites
  • 0

Hi @Jonas @malexander

I managed to reproduce and fix the issue on Linux amd64 and Raspberry Pi 4 B

The Linux and Raspberry Pi 4 ERC 0x2 is fixed in the latest version:
https://forum.digilentinc.com/topic/8908-waveforms-beta-download/

It looks like the Linux FTDI driver didn't like reading odd number of bytes.
The latest version rounds up all the reads from device to 32bit.
The stress tests on 3 systems was running for a day without any issue. With earlier version the error show up after a few hours.

image.thumb.png.b92f583c8f512c37bdb7ee5477502f7b.png

 

Share this post


Link to post
Share on other sites
  • 0

Hi @Jonas

I have tested it using the first device configuration, capturing 8k, 32kB data for days.
The second configuration captures 16k, 64kB of data and it looks like this causes issues for the FTDI driver.
Please use the first configuration for now.

I will add data chunking. Lets hope this will help...
I'm also working on a solution to overcome issue with Digital Discovery RPi4, updating HDL/FPGA interface to write even number bytes.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now