Clock setting issue on Drive AGX Xavier upon set up

Autonomous Vehicles DRIVE AGX Xavier DRIVE AGX Xavier General
,
1

Please provide the following info:
Hardware Platform: [Example: DRIVE AGX Xavier™ Developer Kit]
Software Version: [Example: DRIVE Software 10 Rev.2]
Host Machine Version: [native Ubuntu 18.04]
SDK Manager Version: [Example: 1.3.1.7110]

I am setting up AGX Xaiver with host machine. I was following the set up video

I was able to do everything suggested in the video with minor differences

(1) I start from 18.04 and a clean installation of the SDK (host and target)
(2) I flashed the target at the end of the SDK manager installation, and instead of the magic “64.4%” shown in the video, my system appear to be stuck at 99% for quite a while and once Dev system boot up again, I wasn’t given any steps for running scripts, only goes directly to the desktop. And the desk top looks very lean with only the core of the ubuntu, and fancy tools missing.

Then I keep having the clock issue as described in the following topic by developer “s10”.

I am having the same connection of RTC and ethernet connection as “s10”. But I fail to find any answers to resolve “s10”'s issue.

I am having almost the same phenomena:
the clock was initially 2017 some dates and I cannot change it manually (it changes back right away after I change it), and putting into automatic sync with internet would not change things.

The only difference I have is that I can confirm that I do have internet access, as I have attempted
ping time.google.com -c 5

and I got proper reply backs.

64 bytes from time4.google.com (216.239.35.12): icmp_sqe = 1 ttl = 97 time=23.1ms
64 bytes from time4.google.com (216.239.35.12): icmp_sqe = 2 ttl = 97 time=23.1ms
64 bytes from time4.google.com (216.239.35.12): icmp_sqe = 3 ttl = 97 time=23.3 ms
64 bytes from time4.google.com (216.239.35.12): icmp_sqe = 4 ttl = 97 time=25.0 ms
64 bytes from time4.google.com (216.239.35.12): icmp_sqe = 5 ttl = 97 time=23.0 ms

— time.google.com ping statistics —
5 packets transmitted, 5 received, 0% packet lost, time 4005ms
rtt min/avg/max/mdev = 23.044/23.533/25.008/0.761ms

I have also attempted the

sudo bash /usr/local/sbin/canrtc.sh set
sudo bash /usr/local/sbin/canrtc.sh get
sudo bash /etc/systemd/scripts/nv_rtc_sync.sh

Command went through, but
And it only changed the time to some dates in 2003.

Can some one help out? This has prevent me from installing things and visiting websites.
Thank you!

3

Hi @ChaseCRH,

If the installation was completed, it’s expected. In the video, it’s DRIVE Software 8.0 instead of 10.0.

For the RTC question, it should be because system time got overwritten by phc2sys. Please try with disabling Aurix as PTP master by “gptpoff” command mentioned in Using the MCU Console.

4

Hi VickNV,
thank you for your reply.
I have connect to MCU using serial connector and minicom.
I was able to issue the gptpoff command, as indicated in the shell. However, the issue seems to be remained. The clock doesn’t change and I tried reboot but issue remains.
Any suggestion?
Thanks!

5

After issuing gptpoff on Aurix console, please try on Xavier A if setting system time with “date” command is working and system time won’t be overwritten.

6

In Xavier A I attempted
sudo date --set=“2 DEC 2020 18:12:00”
the command went through
The time changed for 1ish second and then change back to 2003 Dec something.

7

This is what works for us on the default install.

On XavierA

sudo systemctl stop nv_ptp_master.service
sudo ntpdate time.google.com

Verify that the time adjusts and doesn’t get reset.

I learned a little about PTP (the RedHat guides are useful to learn about the ptp4l and the phc2sys commands) then wrote all our own SystemD services so it has logic/flow intended for our use case. IIRC for the original services, the NTP sync didn’t work correctly.

2 Likes
8

Hi ChrisB
thank you for the suggestion.
I issued both commands.
The second return with
14 Dec 18:16:38 ntpupdate[5053]: no server suitable for synchronization found

I suspect it is the internet connection issue, but I
ping time.google.com
it does get reply.
Any thoughts?

Thanks!

9

The commands work on my side.

10

I tried them both and the second one gives the error
14 Dec 18:16:38 ntpupdate[5053]: no server suitable for synchronization found

I thought it is the internet issue but apparently I can still ping google so I don’t know what either might be the reason.

11

You may clarify by running the same command on host system or on target with ip instead of hostname.

12

Hi VickNV,
Just want to make sure I understand your suggestion.
You suggested me to try
sudo systemctl stop nv_ptp_master.service
sudo ntpdate time.google.com
on my host pc
and try
sudo systemctl stop nv_ptp_master.service
sudo ntpdate 216.239.35.0

If so, I tried both.
My Host PC return similar error as
14 Dec 18:16:38 ntpupdate[5053]: no server suitable for synchronization found

For the second one I got the same response as before
14 Dec 18:16:38 ntpupdate[5053]: no server suitable for synchronization found
the IP address I used is the one I got from
ping time.google.com

My host PC and the target machine are both connected to ethernet. They each has an IP address (10.xx.xx.xx) assigned by company network. I can establish ssh from my host pc to AGX using the IP address.
I for sure have internet access with host PC and that’s how I get to post things here.

13

I’m not familiar with ntpdate.
If “sudo ntpdate time.google.com” doesn’t even work on your host system, you may search in internet if any solution for it…

14

Hi VickNV
I have tried multiple ethernet source and I think we have narrow down to a internet issue. The AGX cannot seem to connect to internet properly.

Is there any additional setting (network proxy) that is needed for the AGX in order to connect to internet?
Thank you!

15

Don’t you have the same issue on your host system? Could you clarify it?

16

Hi VickNV,
Sorry I wasn’t making it clear.

I think I was able to confirm with my host PC that this is due to network issue. we also have an Drive PX 2 target machine with us. When plug into the company network, we have the same issue with ntpdate command.

When I shift my PC to a different network (private), the same command

sudo ntpdate time.google.com

come back with correct result and my host PC time is adjusted mildly with

3 Dec 18:36:54 ntpdate[11005]: adjust time server 216.239.35.12 offset -0.014513 sec

This makes me think that ntpdate service is blocked by company server.
This is also suggested by this topic I found

In that topic, I found the following command

sudo date -s "$(wget -qSO- --max-redirect=0 google.com 2>&1 | grep Date: | cut -d' ' -f5-8)Z"

And this command can be used to adjust the time on Drive PX2 to correct ones. However, when I try to issue it in AGX, I got the correct time response

Thu Dec 3 18:40:25 CST 2020

But the AGX system clock remains the outdated one 2003 Dec something.

BTW, our Drive PX2 has the same internet environment as AGX, and it can browse the internet normally after the clock is synced, despite the clock might be wrong when first boot up.

17

Below steps is what’s working on my side. FYI.

on Aurix:
$ gptpoff

on Xaiver A :
$ systemctl stop nv_ptp_master
$ sudo /etc/systemd/scripts/nv_rtc_sync.sh

18

To update my previous reply, just running below command on Xavier A should be enough.
Please try it and let me know. Thanks!

$ systemctl disable nv_ptp_master

19

Thank you VickNV for the update

I issued the following command

systemctl disable nv_ptp_master

It is shown that

Removed /etc/systemd/system/tegra.garget.want/nv_ptp_master.service

Then I issue the time change command that can go through

 sudo date -s "$(wget -qSO- --max-redirect=0 google.com 2>&1 | grep Date: | cut -d' ' -f5-8)Z"

The time changed briefly for a few second, then change back to 2003 Dec 16.

Then I reboot the system, and then try toe reset command again

 sudo date -s "$(wget -qSO- --max-redirect=0 google.com 2>&1 | grep Date: | cut -d' ' -f5-8)Z"

This time, the time is correctly set, and doesn’t seem to change back. So I guess the reboot is necessary?

While I am keep monitoring the status, I was wondering should I do anything to set the RTC module so that my clock is correct upon boot up? I found these in other topics.

sudo bash /usr/local/sbin/canrtc.sh set
sudo bash /etc/systemd/scripts/nv_rtc_sync.sh

Thank you!

20

During system initialization, nv_rtc_sync.service will be involved. That’s why it works after rebooting.

Running the two commands should work even before rebooting.

$ systemctl stop nv_ptp_master
$ systemctl disable nv_ptp_master