Jump to content
  • 0

AD2: ERC: 0x2 with Raspberry Pi 4

Jonas

Asked by Jonas,

Question

Jonas Member

Jonas

Posted
Posted

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

Link to comment
Share on other sites

24 answers to this question

Recommended Posts

attila Prolific Poster

attila

Posted
Posted

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.

Link to comment
Share on other sites
attila Prolific Poster

attila

Posted
Posted

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

 

Link to comment
Share on other sites
attila Prolific Poster

attila

Posted
Posted

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.

Link to comment
Share on other sites
malexander Prolific Poster

malexander

Posted
Posted

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.

Link to comment
Share on other sites
Jonas Member

Jonas

Posted
  • Author
Posted

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!

Link to comment
Share on other sites
attila Prolific Poster

attila

Posted
Posted

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.

Link to comment
Share on other sites
attila Prolific Poster

attila

Posted
Posted

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

Link to comment
Share on other sites
Jonas Member

Jonas

Posted
  • Author
Posted

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?

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

Go to question listing
×
×
  • Create New...