cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Adventurer
Adventurer
398 Views
Registered: ‎11-13-2018

What causes XDMA Configuration Registers to Reset to Default?

Jump to solution

Hello,

We are using the XDMA IP in Vivado 2019.2 with an AC701 evaluation board. We are writing a Windows driver based on the XDMA driver provided and have run into a problem. We noticed that on cold reset our DMA utility was hanging and would not complete the cycle. The DMA utility works perfectly after a warm reboot or reinstalling the driver. We investigated this and saw that on cold reset the H2C and C2H control registers were default (8'h0). That led us to see that the following registers were also default: H2C Channel Interrupt Enable Mask and C2H Channel Interrupt Enable Mask. The Channel Identifier Registers were as expected. On warm reset or reinstallation of the driver, the registers are no longer default.

Our question is: What causes the registers to be reset to default?

It doesn't seem to be a simple assertion of the sys_rst_n pin, as this seems to set everything to 0xFFFFFFFF until the reset is held and "Scan for Hardware Changes" is clicked (we tested this with a push-button). Could it be some strange hot reset?

A similar problem was mentioned recently in https://forums.xilinx.com/t5/PCIe-and-CPM/XDMA-Configuration-registers-reset-after-cold-boot/m-p/1099710, but their suggested fix did not solve our problem. 

Any support or advice would be greatly appreciated! Thanks

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Adventurer
Adventurer
209 Views
Registered: ‎11-13-2018

After further investigation we found that any changes to the devices in the system (like disconnecting a keyboard) would cause these spurious interrupts. That led us to dive deep in comparing the original driver code to our code. Eventually, we saw differences in the .inf files and applied changes to make them similar. This resolved the spurious interrupt issues we were seeing. 

The only remaining problem is that the XDMA configuration registers are reset to default values after boot and we are unsure why. We implemented a workaround mentioned in an earlier comment, but maybe this bug is still worth looking into for Xilinx. 

View solution in original post

3 Replies
Highlighted
Adventurer
Adventurer
331 Views
Registered: ‎11-13-2018

This also occurs using the XDMA example design (with changes to the XDC) and the provided Windows driver. I see that the dma_bridge_resetn signal can reset the internal registers, so we enabled this port and tied it to a constant value of 1. This did not solve the problem so it is looking like a bug in the IP. Are there any workarounds or is there something we are missing?

0 Kudos
Highlighted
Adventurer
Adventurer
273 Views
Registered: ‎11-13-2018

Here's an update on what we've figured out so far...

We used the solution described in this post as a partial workaround:
https://forums.xilinx.com/t5/PCIe-and-CPM/XDMA-Configuration-registers-reset-after-cold-boot/m-p/1111029#M16559

The problem now is that we are still getting spurious interrupts on boot. Many posts mention enabling MSI-X to get rid of these interrupts, but when we tried it no interrupts occur at all (not even the expected ones). We also tried tying 0 to the usr_irq_req, but that didn't make a difference. Eventually, we will need to connect things to this port, so I'm not sure if that's really a good solution anyway.

Has anything been done to fix these issues? Xilinx employees in other posts mention that it was going to be looked into:
https://forums.xilinx.com/t5/PCIe-and-CPM/XDMA-Linux-driver-calling-ISR-repeatedly-during-transfer-without/m-p/886152/highlight/false#M11857
https://forums.xilinx.com/t5/PCIe-and-CPM/Linux-XDMA-module-from-AR65444-rel20180420-ISR-called/m-p/1111397#M16567

We are going to continue to find a work around, but can anyone see something we're missing? I know every XDMA user's application is different, but maybe there's something obvious we are not seeing. Is there a patch somewhere for these issues?

Thanks in advance,
Brad

0 Kudos
Highlighted
Adventurer
Adventurer
210 Views
Registered: ‎11-13-2018

After further investigation we found that any changes to the devices in the system (like disconnecting a keyboard) would cause these spurious interrupts. That led us to dive deep in comparing the original driver code to our code. Eventually, we saw differences in the .inf files and applied changes to make them similar. This resolved the spurious interrupt issues we were seeing. 

The only remaining problem is that the XDMA configuration registers are reset to default values after boot and we are unsure why. We implemented a workaround mentioned in an earlier comment, but maybe this bug is still worth looking into for Xilinx. 

View solution in original post