PicoZed SDR Z7035-AD9361 Power Sequencer Update

I have a custom carrier using 5V for JX_VIN and 3.3V for VCCO_12 and VCCO_13.  I'm not using the MGT bank so have connected MGTAVCC and MGTAVTT to gnd.  Following the procedure outlined in the pdf, I still see pulsing D3 and VIN_EN from ADM1166 never enables VIN.

Are there other HW configurations on my custom carrier that could be missing?

What you described should work just fine. Let's confirm a few things.

1. You successfully updated the ADM1166 firmware by attaching the SDR2x2 SOM to an Avnet carrier and following the PDF instructions?

2. Did it power up on the Avnet carrier after reprogramming the ADM1166?

3. Can you measure the 5.0V, and 3.3V rails on your carrier and confirm they are within spec (Table 1 in the PDF)?

4. Are you running the out-of-box SD card image on the SOM, or something custom?

5. Which revision of SOM do you have RevC or Rev E?

Let's start there. We should be able to diagnose this quickly.

/Matt

1) yes, we are using the AES-PZSDRCC-FMC-G board to program

2) yes, it did power up on the Avnet carrier both before and after reprogramming the ADM1166

3) 5.0 measures 5.08V and 3.3 measure 3.38

4) we're running a custom image on SDCard, but the SOM boots fine on the FMC Carrier.  On custom carrier, PG_MODULE LED (D3) blinks constantly and VIN_EN never turns Q13 on.

5) static bag says revC

Thanks!

Copying 'iampkim' response from elsewhere:

"I put a probe on my 5V into the SOM.  After my 5V comes up, I see Vin_en go high about 4ms later..  When Vin_en goes high (12V), my 5V droops to 3.5V for about 2ms and ramps backup to 5V.  Around 400ms later, Vin_en goes low again and shuts down the SOM.
I'm guessing the in-rush current on the 5V to the SOM is causing the droop.  Is a 2ms glitch long enough to shut down the ADM1166?  Once it shuts down, does the ADM1166 wait to see if the 5V is good and try again?"

---

YES! This is almost certainly the problem. If your 5V rail dips beneath the 4.5V threshold the ADM1166 will power down the SOM. It should stay in a power down state until you power cycle the system 5V rail. You could modify the ADM1166 firmware to accomodate your 5.0V supply. A simple time delay would do the trick. You can also set a measurement window on the ADM1166 inputs such that the threshold must be crossed for x ms before triggering.

/Matt

It looks like the current limit from the bench supply was too low.  I've increased the current limit to 1.5A and the glitch on the 5V input virtually goes away - however, the PG_MODULE led continues to blink.  Is there a document somewhere that details the ADM1166 configurations?

It looks like the 1.8V switcher on the SOM is going into short-circuit shut-down.  Probing around shows that VCCPCOM-1P8V has a zero ohm connection to FPGA_VBATT.  Following the user guide and connecting FPGA_VBATT (JX1-7) to ground (Sper note on Table 14 of SOM User's Guide V1.5) will short the 1.8V and prevent the module from booting.  A simple fix is to remove R9 on the SDR SOM to remove the VCCPCOM-1P8V from FPGA_VBATT ... not using bitstream encryption so this is not an issue.

Hi Peter,

Are you saying you removed R9 from the SOM and it now powers up successfully on your custom carrier?

Based on the symptoms you described, it sounds as thought FPGA_VBATT (JX1-7) may be grounded on your carrier. That would also short the VCCPCOM-1P8V rail to ground (which you observed) and keep the SOM in a protective shutdown state.

/Matt

Yes, I removed R9.  The note under table 14 of the SOM User guide V1.5 says grounding FPGA_VBATTis OK when not used.  I have that pin (JX1-7) hardwired to GND on my custom carrier and it shorts the 1.8V switcher (U18) to gnd (the switcher tries to power up twice, each time going into safety shutdown, and then the enable goes low after 10ms) .  That note should be fixed.

I did the exact same thing on my custom carrier, and had to remove R9... I agree, the user guide should be clarified.

All of the information in the user guide is correct, but not very clear.  It says "As specified in the Zynq TRM, if the battery is not used, connect VCCBATT to either ground or VCCAUX." (which I read as I should connect the pin to GND or VCC, but it's saying that the Zynq pin, not the SOM pin, needs to be connected to either voltage).  Then the next sentence is the critical one, which I must have overlooked, or didn't think was important: "On PicoZed SDR Z7035/AD9361 VCCBATT is connected through a 0 Ω resistor (R9) to the PicoZed SDR VCCAUX supply (VCCPCOM-1P8V), which is 1.8V."

Then even the "Important! To apply an external VCCBATT battery to Zynq from the end user carrier card, remove R9 from the PicoZed SDR System-On-Module." isn't clear, because that makes me think I need to pull R9 if I want to connect a battery, but doesn't make me think that R9 is related to me grounding the pin on the carrier.

And the JX1 pin summary is worse, where it just says "FPGA_VBATT (VCCBATT) is required only when using bitstream encryption. If battery is not used, connect VCCBATT to either ground or VCCAUX."

IMO, it'd be better if the guide was more direct... something like "If not using FPGA_VBATT, leave pin disconnected on the carrier.  The VCCBATT voltage is connected to 1.8V via R9 on the SOM.  If connecting an external battery on the carrier, remove R9.

Pat

Gentlemen - I just read the Vbatt section again. Wow, I'm the author and I still had to read it a few times to understand my original intent.

Really sorry that it caused you problems. I'm cleaning that section up today. Thanks for the suggested text Pat. I may reuse it.

Thanks

/Matt