assertion failed! Pin_memory problem.

[Altera_Forum]

Hi 

I'm encountering an assertion failed problem. The returned message is "MMD FATAL: acl_pcie_dma_windows.cpp:381: WDC_DMASGBufLock function failed." I looked into the acl_pcie_dma_windows.cpp file and it was somthing about pin_memory: 379 assert(lock_size < MAXDWORD); 380 WD_status = WDC_DMASGBufLock(m_device, lock_addr, lock_options, (DWORD)lock_size, &new_mem->dma ); 381 ACL_PCIE_ASSERT( WD_status == WD_STATUS_SUCCESS, "WDC_DMASGBufLock function failed.\n" ); It doesn't happened every time I execute my program, most of the time it would run successfully (without recompilation), but the frequency is increasing as I'm using more clCreateBuffer (which is the only thing I can think of that is related to pinning memory).  Anyone have idea of what does this error mean and how to solve it? Thanks a lot!

[Altera_Forum]

These types of errors are related to PCI-E timing bugs in Altera's interface or the BSP provided by the manufacturer. I don't think users can do anything to avoid them. On Stratix V I have not encountered them since v16.1. On Arria 10 there are still numerous timing issues with PCI-E-based partial reconfiguration and hence, I always force JTAG-based reconfiguration and have never had any problems with that.

[Altera_Forum]

Hi HRZ 

Thank you for the reply. I tried forcing JTAG-based reconfiguration as you mentioned using " set ACL_PCIE_USE_JTAG_PROGRAMMING=1", but the same problem still exist.  Is it because that it's still transferring data via PCIe at runtime or am I not forcing it correctly? Thank you.

[Altera_Forum]

If the environmental variable is set correctly, you will see lots of messages from quartus_pgm during host execution that starts the programming process through JTAG and finishes it (which can take up to 30 seconds) and then your kernel is executed. Did you see these messages? On my environment those messages are especially printed out in green, but I use Linux and things might be different on Windows.

[Altera_Forum]

--- Quote Start ---  If the environmental variable is set correctly, you will see lots of messages from quartus_pgm during host execution that starts the programming process through JTAG and finishes it (which can take up to 30 seconds) and then your kernel is executed. Did you see these messages? On my environment those messages are especially printed out in green, but I use Linux and things might be different on Windows.  --- Quote End ---   Yes I saw the green messages and it took much longer to configure compares to vie PCIe.  I tried to identify what's causing the problem since it doesn't happen a lot before, but all I found so far is that it's related to storing data in buffer. Previously it would happened maybe 1 out of 50 times, and as I store more data in the device buffer the frequency increase, now it would happens like 1/3 of the time...  Weird thing is that it only happens at the beginning of my program(video processing), sometime it happens at the 10th frame or the very first frame, but if it pass the first few frames safely then it can run all the way to the end.

[Altera_Forum]

All right. Have you been able to pinpoint in which part of your code this issue happens? Does this happen when you are trying to copy data from the host to the device? Maybe your problem is different from what I encountered on my own environment before; in fact, it seems in your case the DMA operation is failing for some reason. I recommend contacting the support channel of your board manufacturer. They will give you instructions as to how you should obtain debugging information during execution so that they can pinpoint the issue in the driver. If you are using Altera's reference board, then contact Altera directly.