cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Visitor
Visitor
767 Views
Registered: ‎07-16-2018

Zynq Secure Lockdown Timing Anomaly

Jump to solution

I’m bringing up a board with a XC7Z010 device. All seems largely well with all major interfaces verified however I am struggling to understand the cause of a PS_POR_B / Secure Lockdown issue at power-up.


All supply rail sequencing seems OK (Scope_Captures.tif : Image1) .....

 

VCCPINT & VCCINT (@1V0), VCCPAUX & VCCAUX (@1V8) and VCCO_PSDDR (@1V5) ramping in 1mS concurrently. VCCO_0 & VCC_MIO1 (@2V5) and VCCO_MIO0 (@3V3) ramping in ~1mS concurrently and about 450uS after the others start ramping

 

The above seems to satisfy the PS Power-On sequencing outlined in DS187.

 

All the board supplies are fed into a pair of PSU supervisor ICs (TPS386596) or’ed to produce the PS_POR_B signal (RST3V3n) (PS_POR_B_Circuit.tif).

 

This circuit produces the PS_POR_B reset pulse asserted low before power ramp and remaining asserted until ~52mS after all power is ‘good’ (Scope_Captures.tif : Image2)

What I’m finding though is that on release of PS_POR_B, it is not possible to ‘see’ the Zynq in the JTAG chain in Vivado Lab Hardware Manager and that the device will not configure via QSPI.

 

This is only achievable if the PS_POR_B assertion is extended until about 150mS or alternatively, a supplementary assertion of PS_POR_B after power-up also seems to fix the problem. I am assuming therefore that the device is going into Secure Lockdown.

 

Reading about the Secure Lockdown timing parameters, The PS_POR_B should de-asserted either before ~13.7ms or after ~34.3ms of the last 'control supply' i.e. VCCINT (PL), VCCAUX (PL), VCCBRAM, VCCO_0 (PL) reaching 250mV, to avoid Secure Lockdown.

With the PS_POR_B being released after ~50ms, this should more than clear that window. Moreover, the PS_POR_B in fact has to be extended to ~150ms to achieve correct booting.

 

I have tried manipulating the power supply sequencing with around 1mS gaps between each of 1V0, 1V8 and 3V3/2V5 to no avail.

I have tried keeping the original PSU ramp timing but bringing PS_POR_B release early to ~7ms after last supply reaches 250mV, also to no avail.

 

 

Observing the JTAG signals, I see that the XC7X010 is responding but clearly not in a manner that is recognised by Vivado Lab (Scope_Captures.tif : Image3). Multiple JTAG accesses are made over time (Scope_Captures.tif : Image4).

 

I think I’ve run out of things to try to resolve this, if you have any ideas or suggestions, they would be gratefully received.

 

Kind regards.

Scope_Captures.tif
PS_POR_B_Circuit.tif
0 Kudos
1 Solution

Accepted Solutions
Highlighted
Xilinx Employee
Xilinx Employee
710 Views
Registered: ‎10-11-2011

How are you handling SRST_B? It should never be asserted after POR is asserted. Maybe a glitch?

This AR are various reasons that might explain lockdowns:

https://www.xilinx.com/support/answers/56195.html

 

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------

View solution in original post

2 Replies
Highlighted
Xilinx Employee
Xilinx Employee
711 Views
Registered: ‎10-11-2011

How are you handling SRST_B? It should never be asserted after POR is asserted. Maybe a glitch?

This AR are various reasons that might explain lockdowns:

https://www.xilinx.com/support/answers/56195.html

 

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------

View solution in original post

Highlighted
Visitor
Visitor
629 Views
Registered: ‎07-16-2018

Thanks dentist,

Getting the scope out I discovered the RC time-constant on a switch debounce circuit took the SRST_B past the deassertion of POR_B.

A simple resistor change has cured the problem :-)

Thanks for you help/post.

0 Kudos