UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Visitor dani8492
Visitor
3,635 Views
Registered: ‎01-27-2017

Connection to picoZed not possible! Secure lockdown mode?

Jump to solution

Hello everyone,

 

we use a picoZed with a Zynq 7015 Chip on it and designed a Carrier Card for it by ourselves. On this carriercard we used the powersupply circuit used in the FMC-V2 CarrierCard from Zedboard (http://microzed.org/product/picozed-fmc-carrier-card-v2) .
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.

 

tslw_timing calculations.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:

vccint.png

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

 

VCCAux vs. PS_POR_B:

vccaux.png

Figure 3:VCCAux vs. PS_POR_B Tslw=28.3ms

 

VCCO_0 vs. PS_POR_B:

vcco_0.png
Figure 4: VCC0 vs. PS_POR_B Tslw=25.15ms

 

VCCO_34 vs. PS_POR_B:

vcco_34.png
Figure 5: VCCO_34 vs. PS_POR_B Tslw=27.5ms

 

VCCO_13 vs. PS_POR_B:

vcco_13.png
Figure 6: VCCO_13 vs. PS_POR_B Tslw=23.55ms


INIT_N vs. PS_POR_B:

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

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 we can do?

 

Kind Regards,

Daniel

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Visitor dani8492
Visitor
6,246 Views
Registered: ‎01-27-2017

Re: Connection to picoZed not possible! Secure lockdown mode?

Jump to solution

Hey,

 

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

View solution in original post

0 Kudos
3 Replies
Community Manager
Community Manager
3,537 Views
Registered: ‎07-23-2012

Re: Connection to picoZed not possible! Secure lockdown mode?

Jump to solution
INIT_B toggles in secure lock down. To understand if the system is in secure lock down or not, first monitor the activity on INIT_B. You can find more details on this in Chapter-6 of UG585.
-----------------------------------------------------------------------------------------------
Please mark the post as "Accept as solution" if the information provided answers your query/resolves your issue.

Give Kudos to a post which you think is helpful.
0 Kudos
Visitor dani8492
Visitor
3,530 Views
Registered: ‎01-27-2017

Re: Connection to picoZed not possible! Secure lockdown mode?

Jump to solution

Thanks smarell for your answer!

 

I'm sorry, figure 7 was measured at the wrong pin. I did the measurement again and recognized that the INIT_B Signal goes high in the same moment when POR_B rises and also drops low in the same moment when POR_B sinks to 0V.

Attending to the User Guide this would be insecure lockdown mode. Is that right?

If yes, why do we get there and what do I have to change that we don't get into insecure lockdown?

 

Why are there two different descriptions what happens at INIT_B in secure lockdown? The Userguide says there will be an errorcode on this signal, the AR#63149 says it stays high in secure lockdown. Which one is right?

 

Thanks for your answers!

 

Regards Daniel

 

0 Kudos
Highlighted
Visitor dani8492
Visitor
6,247 Views
Registered: ‎01-27-2017

Re: Connection to picoZed not possible! Secure lockdown mode?

Jump to solution

Hey,

 

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

View solution in original post

0 Kudos