Connectivity issue in SJA1110 Dear NXP members, This ticket may be related to the following topics: SJA-1110-Configuration-of-Qbv 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 = 125000 For 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): Screenshot 2026-07-08 084413.png 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 = 25000 It would work, but I needed to start between 30 seconds and 2 minutes for the transmission of the packets start. Screenshot 2026-07-08 085025.png 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 7 In 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 4 in 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: Screenshot 2026-07-08 090805.png Screenshot 2026-07-08 091033.png It is also worth mentioning that this external gPTP Grandmaster provides Sync timestamps based on the current Unix epoch: Screenshot 2026-07-01 110153.png While when the PFE0 was used as the Grandmaster, it would provide Sync timestamps starting with 0: Screenshot 2026-07-08 091440.png What would explain this behavior? Thank you for your support! Best regards, Guilherme Re: Connectivity issue in SJA1110 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 Re: Connectivity issue in SJA1110 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 Re: Connectivity issue in SJA1110 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.
Based on your observations, the behavior strongly suggests that the issue is related to the Qbv schedule activation time rather than to the gate list entries themselves. If the ADMINBASETIME being configured as 0 while the external gPTP Grandmaster provides an epoch-based PTP time value, ADMINBASETIME = 0 is far in the past relative to the current synchronized gPTP time domain and the switch needs to resolve the Qbv change/start time based on that value. This may lead to unexpected schedule activation behavior compared with a setup where the PTP time starts close to zero, and it is therefore safer to program ADMINBASETIME as a future value in the currently synchronized PTP time domain.
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.
You may use the ECT server implementation as a reference. In particular, please check file udp_traffic.c ; routine udpReceiveCallback() . It doesn't matter if you use SDK or RTD version of ECT server.
PavelL_0-1783939380327.png
In the TAS configuration handling, the ECT server (SDK version) reads the current PTP time using SWITCH_DRV_GetPtpClk(), assigns this value to the TAS baseTime, adds a margin of 2 seconds, and then calls SWITCH_DRV_WriteTasAdminParameters() followed by SWITCH_DRV_ChangeTasConfig().
This approach avoids using ADMINBASETIME = 0 and aligns the Qbv schedule activation with the actual synchronized PTP time domain.
Best regards,
Pavel
View full article
