- Ask a related questionWhat is a related question?A related question is a question created from another question. When the related question is created, it will be automatically linked to the original question.
Original question:
TMDXIDK5718: SOF/SyncManager Jitter - PRU-ICSS-ETHERCAT-SLAVE for AM571x_idk
Hello,
I am reposting this inquiry as the previous ones got locked due to inactivity.
I'm encountering what appears to be some sort of jitter with the SOF/SyncManager on my Sitara EtherCAT Slave Controller. I'd like to understand if there is an easy way to perform diagnostic on the Slave Controller. Specifically we are looking for a direct way to measure the SOF signal. Our setup is as follows.
Master:
Slave
We're currently only tracing timings using a GPIO toggle in the interrupt handlers for Sync0/Sync1/SyncManager. We're currently measuring time from SyncManager to Sync0 as ~36us when the expected value is 55us resulting in about 20us jitter from SOF to SyncManaer. When Acontis has measured this timing on an EL9800 board, they do not see such a delay, although they are directly measuring the SOF signal, and not the SyncManager interrupt. Any guidance on how to measure SOF on the Sitara would be of great help.
For reference I'm basing my understanding of SOF timing from this beckhoff documentation.
https://infosys.beckhoff.com/english.php?content=../content/1033/tc3_io_intro/1446579467.html&id=
Regards,
Marvin
Hi Dhaval,
Thanks for the support. I'll work on probing those signals. We did do some debugging since the original query and found that the SOF signal does have about a 20us delay to the actual interrupt occurring in software. For this we measured via pin D7(vout1_d10) and by setting the pinmux in software initialization. So the SOF signal is arriving at the time we expect, but the delay until the hardware interrupt is about 20us.
Hi Dhaval,
Just checking up to see if you had any input on the SOF signal measurement I provided last week. I'm still waiting on some hardware support from our team to get those other measurements.
One thing I did also want to ask is that you noted using the signal pr1_edio_data_outN for measurement. From my understanding of the TMDXidk5718 board PRU1 is not populated for EtherCAT functionality. So in this case we're using PRU2 for our development purposes. Just wanted to check if this is correct.
Hi Dhaval,
Yes I have tried that before but it did not work for me. There was a forum post some time back where another customer had a similar issue.
https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1089006/am5718-idkam571x-ethercat-slave-on-pru-icss1
Also checking the SDK source code it's noted hat PRU1 ETH0 is not wired for the default IDK. The PINMUX options are commented out in the SDK source.
Hi Dhaval,
Still working on getting the Sync0/Sync1/PDI measurements. Not sure if you have any insight on why PRU1 does not work for me even with the provided patch?
Additionally I wanted to bring up another measurement observation we think is related to the Start of Frame Timing.
First some background information. We're running EtherCAT using the Subordinated Cycles mode. Sync0 runs at a rate of 55us, Sync1 runs at 220us. So we have a ratio of 4 Sync0 events to every one Sync1 event.
When measuring events we noticed a discrepancy during controller startup.
At the very start of the Slave receiving Sync interrupts we see the following. The first full cycle(Red) contains 5 Sync0 pulses and 1 Sync1 Pulse. Subsequent cycles(Yellow) are behaving as we expect with only 4 Sync0 pulses to 1 Sync1 pulse.
I set up a read on some of the EtherCAT registers and saw the following. From left to right I'm reading 0x910 System Time, 0x990 Sync0 Next Time, and 0x998 Sync1 Next Time.
Hi Dhaval,
Thanks for the response we really appreciate the assistance. I've outlined some answers below.
1. PRUICSS Instance One
Okay I've removed the J51 header and changed the DEFAULT_PRUICCS_INSTANCE to PRUICSS_INSTANCE_ONE. The Master reports Bus scan error 'Bus configuration mismatch (0x9811001e)', 0 slaves found. Is it possible I would also have to modify the SDK to enable PRU1 eth0 Pinmux as mentioned in my previous post?
2. SOF Jitter
We're measuring the SOF signal directly from the board on pin D7 vout1_d10. The SOF signal arrives at the time as expected from the master, 55us ahead of the next Sync0. However, we don't see a Hardware Interrupt for the PDI_ISR/SyncManager until 20us after the SOF signal is seen. So despite SOF arriving at the time expected, we don't receive the interrupt in software until 20us later. Measurement for this on pin D7 is below.
3. Sync0 Timing at Startup
Yes we only see this happening in the first cycle, after which it is corrected. Notably this is an issue because of the LatchInputSync0Counter variable. This variable is incremented at each Sync0 interrupt, and used to indicate when PDO Input Mapping should occur. The Sync1 interrupt resets this counter, so we only see the issue at startup because of the unexpected extra Sync0 interrupt, thus causing Input Mapping to occur early. It does however correct itself for all subsequent cycles. 
Hi
It's not until when our first Sync1 pulse occurs in Green that we see this register updated. We're wondering if you might know where the Sync1 next time(0x998) register is updated from, and why it's not done until this point. I know the PRU EtherCAT firmware from Texas Instruments if provided a black box. Would it be possible to have access to the source code to understand why this register is not updated during startup?
It looks like a issue. We will look into this issue and provide more details.
2. SOF Jitter
We're measuring the SOF signal directly from the board on pin D7 vout1_d10. The SOF signal arrives at the time as expected from the master, 55us ahead of the next Sync0. However, we don't see a Hardware Interrupt for the PDI_ISR/SyncManager until 20us after the SOF signal is seen. So despite SOF arriving at the time expected, we don't receive the interrupt in software until 20us later.
According to us, we need to profile the Sync0/Sync1/PDI using HW pins, instead of profiling using GPIOs from ISR. We understand that there are challenges in performing profiling using sync and edio pins. We will try it on our side and provide more details.
Regards
Dhaval
Hi Dhaval,
Thank you this certainly helps clarify the SM timing we're seeing. I'm working on debugging PRU1 to get it working so I can measure via the provided pinmux options.
We were also curious if there was any update on the Sync1 Next Time 0x998 register at startup.
Hi Dhaval,
I was able to get PRU1 to work for my board. There was a PINMUX conflict in our use application that was causing the issue. Thanks for the patience on helping me figure out the root cause.
I used the pinmux setting provided for SOF/Sync0/EDIO OUT1. I've also changed PDI_ISR_EDIO_NUM to 1 in tiescbsp.h file.
SOF/Sync0 are working fine, however the measurement for EDIO OUT1 is reading constant High. I'm looking into the documentation, but maybe you might be able to help me understand a root cause for this?
Dhaval,
I checked the schematic and it looks like EDIO_DATA1 for pin G2 is actually on J4 Pin 4, not Pin 3. Assuming I'm now measuring the correct pin for the PDI my results can be found below.
For this test I was using an expected delay from SOF to Sync0 of 10us.
SOF Pin F4 to Sync0 Pin D2 is as expected around 10us.
SOF Pin F4 to EDIO Out Pin G2 is at about 15us. So this is the Jitter which we had previously been concerned about which still appears using the direct pin measurements. I understand as previously stated that process data buffer could impact this delay in our previous measurements using GPIO toggles in software. Is that statement still true for this measurement using the hardware signals?
Hi Dhaval,
Wanted to check if there was any update on the Sync1 Start Time Register issue at startup?
Hi Dhaval,
No worries on the time between responses I understand fixing these issues is not a simple task.
Yes 0x09A4 SYNC1 Cycle Time register is updated sometime before I'm reading the 0x0 in the 0x998 register. See attached image, 0x09A0 and 0x09A4 have been initialized with cycle times. 0x0910 System Time is being updated, and 0x0990 Sync0 Next Time is set to occur at a specified future time, however 0x0998 is still reading 0.
