Actions
Forum Thread Details
  • State Verified Answer
  • Replies 5 replies
  • Subscribers 176 subscribers
  • Views 233 views
  • Users 0 members are here
Related

picoZed 7015 - PG_Module Signal disappears

dani8492
 

Hello,

 

we use a picoZed 7015 and designed a Carrier Card for it by ourselves. On this carriercard we used the powersupply circuit used in the FMC-V2 CarrierCard.
   It’s not possible for us to connect Vivado to the picoZed using JTAG communication. Everytime we try to connect to the target, Vivado shuts down the whole task.

 

The JTAG port is conneted over the Digilent JTAG-HS2 Programming Cable. When using the programming software "Adapt" of digilent, the FPGA appears at the toolchain, but the ARM doesn’t. When we connect the picoZed in standalone mode over JTAG. Both, ARM Core and FPGA are visible in the Toolchain. Also Vivado doesn’t crash when using picoZed in Standalone Mode, but two errors occur which say “[Labtools 27-2269] No devices detected on target localhost:3121…” and “[Labtools 27-55] Invalid index 0 passed to getIndex”.
   We also measured the PG_Module Signal which is Active High when the picoZed is in standalone configuration and the PG_Module Signal on the Carriercard is also High when no picoZed is pluged in. But if the picoZed is connected to the Carriercard the PG_Module Signal turns low. Therefore we found the Design Advisory AR#63149 (https://www.xilinx.com/support/answers/63149.html) and made the recommended test measurement. According to the test results, the PS_POR_B turns high in the calculated Secure Lockdown Window.

 

https://picload.org/image/roogawpc/tslw_timingcalculations.png

 

Figure 1: PS_POR_B timing calculations

 

 

 

According to this there is the possible risk that the secure lockdown occurs in the time window. So we made the required measurements which are depictured below.

 

 

 

VCCInt vs. PS_POR_B:
    

 

https://picload.org/image/roogawwg/vccint.png

 

Figure 2: Measurement of VCCInt vs. PS_POR_B Tslw=31,25ms

 

 

 

VCCAux vs. PS_POR_B:

 

https://picload.org/image/roogawpp/vccaux.png

 

Figure 3:VCCAux vs. PS_POR_B Tslw=28.3ms

 

 

 

VCCO_0 vs. PS_POR_B:

 


   https://picload.org/image/roogawic/vcco_0.png

 

Figure 4: VCC0 vs. PS_POR_B Tslw=25.15ms

 

 

 

VCCO_34 vs. PS_POR_B:

 


   https://picload.org/image/roogawpd/vcco_34.png

 

Figure 5: VCCO_34 vs. PS_POR_B Tslw=27.5ms

 

 

 

VCCO_13 vs. PS_POR_B:

 


   https://picload.org/image/roogawpg/vcco_13.png

 

Figure 6: VCCO_13 vs. PS_POR_B Tslw=23.55ms

 


   INIT_N vs. PS_POR_B:

 


   https://picload.org/image/roogawpo/init_n.png

 

Figure 7: INIT_N doesn’t turn low after PS_POR_B turns high

 

 

 

All the measurments show the described behavior in the Answer Record (#63149).

 

 

 

Implemented Solution:
   We tried to tie a capacitance of 100µF to the PG_Module port at the Carriercard to change the timing between the last PL power ramp and the PS_POR_B. Like shown in Figure 8 the voltage at the PS_POR_B port then rises slowly and drops down from ~1.2V back to LOW after more than 70ms (out of SL-Window range).

 

https://picload.org/image/roogawip/vcco_0_101uf.png

 

Figure 8: VVCO_0 vs. PS_POR_B with a 100μF Capacitance tied from PG_Module to GND

 

 

 

So it still doesn't work. Does anybody have a possible solution to this issue. What can we do?

 

Thanks for your help!

 

 

 

Kind Regards,

 

Daniel

 

EDIT: Picture Upload didn't work, so I uploaded them on an extern provider an inserted the links here.

  • 0

    We took a closer look on the start-up sequence on our carriercard and delayed the 1V8_LDO for some ms so no overlapping at the risetime of 1V0 is given. After we applied this, we saw that voltage at the VADJ(1V8) and the 3V3 Channel rises to a defined value (~1V for VADJ and 100mV for 3V3), although the channels are not activated. When the enable signal of the responding port turns high, the output-voltage rises to the desired voltage (1,8V/3,3V).

    Here you can see plots of the outputs of Channel 1 and 2 vs. the PG_1V8 Signal from the picoZed:

    https://picload.org/image/roowwroa/vcc_en_1v8.png
    https://picload.org/image/roowwrol/vcc_en_3v3.png

    If I unplug the picoZed and enable the ADP5052 manually, the voltage jumps directly from 0V to 1,8V no step in between. So has this error its origin on the picoZed? Has anybody an idea where this could come from? Is there an connection between the banks of the Zynq so it is possible to pull the banks of vcc_34/35 to high?

  • 0

    Hello Dani,

    Do you have an Avnet PicoZed FMC Carrier Card that you could try and make sure everything is working properly with the SOM?

    The issue most likely stems from your Custom Carrier Card and not the SOM. I am going to suggest that you read through the PicoZed Carrier Design Guide and the PicoZed Hardware User guide in attempts to find the issue with your Carrier Card http://zedboard.org/support/documentation/4736

    --Josh

  • 0

    Thanks for your reply.

    No we don't have one yet.

    We found the error with the output voltage which rises too early. The banks got supplied by the LVDS Signals from a ADC on the Carrier Card.

    But the timing problem still remains. I did a mistake on Figure7 (measured wrong pin) the signal of INIT_B acts the same like the POR_B Signal. So it is asserted for about 1.8ms, drops low afterwards in the same moment with POR_B. Attending to Userguide #585 Chapter 6.3.12 a drop to zero means the chip goes into insecure mode. What can we do about this issue?

    Thanks for your help!

    Regards Daniel

  • 0

    Hi Dani,

    I cannot really advise you based on the information your provided. Would you be willing to send me a PDF of your schematic that I could perform a quick review on?

    --Josh

  • 0

    Hey Josh,

    we found the mistake. The SRST_B Pin was connected to the CDCM Clocksynthesizer (like in FCM V1) with a 0R Resistor. Therefor this Chip asserted the SRST Signal not until it was supplied by the 3V3 on the CarrierCard. Since the 3V3 is the last Supplyvoltage the time between the assertion of SRST and POR_B (or probably the begin of the Boot process) was too short.

    Also, there was a solder connection beneath the microheaders which connected PG_Module with two neighbored MIO-Pins, this also disturbed the Booting process.

    Thanks for your support.

    -- Dani