cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Visitor
Visitor
214 Views
Registered: ‎05-28-2020

TSU timer is not incrementing correctly

I am seeing weird behavior in the tsu_timer registers of the Zynq Ultrascale+ that uses the DP83867CRRGZR Ethernet PHY.

According to the register reference, the tsu_timer_nsec register should hold the nanoseconds timer, and the tsu_timer_sec register (and tsu_timer_msb_sec) should hold the seconds timer.

However, what I am seeing is that the tsu_timer_nsec register remains empty (0x00000000) and the tsu_timer_sec register contains a combination of seconds and nanoseconds. For example, if I poll the tsu_timer_sec register (approximately) once every second, I see an output similar to the following: 

 

root@program:~# devmem 0xFF0B01D0
0x7B6A6024
root@program:~# devmem 0xFF0B01D0 0x8A317732
root@program:~# devmem 0xFF0B01D0 0x99928EAA
root@program:~# devmem 0xFF0B01D0 0xA8B6040C root@program:~# devmem 0xFF0B01D0 0xB79CB402

These values also match the values read from emio_enet0_enet_tsu_timer_cnt[93:0]. 

 

When I run ptp4l, the zynq clock fails to synchronize with the grand master clock, and I see similar bahavior on the tsu_ptp_tx and tsu_ptp_rx registers (_sec register increments by ~ 0x10000000 every second, and _nsec register remains empty).

 

I also see the following output from ptp4l: 

ptp4l[4514.962]: selected /dev/ptp0 as PTP clock
ptp4l[4514.963]: port 1: INITIALIZING to LISTENING on INITIALIZE
ptp4l[4514.963]: port 0: INITIALIZING to LISTENING on INITIALIZE
ptp4l[4514.963]: port 1: link up
ptp4l[4515.477]: port 1: new foreign master b42e99.fffe.a78faa-1
ptp4l[4519.477]: selected best master clock b42e99.fffe.a78faa
ptp4l[4519.477]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE
ptp4l[4520.691]: master offset 7632232494850134543 s0 freq      +0 path delay  72933377
ptp4l[4521.691]: master offset 7632232493657728990 s0 freq      +0 path delay 265294060
ptp4l[4522.691]: master offset 7632232492740700486 s0 freq      +0 path delay 182310568
ptp4l[4523.691]: master offset 7632232491740612991 s0 freq      +0 path delay 182310568
ptp4l[4524.691]: master offset 7632232490730573848 s0 freq      +0 path delay 192324465
ptp4l[4525.692]: master offset 7632232489720530206 s0 freq      +0 path delay 202338362
ptp4l[4526.692]: master offset 7632232488689645026 s0 freq      +0 path delay 233178421
ptp4l[4527.692]: master offset 7632232487689617780 s0 freq      +0 path delay 233178421
ptp4l[4528.692]: master offset 7632232486720382219 s0 freq      +0 path delay 202338362
ptp4l[4529.692]: master offset 7632232485689481040 s0 freq      +0 path delay 233178421
ptp4l[4530.692]: master offset 7632232484689414294 s0 freq      +0 path delay 233178421
ptp4l[4531.692]: master offset 7632232483688347841 s0 freq      +0 path delay 234193504
ptp4l[4532.692]: master offset 7632232482688317095 s0 freq      +0 path delay 234193504

 

I can use wireshark to inspect the packets being sent by the host computer to the ZynqMP, and the time sent to the Zynq is correct.

 

It seems like all of the TSU timers are filling the "seconds" registers with the 8 LSB of seconds and 24 MSB of nanoseconds, and the rest of "seconds" spill over to the tsu_timer_msb_sec register. 

 

What is causing these registers to be stored / increment incorrectly? 

0 Kudos
0 Replies