PXI-7813R hardware failed same way twice. Failure limits DMA to only 3069 transfers.

[Andrew_Quick]

Hi,

I have had two PXI-7813R cards fail on me in the same way. I am doing a simple DMA transfer of 64K bytes from the FPGA to the host. Both cards that failed stop transferring after 3069 bytes. I am not sure how long the first card lasted before it failed but the second one lasted about three weeks.

Question; Is there any way that I can actually damage the FPGA card with a compiled program? I hope the answer is no but I just thought I would throw the question out there.

Thanks

Andy

[Miro_T]

It will be very unusual for the DMA transfer to damage a card. Can you elaborate more on the failure that you seeing?

Do you get any error when reading more than 3069 bytes? If so what is it?

Do you see any other problems with the card, if so can you list them out ?

Do you have any other R series cards that are able to run the same exact code? Any problem there?

[Andrew_Quick]

The whole thing makes no sense to me. If it failed at 2048 or 4096 then there is logic but 3096, where does that come from. The software is very simple, I have a FPGA FIFO write inside a 64K for loop. Each iteration of the loop I read one byte of data from an I/O port and write it to the FIFO. Inside a host VI I have a FIFO read inside a 64K for loop which reads one byte at a time. What is happening is that the FIFO read is giving a -50400 error after the FIFO read has been round the loop 3069 times. I have tried multiple different methods to solve the problem such as reading all 64K bytes in the FPGA loop before starting the host read. When I do this the "elements remaining" on the FIFO.read shows 3069 and then counts down. I have set the FIFO.read size to 100,000.

The code works on a different machine with the same code and hardware. The code once worked on this machine but has failed the same way twice.

I guess I will just have to send the card back as another RMA repair.

I was wondering if the MXI interface (PXI-8360) could be responsible?

Thank you.

[a_clucker]

---

"Inside a host VI I have a FIFO read inside a 64K for loop which reads one byte at a time"

To confirm: you have a PC controlling the PXI chassis over MXI, and the code running on the PC is looping at 64 kHz?

Can you confirm in any way that this rate is actually achieved?

"The code works on a different machine with the same code and hardware."

Does the other HW also use a MXI-controlled PXI chassis? Is it the exact same code?

In general, I recommend calling FIFO read twice in the host loop: once to obtain the number of items available to read (without actually reading any items), and immediately after to read that number of items. Reading only one element at a time on a host can easily lead to FIFO overflow, as a host is inherently slower than FPGA.

[Miro_T]

I think your FIFO implementation is wrong and you are just simply getting fifo timeouts. (nothing wrong with your card).

I would recommend looking over DMA FIFO's in the cRIO developers guide (same idea applies to R Series) starting pdf page 97.

Figure 5.23 shows a nice trick how to use another 'DMA read method' to check number of elements in the FIFO and read it that amount later.

Similarly, figure 5.24  shows how to handle FPGA FIFO timeouts. 

You can also find few DMA FIFO examples in the LabVIEW example finder (click Help>>Find Examples...)

[Andrew_Quick]

Yes, I have a PC running LabView and it communicates with the PXI rack over MXI.

No, the loop is not looping at 64 kHz. It is a for loop running 64K times (65536). I am reading 1 byte at a time from the FIFO with a 2 second timeout each time.

Yes, the code works on another identical machine.

I changed the program to 0 timeout and 0 bytes to read in an infinite loop. I read back the available bytes and it never got past 3068.

There is no FIFO overflow because the amount of data being read is less than the FIFO size. I check the overflow flag anyway and it does not get set.

I will see if I can find the RMA numbers from our goods out people so maybe you can track them and let me know what you find.

Thank you.

[Andrew_Quick]

Thank you. I did not know about the trick of setting the bytes to read to 0 in order to just read the amount of data available. I did try this but as you can see from my previous response it just confirmed that the DMA transfer gets stuck at 3068 available bytes instead of reaching the real data count of 65536.

[a_clucker]

Hey Andrew,

At this point, I recommend creating a Service Request and working with Applications Engineers to further troubleshoot. If/when you create one, please reference this thread in the description.

[nanocyte]

Sounds like a logic error. What do you get from "Actual Depth" when you call configure? Are you sure there's never any timeouts from the FIFO writer.

[Andrew_Quick · Accepted solution]

Hi,

Found the answer to this one yesterday. Sorry I did not post immediately.

The problem was caused by turning power onto the PXI rack containing the 7813R at the same time that power was tuned onto the PC running LabView. I had the PXI rack and the PC connected to the same power strip. When we saw the problem we would power cycle the rack and PC together thinking that would be the best system reset. We finally discovered that if we waited a few seconds after powering the PXI rack or rebooted the PC without power cycling the PXI rack that everything would work as expected.

Thank you for looking at this for me.

Regards

Andy