ADRV9009-ZU11EG + ADRV2CRR-FMC_RevB Auto Powerdown

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!



Forgot to finish a sentence.
[edited by: HLKMay at 5:46 PM (GMT 0) on 9 Dec 2019]
Parents
  • 0
    •  Analog Employees 
    on Dec 10, 2019 3:41 PM over 1 year ago

    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? 

  • 0
    •  Analog Employees 
    on Dec 11, 2019 1:52 PM over 1 year ago in reply to HLKMay

    Hello,

    Are you using Linux with the design ?

    Regards,

    Adrian

  • 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?

Reply
  • 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?

Children