jukkar
commented
3 years ago /subsys/net/l2/ethernet/gptp/gptp user api.c line 62
[ The 1020EVK does NOT pass through line 62, unlike the FRDM-K64F ]
/subsys/net/l2/ethernet/gptp/gptp user api.c line 64
What does the "NOT pass" mean here? The line 62 is this one
for (port = GPTP_PORT_START; port <= GPTP_PORT_END; port++) {Do you mean that the in 1020EVK, the for loop is not entered?
~That would mean that GPTP_PORT_END which is (gptp_domain.default_ds.nb_ports + 1) which means that nb_ports variable is 0 which means that the system was not able to find any ptp clock in the system. That would indicate some issue in mcux driver if this is really the case.~
Edit: actually, because how the for loop is written <=, we should always enter the loop.
The gptp subsystem is not board specific so this indicates some issue in mcux driver and/or NXP HAL.
kevin137
MaureenHelm
hakehuang
santi681
aunsbjerg
As you can see, the ATCRval register is reading 0xa91
And here, the ATCR register is reading 0x91, as we think it should be.
ainguraXmarquiegui
reibax-marcus
Description of bug
Problem with the gptp_event_capture() function in the gPTP demo in ZephyrOS on the RT1020EVK: time.second member of net_ptp_time struct is updated correctly, but time.nanosecond is NOT. The same function in the same demo on the FRDM-K64F works correctly.
Background
We are trying to use gPTP (IEEE 802.1AS) on the i.MXRT platform to synchronize timestamps across devices in a sensor network. All the hardware documentation for the i.MXRT and App Notes such as AN12149 (https://www.nxp.com/docs/en/nxp/application-notes/AN12149.pdf) indicate that this should be possible. We are interested in using ZephyrOS because we feel it should work well with the way we develop embedded systems, which are at the moment all based on Linux and Yocto. Zephyr seems to have good network support, and gPTP support, at least on some platforms (https://docs.zephyrproject.org/latest/reference/networking/gptp.html). To kick-start this process, and to evaluate whether gPTP/ZephyrOS/i.MXRT is a good technical solution for synchronization, we asked a graduate student at Universitat Politècnica de Catalunya, Santi Prats, to help us.
Santi advanced significantly, first on installing the SDK and tools, then with compiling Zephyr and applications for i.MXRT and Kinetis, also with PTP and gPTP synchronization purely in Linux. Then he encountered a problem which stumped him and us.
To Reproduce
On the FRDM-K64F board (https://docs.zephyrproject.org/latest/boards/arm/frdm_k64f/doc/index.html), he is able to extract timestamps from the gPTP system with nanosecond resolution. But on the RT1020EVK (https://docs.zephyrproject.org/latest/boards/arm/mimxrt1020_evk/doc/index.html), using the same code, with the same libraries and tools, the nanosecond member of the net_ptp_time struct is NOT being filled, and therefore we are only able able to read the PTP Hardware Clock with a resolution of seconds. Reproducing the issue is as simple as adding a few extra LOG_INF() calls to the gptp demo (see below), compiling it for the RT1020-EVK, flashing it, and running it.
Lightly modified demo code
Build
Run
Expected behavior
The expected behavior is what happens running the same code on the FRDM-k64f:
Note that on the FRDM-k64f, the nanosecond member IS being updated.
Impact We are unable to proceed with the development of the time synchronization element of our new sensor solution because of this issue. Santi is attempting to make equivalent functionality work in FreeRTOS to continue with his academic pursuits, but this is not a great solution for us, because other team members are developing other components of the sensor firmware in Zephyr. We the just getting started with Zephyr; we like what we see so far, but timestamp synchronization with gPTP is at the very heart of what we are trying to do with our sensors--if we can not make it work, we will need to change our strategy. We reached out to NXP through our distributor EBV, and they have confirmed that the gPTP stack and demo should work in Zephyr on the RT1020-EVK. They encouraged us to report the issue here.
GDB / console output
Using the gdb debugger, Santi isolated the differences in the progress of the call to gptp_event_capture to a single line of code that differs between the FRDM-K64F and the MIMXRT1020-EVK. The relevant part of his (attached) document describing the problem follows:
GDB debugging
To investigate the differences between what is happening on the FRDM-K64F and the MIMXRT1020-EVK, the GDB debugger was used. The following was executed from the Zephyr directory:
We enter into "debug mode"
A position is set in the moment just before the execution of
At this instant,
Both return 0. We now step through to see execution of gptp_event_capture()
Before the execution finishes, and analyzing the output of (gdb) step, it is seen that execution passes through the following files and in this order:
Finally,
Now, in the display of the time.seconds member, a correct value is seen, while the time.nanoseconds member still reads 0:
In conclusion, we are seeing the desired behavior on the FRDM-K64F; we are able to read timestamps down to the nanosecond. The same application code, making the same api calls on the RT1020 is not returning nanoseconds, however, and it all seems to come down to line 62 in gptp_user_api.c
Environment:
Zephyr6.pdf