cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
johnblackxilinx
Contributor
Contributor
925 Views
Registered: ‎01-27-2019

ZynqMP stuck on running psu_init.tcl

Jump to solution

Hi.

I have 2 custom boards based on zynqMP. one of them work correctly but the other one suck on boot.

In SDK, bitstream load correctly, but when psu_init.tcl run, it stuck on last line:

 

10:50:44 INFO	: Project 'top_hw_platform_1' created. You can now create BSPs and application projects targeting this hardware platform.
10:53:03 INFO	: Connected to target on host '127.0.0.1' and port '3121'.
10:53:19 INFO	: Jtag cable 'Digilent JTAG-SMT1 210203861323A' is selected.
10:53:19 INFO	: 'jtag frequency' command is executed.
10:53:19 INFO	: Sourcing of 'C:/Xilinx/SDK/2019.1/scripts/sdk/util/zynqmp_utils.tcl' is done.
10:53:19 INFO	: Context for 'APU' is selected.
10:53:20 INFO	: System reset is completed.
10:53:24 INFO	: 'after 3000' command is executed.
10:53:24 INFO	: Context for 'APU' is selected.
10:53:24 INFO	: Cleared APU and A53 resets
10:53:24 INFO	: Context for 'RPU' is selected.
10:53:24 INFO	: Cleared RPU and R5 resets
10:53:24 INFO	: 'targets -set -filter {jtag_cable_name =~ "Digilent JTAG-SMT1 210203861323A" && level==0} -index 0' command is executed.
10:53:26 INFO	: FPGA configured successfully with bitstream "D:/.../top.bit"
10:53:26 INFO	: Context for 'APU' is selected.
10:53:26 INFO	: Hardware design information is loaded from 'D:/.../system.hdf'.
10:53:26 INFO	: 'configparams force-mem-access 1' command is executed.
10:53:26 INFO	: Context for 'APU' is selected.
10:53:26 INFO	: Sourcing of 'D:/.../psu_init.tcl' is done.

 

Flash doesn't programed!! It doesn't boot on SD!!! 

I changed FPGA too in defected board, but nothing was changed!

I think ARM core doesn't works correctly. power consumption of two boards are the same. ARM oscillator is OK too.

Anybody can propose me a test or suggestion to find the exact problem? Or anybody face to this or the same problem?

thanks.

0 Kudos
1 Solution

Accepted Solutions
ibaie
Xilinx Employee
Xilinx Employee
906 Views
Registered: ‎10-06-2016

Hi @johnblackxilinx 

The psu_init.tcl file is the initialization script for the processing system (PS) that is generated based on the Vivado configuration. There is also a psu_init.c file generated that is used by the FSBL to do the same initialization as part of the FSBL execution. If the initialization is failing the usual issue tends to be the DDR memory initialization phase as it includes some infinite loops in the calibration process.

Anyway the best way to debug this issue is using the FSBL to initialize the device rather than the TCL file. So basically use SDK to load the FSBL without the psu_init initialization selected in the debug configuration and check where does the execution of the FSBL get blocked, that would give a clue of what's going on in the board.

Regards


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

View solution in original post

6 Replies
ibaie
Xilinx Employee
Xilinx Employee
907 Views
Registered: ‎10-06-2016

Hi @johnblackxilinx 

The psu_init.tcl file is the initialization script for the processing system (PS) that is generated based on the Vivado configuration. There is also a psu_init.c file generated that is used by the FSBL to do the same initialization as part of the FSBL execution. If the initialization is failing the usual issue tends to be the DDR memory initialization phase as it includes some infinite loops in the calibration process.

Anyway the best way to debug this issue is using the FSBL to initialize the device rather than the TCL file. So basically use SDK to load the FSBL without the psu_init initialization selected in the debug configuration and check where does the execution of the FSBL get blocked, that would give a clue of what's going on in the board.

Regards


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

View solution in original post

johnblackxilinx
Contributor
Contributor
838 Views
Registered: ‎01-27-2019

Hi, thanks @ibaie You are right. the problem was from DDR memory.

FSBL was stuck in "unsigned long psu_ddr_phybringup_data(void)" function in file "psu_init.c" in line:

while (regval != 0x80000FFF)
regval = Xil_In32(0xFD080030); /*PUB_PGSR0*/

I hope with changing DDR memory, it'll be worked.

Thank you very much.

best regards.

gustoff
Participant
Participant
602 Views
Registered: ‎07-07-2016

Hi!

I stuck in the same place. Did change of the DDR memory help?

By the way, if read 0xFD080030 register in this place, i got 0x8010001E value, which says that board (ZCU102) has impedance error (table 17-5 of ug1085). 

0 Kudos
johnblackxilinx
Contributor
Contributor
535 Views
Registered: ‎01-27-2019

Hi @gustoff.

Yes, I changed it and it helped to work correctly.

It depends on your memory address configuration. You can test your system with just one the first chip.

If the failed chip is the first one, It won't help you and you need change it.

Best regards.

0 Kudos
gustoff
Participant
Participant
522 Views
Registered: ‎07-07-2016

Hi @johnblackxilinx 

Thanks for response!

Do I understand correctly that you physically replaced the DDR memory on new (I mean, you don't simply change DDR like settings in Vivado)?

0 Kudos
johnblackxilinx
Contributor
Contributor
415 Views
Registered: ‎01-27-2019

Hi @gustoff.

Yes. exactly.

0 Kudos