Hi,
I have been experiencing similar clock jump issues as described in thread:
I am using SDK version: ti-processor-sdk-linux-am65xx-evm-08.06.00.47 and a custom designed AM6548 based board. I am using these boards for network monitoring and noticed in some capture files I get random time jumps of a couple hours at a time. I understand that this problem was supposed to be fixed in the 8.6 SDK release, however it looks like it still persists (although much less frequently). Using the steps outlined in lucas's thread above, I can replicate the time jump. Using phc_ctl I can set any of the icssg instance's clocks to 16750, set the interface down, set it back up, and see the time jump at clock time 16777.
root@am65xx-evm:/home# ./phc_ctl pru1 set 16750
phc_ctl[5527.460]: set clock time to 16750.000000000 or Thu Jan 1 04:39:10 1970
root@am65xx-evm:/home# ip l set pru1 down
root@am65xx-evm:/home# ip l set pru1 up
root@am65xx-evm:/home# ./phc_ctl pru1 get
phc_ctl[5545.407]: clock time is 16767.948637776 or Thu Jan 1 04:39:27 1970
root@am65xx-evm:/home# ./phc_ctl pru1 get
phc_ctl[5549.089]: clock time is 16771.630718988 or Thu Jan 1 04:39:31 1970
root@am65xx-evm:/home# ./phc_ctl pru1 get
phc_ctl[5552.170]: clock time is 16774.711789880 or Thu Jan 1 04:39:34 1970
root@am65xx-evm:/home# ./phc_ctl pru1 get
phc_ctl[5554.334]: clock time is 16776.875489744 or Thu Jan 1 04:39:36 1970
root@am65xx-evm:/home# ./phc_ctl pru1 get
phc_ctl[5555.570]: clock time is 8389.503409132 or Thu Jan 1 02:19:49 1970
I can replicate it at multiples of the same clock time as well
root@am65xx-evm:/home# ./phc_ctl pru1 set 33540
phc_ctl[5661.528]: set clock time to 33540.000000000 or Thu Jan 1 09:19:00 1970
root@am65xx-evm:/home# ip l set pru1 down
root@am65xx-evm:/home# ip l set pru1 up
root@am65xx-evm:/home# ./phc_ctl pru1 get
phc_ctl[5668.863]: clock time is 33547.335380500 or Thu Jan 1 09:19:07 1970
root@am65xx-evm:/home# ./phc_ctl pru1 get
phc_ctl[5670.984]: clock time is 33549.456723732 or Thu Jan 1 09:19:09 1970
root@am65xx-evm:/home# ./phc_ctl pru1 get
phc_ctl[5672.670]: clock time is 33551.143041248 or Thu Jan 1 09:19:11 1970
root@am65xx-evm:/home# ./phc_ctl pru1 get
phc_ctl[5674.421]: clock time is 33552.893709252 or Thu Jan 1 09:19:12 1970
root@am65xx-evm:/home# ./phc_ctl pru1 get
phc_ctl[5676.389]: clock time is 25166.253645372 or Thu Jan 1 06:59:26 1970
Is there any update on a fix for this? Or at the very least a work around? It is making my network logs next to useless with unreliable timestamps.
Edit: It has just occurred to me, on startup I am taking the interfaces down one by one, and renaming them to pru1 through pru6 based on their MAC addresses that I hard code in the device tree. I do this because the startup order of them doesn't seem deterministic, and so every so often, what gets named eth1 and eth2 is actually not ICSSG0. Is this issue coming from the fact that I am taking the devices down one by one, while each set of interfaces share a clock? (ie ICSSG0 PRU0 and PRU1 share the same clock...but I am taking them down and back up one by one). And if so, is there a better way to ensure consistent interface naming on bootup?
Edit2: Indeed it would appear that bringing down the interface and renaming it is the root of the issue here. Not too surprising given the previous thread. On startup this time I only did the renaming procedure for PRUs 1-4 and do not take down ICSSG2 interfaces:
root@am65xx-evm:/home# ./phc_ctl eth5 get
phc_ctl[11626.194]: clock time is 1679767534.483117760 or Sat Mar 25 18:05:34 2023
root@am65xx-evm:/home# ./phc_ctl pru1 get
phc_ctl[11628.516]: clock time is 1679767536.818157608 or Sat Mar 25 18:05:36 2023
root@am65xx-evm:/home# ./phc_ctl pru1 get
phc_ctl[12720.991]: clock time is 1679760240.685721520 or Sat Mar 25 16:04:00 2023
root@am65xx-evm:/home# ./phc_ctl eth5 get
phc_ctl[12724.160]: clock time is 1679768632.448268308 or Sat Mar 25 18:23:52 2023
