AM6422: Freertos CPSW SWITCH 1588

Hello,

    Thank you very much for your reply. We have now run the program on both terminals and connected them directly via an Ethernet cable. Time synchronization has been achieved, but the synchronization accuracy is far better than 1 microsecond. Below is the printed time synchronization information. What could be the cause of this?

Hi,

Is this the case with the examples running for 1 minute after identifying the nodes, and starting the sync? Can you please confirm the revision variant of the AM64x EVM that you are using? Usually, the sync accuracy is between 50-100ns. But this could vary based on the crystal oscillator and the supporting circuitry, which AM64x Rev-D and later versions are known to have.

By identifying this, we can provide an alternative to unblock you from this issue.

Thanks and regards,
Teja.

Hello，

    Such test results are not only observed after running for one minute; I tried observing for half an hour, and during this period, there were instances where the time synchronization offset exceeded 1 microsecond, then it returned to within 1 microsecond, and after some time, it occurred again. We are using a self-developed board, but the hardware circuit structure is consistent with the AM64EVM, and the SDK version used is SDK9.2. What is the specific reason for this?

Hello，

    We haven't worked with 1588 before and would like to understand the process using the provided gPTP protocol example. What we're particularly curious about is how to obtain the corresponding absolute time—that is, year, month, day, hour, minute, second, millisecond, and microsecond. Is there a specific function that can be called directly? If we want to implement 1588 time synchronization on R5F1-0 and then have R5F0-0 obtain the time from R5F1-0, is there a way to achieve this with time synchronization accuracy ideally at the microsecond level, not exceeding 10 microseconds? We would appreciate some suggestions.

Hi,

I would request you to check what is the reference design board version your team used to bring up your custom board. If it is based on Rev-D or later, it is a known issue that PTP sync accuracy is getting impacted, due to unexpected noise in the clocking circuitry. So, please check the baseline board revision number. 

Along with it, it is also advisable if you can check the behavior with the AM64x-EVM (not the custom board) and check the findings. This will be helpful in understanding the setup. 

I will cross check the gptp sync accuracy possible with 09.02 SDK again to be sure.

Regards,
Teja.

Hi,

I would like to also clarify again, that the 1588 protocol and gPTP protocols are not completely inter-operable. Only few implementations of 1588 will be interoperable with gPTP.

wanglili 王 said:

Is there a specific function that can be called directly?

Moving ahead, as mentioned earlier, we would need to obtain the absolute time from the GPS module, which will send the current time info along with the PPS signal to sync the time.

wanglili 王 said:

If we want to implement 1588 time synchronization on R5F1-0 and then have R5F0-0 obtain the time from R5F1-0, is there a way to achieve this with time synchronization accuracy ideally at the microsecond level

One way to transport the time info between the cores is to use IPC to exchange the current time between the cores. If this approach is not viable with your design, then we can find other methods to obtain the current time within your accuracy requirements.

Thanks and regards,
Teja.

Hello，

    The hardware schematic we refer to is shown in the figure below.

    Ignoring GPS for now, is there a function to simply obtain the system absolute time? When running the gPTP example, time values are definitely transmitted. Where are these values obtained from?

    This IPC mode cannot achieve the 10μs precision we need. Is there any other way?

Hello，

    We are considering using the gPTP protocol to output PPS pulses, which can be provided to the R5F0-0 core. Then, the R5F1-0 core can provide the coarse second time, and this level of precision should meet our requirements. I noticed that the gPTP example itself includes handling for pulse output, but the corresponding output pulse frequency is 3.814 kHz. We want to output a 1 Hz waveform. According to the provided formula, setting the corresponding bit to 28 or 29 does not yield an exact 1-second interval, which would introduce errors. Is there another way to achieve this functionality?

Hello,

    Do you have any solutions to offer regarding the issue I mentioned?

Hello,

    The issue we are currently facing is quite urgent, as it will determine our subsequent design plans. We would appreciate it if you could provide some suggestions.

Hi,

Yes, there is another way to configure the output for generating 1Hz using GENF module in the CPTS hardware. Currently, the feature is not demonstrated in our SDK, but can be enabled. 

We are currently working on enabling similar utility as part of our activities. We can provide a sample code if needed to enable this. A tested and validated example will need more time to be available publicly.

Thanks and regards,
Teja.

Hello，

    I’m glad to hear that. Regarding the GENF output, we have also considered it, and now we would like to confirm a few points with you:

Hi,

1. The GenF is corrected along with CPTS clocks when enabled, and additional corrections are not needed.
2. We can configure the genF correction to start at a future point, and you can calculate the future time based on the current time+(offset to make all zeroes).
3. You can use the output signal from R5_0_1 to be routed either externally, or through IPC to trigger the R5_0_0 core. 
4. I will have to check the gPTP behavior with 100M link. We can achieve <50ns accuracy with 1G link. 
5. I would have to check internally with the reported issues and corresponding fixes. Since the goal is to be interoperable with other devices, I would need to run through the documentation and open issues. It is generally suggested if you can pick up the latest SDK possible.

Regards,
Teja.

Hello,

    Regarding the use of GenF output configuration, I hope you can provide some guidance. As for configuring the GenF correction to start at a future point in time, how should this be set up? We are currently a bit confused about this part, and if possible, we would appreciate it if you could give specific operational suggestions.

Hello，

    We are currently experiencing some issues with the output pulse:

1. After two AM6422 devices are connected via Ethernet, one is set as the master clock and the other as the slave clock. The print information shows that they are synchronized, but when we use the EnetApp_enableTsSync function to output a pulse on bit 17, the rising edges of the two output pulses have a large error. Our understanding is that this pulse cannot be used to verify the synchronization accuracy between the two devices, because their output timing is uncertain. After synchronization, the pulse widths of the two devices are basically the same, but the rising edges may not be aligned. Is that correct? If so, what method should be used to verify the time difference between the two devices?

2. We currently do not plan to update the SDK version. We would like you to provide the relevant modifications related to GenF output in this version and any changes that could affect time synchronization accuracy beyond 2 µs.

3. Currently, we can output a pulse via GenF, but we encountered problems when locating the rising edge of the pulse, resulting in a large error (millisecond level) between the two devices after synchronization. Regarding the GenF‑related code below, is there any incorrect operation? Additionally, a question: you previously mentioned that the GenF output follows CPTS changes, so there is no need to consider the frequency adjustment of CPTS by the gPTP protocol. However, when we look for the next whole‑second moment, we first read the current time and then calculate the next whole‑second count based on the frequency. Since this frequency is constantly changing, can the output still be guaranteed to be accurate?

4. .Previously, you mentioned reading the current system time, and the provided code uses the IOCTL method to do so. However, this execution time is relatively long. Will this affect the accuracy of the read time? Is there another way to read the current absolute system time?

5. .Regarding the CPTS registers, when R5F1-0 is using them, can R5F0-0 read their values to obtain the current system time?

6. .Regarding the time synchronization method between the two cores mentioned earlier, do you have any alternative solutions other than IPC that can achieve synchronization accuracy within the microsecond level?

7. .Our design also includes GPS. Is it possible to use GPS time as the reference to synchronize the device, and then run gPTP in master mode to synchronize other devices? What are the key steps to achieve this? How should we proceed with this design?

   The figure below shows the GenF pulses generated by our two devices. The pulse width is 1 second for both, but when measured using a logic analyzer, the distance between the rising edges is several hundred milliseconds. One period is 1.00000009 seconds, and the other is 999.99474 milliseconds, indicating that the two devices are clearly not synchronized. However, at this point, the printed information shows that the time difference between them is within 1 microsecond.
   

   

Hello,

    We encountered another issue during testing. There are three AM6422 units in the system, labeled A, B, and C. A serves as the master clock and synchronizes time with B and C. A is connected to one CPSW switch port of B via an Ethernet cable, while another port of B is connected to C. The gPTP example program is running. The print information from B shows normal synchronization, but the print information from C consistently displays an error, as shown in the figure below. We suspect this is a processing error where B, after completing time synchronization as a slave, acts as a master clock to synchronize time with C. We hope you can help confirm the cause of this issue.

Hello，

    The issues we are currently facing have affected our plans, and we hope you can provide technical support. Thank you very much！

Hi,

We have identified that the MCU+ SDK currently doesn't support GENF corrections directly. We have created a patch for it based on the latest 11.02 MCU+ SDK to enable this functionality. You can use the below patch to enable the genf corrections and the corresponding application changes to route the signal out. The patch is configured for 40kHz. Please change it to 1Hz for your usecase.

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/908/1460.0001_2D00_Add_2D00_genf_2D00_corrections_2D00_to_2D00_cpts_2D00_corrections.patch

Thanks and regards,
Teja.

Hello，

    How about the other question?Can you provide some technical support?

Hi,

wanglili 王 said:

The gPTP example program is running. The print information from B shows normal synchronization, but the print information from C consistently displays an error, as shown in the figure below

Are you referring to this question? If yes, then we haven't encountered this before, and We were able to achieve sync with 4 nodes linked in daisy chain as part of our earlier testing. We are planning to reproduce this issue in our test bench. If this is reproducible on our setup, we would be able to root cause this and identify a fix for the same.

Thanks and regards,
Teja.

Hello，

    Yes, this issue occurred after we ran the SDK9.2 example on three nodes. Is the Genf output you provided based on SDK11? Can the output second pulse achieve a timing where both milliseconds and microseconds are zero?When adjusting CPTS, does the pulse width also change accordingly?

Hi

wanglili 王 said:

Can the output second pulse achieve a timing where both milliseconds and microseconds are zero?

You can set the signal to start at any future time, down to 5 nanosecond precision. You would have to use the 'inArgs.compare' field to set the start time. You would have to calculate the future tick count when the time is as per your requirements, and set the value to that. 

wanglili 王 said:

When adjusting CPTS, does the pulse width also change accordingly?

The pulse width changes at nanosecond level, and the accuracy is in the range of +/-50ns. This means there would be corresponding change in the pulse width, again, at nanosecond level.

We are currently investigating the warning logs in the third node, and will update you in the findings. But in our setup running on 11.2 SDK, we couldn't reproduce the large diff issue, and we are observing the accuracy to be close to +/-50ns. Could you please let us know if you were able to achieve similar accuracy in any of your setup? Can you try running the example on TI EVM as well along with your custom board?

This will help us triangulate the issue better

Regards,
Teja.

Hello，

    When operating at 100 Mbps, we can observe cases below 50 ns through the printed information, but during operation there have indeed been instances exceeding 2 μs. Since the evaluation board we purchased is damaged, we cannot continue testing on it; I am sorry about that. However, the hardware we designed ourselves is fully consistent with the evaluation board in terms of schematic.Regarding the issue with the three terminals mentioned above, if one port of B synchronizes with A, the other port of B will then run as a master clock to synchronize C. In this case, should the PTP messages sent from A to B no longer be forwarded to port C via the CPSW switch?

    We have an assumption: after configuring GENF, the pulse starts output at the next integral second moment of the current time—i.e., when both milliseconds and microseconds are zero—with a pulse period of 1 second. After that, it will automatically output at this period without requiring any further configuration. So, is it correct to understand that this pulse should be output only after time synchronization is achieved? If the pulse is output right at the beginning of the program, would that be inconsistent with what we want?

Hello，

    I just ran the gptp_cpsw_lwip example with SDK11.2, and the same printed messages appear when there are three terminals.

Hi,

wanglili 王 said:

In this case, should the PTP messages sent from A to B no longer be forwarded to port C via the CPSW switch?

This is correct. The packets shouldn't reach the other end, and need to be dropped at the middle board. This can be fixed by adding an ALE entry to stop forwarding unnecessary packets between ports. This can be enabled by this pach.

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/908/stop_5F00_ptp_5F00_mcast_5F00_fwd.patch

But we are not observing the high diff between the master and the board away from the master, which is receiving 2 ptp sync packets earlier. Please confirm this behavior.

Further, if the example is having high difference in your board, then we have to look at the hardware config since we are not able to reproduce this from our end. This has been verified in our testing over 2 days, and we haven't observed higher that +/-80ns difference between the signals, even with three boards. 

Let us know if you have any further queries on this topic.

Thanks and regards,
Teja.

Hello，

    Through the modifications you provided, time synchronization among three nodes can now be achieved. However, there is a question: when the provided function is executed after
EnetApp_addMCastEntry(gEnetAppParams.enetType, gEnetAppParams.instId, EnetSoc_getCoreId(), BROADCAST_MAC_ADDRESS, CPSW_ALE_ALL_PORTS_MASK);
it does not take effect.

But when the function is executed after EnetApp_setupNetworkStack();it works. What is the reason for this?

    Regarding the issue of a large time difference, may I ask whether you have used a 100M rate for precision? Is there any data available for this aspect?

Hello，

    Among the patches you sent later, there is also Genf-related configuration. I received two patches in total. Which one has been verified on your side to be able to output a whole-second pulse? If possible, could you send an example.syscfg file?

Hi,

wanglili 王 said:

when the provided function is executed after
EnetApp_addMCastEntry(gEnetAppParams.enetType, gEnetAppParams.instId, EnetSoc_getCoreId(), BROADCAST_MAC_ADDRESS, CPSW_ALE_ALL_PORTS_MASK);
it does not take effect.

Can you please clarify which function you are pointing to? If it is referring to stop_ptp_mcast_fwd.patch, then this has to be applied ideally after the lwip and TSN stacks are initialised so that this entry would not be overwritten to another config.

wanglili 王 said:

Regarding the issue of a large time difference, may I ask whether you have used a 100M rate for precision?

We have ran the tests at both 1G and 100M across all 3 boards. We are not able to reproduce the issue on our end. We are only observing a maximum difference of upto +/-80 ns.

wanglili 王 said:

Which one has been verified on your side to be able to output a whole-second pulse?

The patch which is sent earlier, the one mentioned below, is for maintaining sync between multiple boards while using genF. Without this, genf would drift out of sync. 

Teja Rowthu said:

1460.0001-Add-genf-corrections-to-cpts-corrections.patch

The patch I shared yesterday, which is the below mentioned one, will prevent the PTP sync messages from being forwarded between the ports, thus avoiding/eliminating the warning messages seen earlier in your setup.

Teja Rowthu said:

stop_ptp_mcast_fwd.patch

Please let me know if you have any further queries.

Thanks and regards,
Teja.

Hello,

    We are now able to output a PPS pulse, and the pulse width is similar between the two nodes after synchronization. This means that the pulse output has taken effect along with the frequency adjustment by CPTS, which is a great progress and gives us a lot of confidence. However, there are still some issues that require your technical support. In theory, we can compare the synchronization error between the two nodes by looking at the rising edge of the pulse. But currently, the position of the pulse edge varies depending on the power‑up sequence of the nodes. The figure below shows the difference in the rising edge of the whole‑second pulse after two separate power‑up events. What should we do to achieve our requirements in this regard?

Below are the second pulse rising edges corresponding to the two power‑up events. Our purpose is to use this rising edge to simultaneously trigger different terminals to perform the same operation.

    In the case where the time synchronization error has a large value, we are using the default configuration for the PHY, specifically the DP83867. Is there anything special about this part?

Hi,

We didn't observe this specific behaviour in our boards. But let us recheck this and get back to you about this topic.

Regarding the phase match, the expectation is that the user would have to start the two boards with in the time frame of 1 second. We can update this to be upto few seconds of difference. This can be found in the genf correction patch provided earlier, where we set the genfArgs.compare input based on currentTsVal time stamp. By adjusting the calculated value, the boards can be made to start outputing the signal at multiples of 5 or 10 seconds, so that there is enough time to start both examples within that time frame. 

An easier and preferred method is to flash the example in ospi flash memory, and booting from ospi mode, and powering on both boards simultaneously. This ensures phase match on output signals. 

Thanks and regards,
Teja.

Hello，

    Could the issue be resolved by outputting only after both terminals have achieved synchronization? However, if one terminal loses power during operation while the other continues running normally, will the rising edges of the second pulses become inconsistent again when the powered-off terminal is restarted? How should this situation be addressed?Which variable value should be accurately used as the condition for determining that the two terminals have achieved synchronization?

Hi, 

I think this should be possible with some variations with the application and the stack. Let me go through the example flow, and check for possibilities to make consistent phase lock.

Thanks and regards,
Teja.

Hello，

    Thank you very much for your technical support. We have another question: regarding the IOCTL function, if we want to read the current time in an interrupt, is it inappropriate to use
ENET_IOCTL_SET_OUT_ARGS(&prms, &ts64);
ENET_IOCTL(hEnet, EnetSoc_getCoreId(), ENET_TIMESYNC_IOCTL_GET_CURRENT_TIMESTAMP, &prms, status);?
Is there another way to directly obtain this value in an interrupt?

Hello，

    We currently have a requirement regarding CPTS. We connect an external pulse signal to pin E14, which according to the datasheet supports the CP_GEMAC_CPTS0_HW1TSPUSH function. We want to capture this pulse using CPTS and read the corresponding timestamp in an interrupt. However, this functionality is not currently working. We hope you can help us.Below is the code we are using. We added this code on top of the gPTP protocol. Is there anything incorrect in the code below? Our goal is to process the captured timestamps in the App_cptsEventCb function. The Ethernet TX/RX timestamps are not handled here and should not affect the operation of the gPTP protocol.

int32_t InitializeCPTS_WithGenF()
{
    int32_t status;
    uint32_t coreId = EnetSoc_getCoreId();
    Enet_IoctlPrms prms;
    CpswCpts_RegisterStackInArgs regStackInArgs;
    Enet_Handle hEnet = Enet_getHandle(gEnetAppParams.enetType, gEnetAppParams.instId);

    regStackInArgs.eventNotifyCb    = App_cptsEventCb;
    regStackInArgs.eventNotifyCbArg = NULL;   // pass app context here if needed

    ENET_IOCTL_SET_IN_ARGS(&prms, &regStackInArgs);
    ENET_IOCTL(hEnet, coreId, CPSW_CPTS_IOCTL_REGISTER_STACK, &prms, status);
    if (status != ENET_SOK)
    {
        EnetAppUtils_print("Failed to register CPTS event callback: %d\r\n", status);
        return status;
    }

    EnetAppUtils_print("CPTS event callback registered\r\n");
    return ENET_SOK;
}
uint64_t ceshival[100],ceshivalcnt=0;
static void App_cptsEventCb(void *cbArg, CpswCpts_Event *eventInfo)
{
    /* This callback runs in interrupt context — no blocking calls, no printf. */
    if (eventInfo->eventType == CPSW_CPTS_EVENTTYPE_HW_TS_PUSH)
    {
        /* GENF compare match: output has toggled.
         * eventInfo->tsVal holds the 64-bit CPTS timestamp of the toggle.
         * Signal a task or set a flag here; do not call printf or any
         * blocking/locking API from this context. */
        ceshival[ceshivalcnt++] = eventInfo->tsVal;
        if(ceshivalcnt>=100)
            ceshivalcnt = 0;
    }
    my_count++;
}
static Pinmux_PerCfg_t gPinMuxMainDomainCfg_Modify[] = {
    /* GPIO1 pin config */
    /* GPIO1_61 -> MCAN0_RX (B17) */
    {
     PIN_MCAN0_RX,
     ( PIN_MODE(3) | PIN_INPUT_ENABLE | PIN_PULL_DISABLE )
    },
    /* GPIO1 pin config */
    /* GPIO1_57 -> UART1_TXD (E14) */
    {
     PIN_UART1_TXD,
     ( PIN_MODE(5) | PIN_INPUT_ENABLE | PIN_PULL_DISABLE )
    },
    {PINMUX_END, PINMUX_END}
};
void PPS_Gpio_Modify(void)
{
    Pinmux_config(gPinMuxMainDomainCfg_Modify, PINMUX_DOMAIN_ID_MAIN);
}
int32_t ConfigurePPSIn()
{
    int32_t status;
    uint32_t coreId = EnetSoc_getCoreId();
    Enet_IoctlPrms prms;
    CpswCpts_SetFxnGenInArgs genFArgs;
    uint64_t tsCompVal;
    uint32_t genFLength;
    uint64_t currentTs = 0;
    CpswCpts_RegisterHwPushCbInArgs hwPushArgs;
    struct tisci_msg_rm_irq_set_req     rmIrqReq;
    struct tisci_msg_rm_irq_set_resp    rmIrqResp;

    Enet_Handle hEnet = Enet_getHandle(gEnetAppParams.enetType, gEnetAppParams.instId);


    rmIrqReq.valid_params           = 0U;
    rmIrqReq.valid_params          |= TISCI_MSG_VALUE_RM_DST_ID_VALID;
    rmIrqReq.valid_params          |= TISCI_MSG_VALUE_RM_DST_HOST_IRQ_VALID;
    rmIrqReq.global_event           = 0U;
    rmIrqReq.src_id                 = 6U;  // TISCI_DEV_TIMESYNC_EVENT_INTROUTER0
    rmIrqReq.src_index              = CSLR_TIMESYNC_EVENT_INTROUTER0_IN_PINFUNCTION_CPTS0_HW1TSPUSHIN_CPTS0_HW1TSPUSH_0; // input 12
    rmIrqReq.dst_id                 = 6U;  // TISCI_DEV_TIMESYNC_EVENT_INTROUTER0
    rmIrqReq.dst_host_irq           = 30;//TIMESYNC_OUT_HW_EVENT0; // output 31: CPTS HW_PUSH input
    rmIrqReq.ia_id                  = 0U;
    rmIrqReq.vint                   = 0U;
    rmIrqReq.vint_status_bit_index  = 0U;
    rmIrqReq.secondary_host         = TISCI_MSG_VALUE_RM_UNUSED_SECONDARY_HOST;


    status = Sciclient_rmIrqSetRaw(&rmIrqReq, &rmIrqResp, SystemP_WAIT_FOREVER);
    if (status != ENET_SOK)
    {
       EnetAppUtils_print("TSR pin: %d routing failed: %d\r\n",
                   rmIrqReq.dst_host_irq, status);
    }
        /*hwPushArgs.hwPushNotifyCb    = getTsval;
        hwPushArgs.hwPushNotifyCbArg = (void *)hEnet;
        hwPushArgs.hwPushNum         = CPSW_CPTS_HWPUSH_1;

        ENET_IOCTL_SET_IN_ARGS(&prms, &hwPushArgs);
        ENET_IOCTL(hEnet, coreId, CPSW_CPTS_IOCTL_REGISTER_HWPUSH_CALLBACK, &prms, status);*/
    return status;
}
    PPS_Gpio_Modify();//Enable here
    InitializeCPTS_WithGenF();
    ConfigurePPSIn();

Hello,

    We have made a change to the example program. Originally, it ran on the R5F0-0 core, but now we want to run this part of the program on the R5F1-0 core. We have added relevant configurations and code to the R5F1-0 example program. Currently, the compilation has no issues. We flashed the program from the default_sbl_null.cfg configuration file using serial mode, connected to the R5F1-0 core with an emulator, and after running the flashed program, it enters the assert function after executing EnetApp_driverOpen(gEnetAppParams.enetType, gEnetAppParams.instId). The displayed content is shown in the figure below. Tracing the program, we found that in the Udma_rmAllocMappedRxCh function, the condition in the figure below is not satisfied, where both rmInitPrms->startMappedRxCh[mappedChGrp] and rmInitPrms->numMappedRxCh[mappedChGrp] are 0, causing DMA failure. Could this error be due to the Ethernet DMA resources not being allocated to the R5F1-0 core? We would greatly appreciate your technical support. Thank you very much!

Hi,

For obtaining the current time, you can use the "ENET_TIMESYNC_IOCTL_GET_CURRENT_TIMESTAMP" API but it only gives the base reference time from CPTS, and it will not tell the UTC time format which you expect. 

wanglili 王 said:

We want to capture this pulse using CPTS and read the corresponding timestamp in an interrupt. However, this functionality is not currently working

We will try to reproduce this issue and inform you about the results. Please make sure you are using the correct instance of CPTS, and hw push event number to configure the interrupts.

wanglili 王 said:

Originally, it ran on the R5F0-0 core, but now we want to run this part of the program on the R5F1-0 core.

This needs some changes to the resource configuration such that the application would have the CPSW resources available to it. But currently, out of box, only R5FSS_0_0 is supported. You can change the ownership to R5FSS_0_1 in the resource configuration to make the example compatible with the new core. You can refer to this documentation under the SW pre-requisites for the process to update the resource configuration: https://www.ti.com/lit/an/spradh8/spradh8.pdf

Please let us know if you need further support on resource configuration.

Thanks and regards,
Teja.

Hello,

    Thank you very much for your reply. Can the command ENET_TIMESYNC_IOCTL_GET_CURRENT_TIMESTAMP be used in an interrupt context? If so, we can directly read the nanosecond value and perform the conversion ourselves. We are using the CP_GEMAC_CPTS0_HW1TSPUSH pin (E14) of the CPSW CPTS module. Is there any incorrect configuration in our code that prevents us from capturing the external pulse? We look forward to your support.

    We would also like to know whether, after reconfiguring the resources, it is feasible for r5f0-0 to run ICSSG Ethernet and r5f1-0 to run CPSW Ethernet. In particular, are there any conflicts with respect to DMA resources?

Hello,

    We have successfully implemented CPSW operation on R5F1-0, and gPTP is also running normally. Now we have two urgent issues to resolve:

1. We configured the E14 pin as CP_GEMAC_CPTS0_HW1TSPUSH, intending to use it as an input to capture a pulse signal and record its timestamp via CPTS. However, this has not yet been achieved. Is there something incorrect in our previous code configuration? We would appreciate your technical support on this.

2. In an interrupt context, is it possible to read the current CPTS counter value (or nanosecond value) via an IOCTL function?

Hello，

    "Has there been any new progress on the issue mentioned earlier? Currently, we want to achieve master-slave clock switching during runtime based on gPTP. What approach can we use? This part of the code is too complex for us. We hope you can provide technical support. Thank you very much!"