ADRV9009-ZU11EG + ADRV2CRR-FMC_RevB Auto Powerdown

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 Andrei

We 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.

Thanks,

Mihai

Mihai,

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.

Thanks,

Mike

Hi Mike,

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)

Thanks,

Mihai

Mihai,

Thank you for the suggestion. I applied the changes and so far everything has been working as expected.

Mike

Mihai,

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?

Thanks,

Mike

Hi Mike

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?

R337, R304 – 31.6K, 0402
E27, E25, E23 – BLM18KG471SN1D
E24, E21 – BLM18KG121TN1D

This should fix all the ADP5054 issues.

Thanks,

Mihai

Hi Mike

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?

R337, R304 – 31.6K, 0402
E27, E25, E23 – BLM18KG471SN1D
E24, E21 – BLM18KG121TN1D

This should fix all the ADP5054 issues.

Thanks,

Mihai

Mihai,

Yes, I will try this and let you know how it goes. I think I've located all of the components, but would you be able to provide an assembly drawing or other documentation to confirm them?

Thanks,

Mike

Hi,

I will attach some pictures so you can find the components

Regards,

Ciprian

Mihai,

I received the replacement parts today and found that the ferrite beads are not the correct size. The replacements parts are 0603 size, but the footprint on the board is 1206. Is this intentional? Has this change been applied and verified on your end?

Thanks,

Mike

The footprint change is intentional. We tested on our end and this solves all the known issues.

Thanks,

Mihai

Thank you, Mihai. We installed the new components on the board that was experiencing VDDA3P3_CLK  faults, and it has been running successfully for a few days now. If it continues to run without faults for the rest of the week then we will go ahead and rework our other boards.

Thanks,

Mike

Mihai,

We modified the rest of our boards and all three have now been running without issue for several days. At this point I think it is safe to close out this issue. Thank you for the help.

Mike