XMC4800 EtherCAT frame processing

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
User11870
Level 1
Level 1
First like given 5 replies posted Welcome!
Hello,
I am trying to figure out the frame processing principle of ESC in XMC4800 MCU. However, the 'Reference Manual' does not explain about it instead it point to datasheet of ET1100. So I guess they have same ESC core. In the datasheet of ET1100, Fig. 5, page I-14 I it is explained that
- Processing direction: frame will get in port#0, passes the EtherCAT processing uint (EPU) and gets out at port#1
- Forwarding direction: when the frame get back port#1 (after passing all slaves), it will directly forwarded to port#0 to return master
As my understanding, all ouput/input data processing for one slave will done once by EPU in the processing direction frame.
2406.attach

I have done a simple test with 2 XMC4800 Relax kits. I put a pin toggle at each APPL_OutputMapping() and APPL_InputMapping() event. And this is my result (two upper signals come from Slave#1 and two lower ones from Slave#2)
2407.attach

As you can see, for each slave there is a delay between output and input events, it can be understood. But why APPL_InputMapping() event of slave#1 happens later than APPL_OutputMapping() event of slave#2. It seems that the APPL_InputMapping() event is processed on the returned frame, not in processing direction frame, can you explain this?
Thank you!
0 Likes
4 Replies
MichaelIFX
Employee
Employee
50 replies posted 25 replies posted 10 replies posted
Hi mophong,
the delay from APPL_OutputMapping to APPL_InputMapping origins from the SW-processing inside Slave#1.
While the EPU is triggering this SW-processing, in parallel it forwards the frame to slave#2 on port#1/out.
While slave is still busy on processing APPL_OutputMapping/APPL_InputMapping the frame arrives on Slave#2. The EPU of slave#2 is than triggering the SW-input/output-processing in parallel.

So the delay of slave#1/OutputMapping to slave#2/OutputMapping is more or less the delay you are looking for and which is introduced by the EPU(s) to forward the packet from slave#1 to slave#2.
There is no need to wait for APPL_InputMapping on slave#1 being finished before the frame is forwarded to slave#2.

Kind Regards

Michael
0 Likes
User11870
Level 1
Level 1
First like given 5 replies posted Welcome!
Thanks MichaelIFX,
So the data updated in APPL_InputMapping (data from Slave to Master) will be sent in next cycle frame, not current frame, am I correct?
0 Likes
User13030
Level 1
Level 1
mophong wrote:

So the data updated in APPL_InputMapping (data from Slave to Master) will be sent in next cycle frame, not current frame, am I correct?


did you find out how this works?
thanks.
0 Likes
MichaelIFX
Employee
Employee
50 replies posted 25 replies posted 10 replies posted
Hi mophong,
I just got aware of your comment by yoyixms (btw: thank you!) re-triggering this thread.

Yes, you are right!

Kind Regards

Michael
0 Likes