zynq por reset from pl io out

[hansonyh]

Hi,

    I am using Zynq-7000 to develop a new product , the detailed part number is xc7z015-2clg485i, I met a few problems listed below :

   1, When running  certain time , zynq-7000 seemed to be dead,the debug uart port was no output or input.

    2, To made zynq-7000 stable, I soldering a fly-wire directly to por_b reset button。What I wanted to do was to reset the whole SoC system from ZYNQ's PL side. I thought PL logic could be running independently from PS side. So I write a simple logic ,that made a PL side pin pull down after 10 second. But the result was amazing!  The result from serial terminal shows that ZYNQ will stop at starting Linux kernel , then reboot from SD boot,repeating again and again. I changed the delay time of 12s,15s and 20s. No differences!

   Given that, I think that it is impossible for zynq to reset SoC system from its PL side. 

   Could anyone give a solution for how to make ZYNQ re-run or reset. 

   Any reply will be appreciated!

 Regards!
 Yours Hao

[austin]

Read pages 162-164 in ug585 (Zynq tech reference manual),

Not the restrictions on the timing, and the correct external reset pin:

"PS_SRST_B: This reset is used to force a system reset. It can be tied or pulled High, and can be
High during the PS power supply ramp-up. The PS_SRST_B reset is a non-POR reset."

Commanding an IO pin of the PL to drive this signal low is problematic as during power ON, and subsequent configuration, any possible glitches would cause the system to fail to boot properly.

The IO of the PL is designed to remain tristate until configured and running, but that is once all the power supplies at their recommended values.

IO pin -----| |----------PS_SRST_B---------/\/\/\/\---------Vcc (correct supply for configuration dedicated IO pin)

             0.1 uF                                 10 K

If the IO pin is configured to be a '1' until commanded to reset the system, I believe the above may work.  The idea is that while powering ON, the signal is pulled up, and the powering ON and configuration of the PL should not cause reset to get asserted.  Once running, by pulling the IO low, you get a low pulse on the reset, that then goes high as the capacitor charges back up.

Have not tried it, but something like that should work.  The IO protection diodes will protect the pins from any residual charge on the capacitor.

Note to NOT assert this reset during the proscribed time:

"Note: The PS_SRST_B signal must not be asserted while the BootROM is executing from a POR
reset,..."

[allanherriman]

You might like to read all the comments in this thread.

[hansonyh]

Hi Austin,

    Problem solved!

    The reason why ZYNQ stops at Linux  kernel decompressing is the wrong compiled u-boot file.

    Besides that, I have tried several ways to verify the reset problems:

    1, given your advise , I soldered  a 10uF capacitor to gnd , making a RC circuit to generate a delayed reset signal for srst_b. Result is OK!

    2, I soldered the RC delayed fly-wire direct to PS_POR_B， it was OK!

    3, I removed the 10uF capacitor , soldering the pulled-up GPIO reset signal directly to SRST_B, It　was　ＯＫ　again!

    Given the results above, I guess that:

    when ZYNQ's PL logic drives a low output signal, the signal lasts in low status until POR_B/SRST_B "thinks" the reset signal is valid. The time from the moment that PL drives GPIO to low to the moment that POR_B/SRST_B "thinks" the reset is valid satisfies the required time .  

    I have tried for 3 hours without any accident.

    Thanks !

   Regards!

   Hao

[austin]

h,

10uF is a bit much.  I would use a smaller value, as 10uF peak currents might cause damage to IO structures.  If you use it, put 1N914 (1N4148) protection diodes to Vcc, and from ground.

As the reset is edge triggered on a low, that edge is all it takes.  The duration at the output is not a factor.