Can ARM timing be corrupted?

[SBrow5]

I have a Cyclone V SOC system, and the ARM is running Linux, and the FPGA is running SDI video and VIP suite items. The FPGA DDR memory is being used by the VIP suite and all works well. The ARM is using the DDR memory attached to it, and Linux does not have any problems running. The ARM can configure the VIP suite over the LWAXI bus, and the ARM can write to the FPGA DDR memory from the H2F_AXI bus connected to one of the ports of the MPFE DDR controller.

In a particular system, it has been working well, and then someone does something and the ARM can no longer access the FPGA DDR memory, even after it has been powered down and back up again. The FPGA DDR memory is still working because the VIP suite is running through frame buffers, etc. The ARM DDR memory is working because Linux is running correctly. But as soon as I try and access the FPGA DDR memory from the ARM, the whole system stops - the ARM completely freezes.

The only way I can see this happening is if the FPGA DDR transaction holds wait and never releases it. But how can that happen even once, when the system runs reliably the rest of the time, but also, having been left running for two weeks, it then fails, and continues to fail every time it's rebooted. The only way I could fix it was to load some new firmware in, yet the firmware it had had been tested for months without problems.

Any clues gratefully received.

[Kenny_Tan]

1) Are you using our Intel board? Try to use our example design and make sure it works on the Intel board. From there you can make the comparison on the DDR settings. 2) It can be either connection, clock, or held in reset issue with the EMIF. Try to read any address related to ‘ecc_hmc_ocp_slv_block’. Also, check with your HW team to verify whether your DDR calibration fine by using the DDR toolkit (remove hps component and replace it with emif block) 3) Or use the same Uboot binary elf image (different devicetree blob) and run it on the A10 Soc board that you have. Check whether your DDR cal passes and boots to console promt? 4) If you have calibration failure, check your DDR PLL reference clock on the board matches the frequency specified in the Qsys? If that clock is fine and free running, you can also find the I/O PLL locked signal in signaltap and confirm that it’s locked. 5) check DDR RefClock is in the stable condition where it is not under load?

[Kenny_Tan]

No 3 should be CV boards. btw