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!
We haven't seen any issues with that rail, but since it's powered by the same ADP5054 they could be related.
Can you try the following HW changes and revert to the original sequencer setup…
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?
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
The black box of the ADM1266 can be read using the EVAL-ADP-I2C-USB adapter.
If the sequencer is powering off the board it will be logged in the black box.
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.
We recently set up a second set of boards (SOM and Carrier) and programmed the ADM1266 with the updated configuration. These boards have been left powered-on and idle for the past two nights, and on both nights the ADM1266 recorded VDDA3P3_CLK under voltage faults and disabled the power supplies. Is this something that you have observed as well? Do you have any recommendations on how to proceed?
Can you try the following HW changes and revert to the original sequencer setup?
R337, R304 – 31.6K, 0402E27, E25, E23 – BLM18KG471SN1DE24, E21 – BLM18KG121TN1D
This should fix all the ADP5054 issues.