We're having a problem with the SOM/Carrier powering off when were trying to debug custom designs over JTAG. This could be trying to program the FPGA directly to assess interfaces with IBERT cores (ie: totally custom PL design) or through the SDK with a custom bare-metal PS design (FSBL + say an augmented HelloWorld program) and released ADI PL firmware. In all of these cases, everything starts off fine and operational and after what seems like a variable and random amount of time, the entire stack powers down.Is there a way to disable this auto-powerdown behavior in these cases? Maybe something we can add to the FSBL template design or otherwise?Thanks!
Hi,Do you have a cooling fan running? If the board overheats it automatically powers off.Andrei
Hi Andrei.We do have a fan running and the Zynq die temperature is ~35C, so we do not think this is a temperature related issue. Any other ideas?
Are you using Linux with the design ?
Hi Adrian.We are using Linux in our tactical flow and using Linux, we're able to control the cpuidle bootarg that we think typically solves this problem... though the behavior doesn't seem rock-solid. Needs more verification.In the truly problematic flows however, we're trying to boot the board in a no-OS flow using JTAG. See above but this might be using the FSBL template from the Xilinx SDK or programming the FPGA part directly to play with things like PCIe IBERT cores, as an example. Essentially in these flows, we're using the board without any of the supplied PS base design from ADI.It's just very odd that in these flows, everything looks great for a bit, everyone is booted and happy, power-goods are all asserted... and then bang, off. In other cases, everything is happy and the moment we attach JTAG, bang, off. We suspect something is causing the power sequencer to fall into the faulted state.Is the Zynq PS expected to interact with the on-board power-sequencing chip/architecture in some way to prevent the board from powering off? Something else we're missing?
Hi,We replicated the issue, we'll start debugging.Andrei
Hi AndreiWe have a black-box on loan that we will try to debug with as well, but we're wondering if you've learned anything or made any headway since you replicated the issue.Thanks.
Please use ADI Power Studio to read the content of the black box and let us know which rail is causing the issues.
I am working this issue with Kevin and was able to read out the contents of the black box. The VDD1P3_DIG_A rail is reporting an OV Fault.
Please open the system rails tab, change the following values and program the device:
- OV Fault Level 1.450 Volts
- OV Glitch Filter 100uS
These settings should stop the board from rebooting until we find the right hardware fix (different values for the compensation network)
Thank you for the suggestion. I applied the changes and so far everything has been working as expected.