Dear NXP members,
This ticket may be related to the following topics:
SJA1110-Qbv-AdminBaseTime-Configuration
During the configuration of Qbv on the SJA1110 switch present in the S32G-VNP-RDB3 board, I have been using the SJA1110 SDK for S32G from NXP for setting the gPTP/Qbv parameters, compiling the new sja1110_uc.bin file, and deploying it on the firmware folder of the A-core Linux BSP.
Initially, I have been using the PFE0 interface (SJA1110 switch Port 4) as the gPTP grandmaster, with ADMINBASETIME set to 0. I performed some tests and validations and everything indicates that it behaves as expected.
However, during the course of the project, I had to reassign the roles so that now the gPTP grandmaster would come from an external device which is connected to the Port 3.
From the moment I would connect this external device, the Qbv performance would behave quite erratically.
I did some tests starting with large cycle values, for instance:
Cycle = 1 sec -> 125000000
CycleExt (12.5%) = 15625000
segment 1 = 0.25 sec TCs 0 and 1 GATESTATUS 1 and 0
segment 2 = 0.25 sec TCs 2 and 3 GATESTATUS 6 and 7
segment 3 = 0.25 sec TCs 4 and 5 GATESTATUS 2 and 3
segment 4 = 0.25 sec TCs 6 and 7 GATESTATUS 4 and 5
port 3: TRIGGER_TIME = 1250000 (2x625000)
port 4: TRIGGER_TIME = 3125000 (4x781250)
ports 5...: TRIGGER_TIME = 125000For testing, I send UDP packets from the client (S32G PFE0 interface) to another Linux device connected on the same network acting as server.
I capture the packets using the tcpdump tool on the server side, and analyze the results.
In this case, the transmission would start after a few seconds, but once started, it would behave correctly (1 second cycle, 25% for the given traffic priority):
Then, I used the GATESTATUS division into four segments, but reduced the cycle time to 200 ms:
Cycle = 200ms -> 25000000
CycleExt = 3125000
segment 1 = 50 ms TCs 0 and 1 GATESTATUS 1 and 0
segment 2 = 50 ms TCs 2 and 3 GATESTATUS 6 and 7
segment 3 = 50 ms TCs 4 and 5 GATESTATUS 2 and 3
segment 4 = 50 ms TCs 6 and 7 GATESTATUS 4 and 5
port 3: TRIGGER_TIME = 250000
port 4: TRIGGER_TIME = 625000
ports 5...: TRIGGER_TIME = 25000It would work, but I needed to start between 30 seconds and 2 minutes for the transmission of the packets start.
In the subsequent tests, I observed the same pattern:
- When the cycle time was reduced to 100 ms, I would have to wait between 2 and 4 minutes before transmission started;
- When the cycle time was reduced to 50 ms, I would have to wait between 5 and 6 minutes before transmission started.
And so on. So, the shorter the cycle length, the larger the wait time before Qbv effectively started. Until then, the traffic was blocked.
But there is another weird behavior observed when I did the following configuration:
Cycle = 0.5 ms -> 62500
CycleExt = 7812
segment 1 = 30 μsec TCs 0, 1, 2, 4, 5, and 7: GATESTATUS 0, 1, 2, 3, 5, 6, and 7
segment 2 = 300 μsec TC 6: GATESTATUS 4
segment 3 = 170 μsec TCs 0, 1, 2, 4, 5, and 7: GATESTATUS 0, 1, 2, 3, 5, 6, and 7In this case, all of the traffic would pass except TC6.
When I invert the configuration:
Cycle = 0.5 ms -> 62500
CycleExt = 7812
segment 1 = 30 μsec TC 6: GATESTATUS 4
segment 2 = 170 μsec TCs 0, 1, 2, 4, 5, and 7: GATESTATUS 0, 1, 2, 3, 5, 6, and 7
segment 3 = 300 μsec TC 6: GATESTATUS 4in this case, only the TC6 traffic would be transmitted while the other TCs would be blocked.
From my opinion, it points in the direction of the time synchronization issue.
Here is how I have configured gPTP on the S32DS:
It is also worth mentioning that this external gPTP Grandmaster provides Sync timestamps based on the current Unix epoch:
While when the PFE0 was used as the Grandmaster, it would provide Sync timestamps starting with 0:
What would explain this behavior?
Thank you for your support!
Best regards,
Guilherme
Hello @GuilhermeS32G ,
Yes, please wait to get access. Besides NDA, Automotive Ethernet belongs to export control policy.
In my opinion, the ECT tool is a great source of code related to switch's dynamic reconfiguration.
Yes, split the Unix epoch gPTP timestamp into ADMINBASETIME[0:31] and ADMINBASETIME[32:63] is the right way.
Best regards,
Pavel
Hi @PavelL ,
Thank you for your response.
Indeed, this ECT tool seems to be the right way to go.
However, I still have no access for downloading it. It says: "SJA11XX Standard Software - Your Request form has been received". I may need to wait for some time to see if I can get access.
In the meanwhile, just to clarify, let's say the current Unix epoch (with nanoseconds) is:
1784013205012345678
Which represents, in UTC:
Tuesday, July 14, 2026 at 7:13:25 AM
What is the correct way to split this timestamp into ADMINBASETIME[0:31] and ADMINBASETIME[32:63]?
Best regards,
Guilherme
Hello @GuilhermeS32G ,
Thank you for creating a follow up thread - it help us to keep clarity on cases.
Thank you for sharing all the details and test results at once.
I checked provided data and your gPTP configuration appears to be correct.
Therefore, for this use case, I would recommend configuring ADMINBASETIME dynamically based on the current synchronized PTP/gPTP time (and still using a fixed value of 0 in the static configuration).
A typical sequence would be:
1. Start gPTP and wait until the switch is synchronized to the external Grandmaster.
2. Read the current PTP clock from the switch.
3. Set ADMINBASETIME to a future time value, for example current PTP time + sufficient safety margin.
4. Write the TAS/Qbv administrative parameters.
5. Trigger the TAS/Qbv configuration change.
Best regards,
Pavel