• State
  • Locked Locked
  • Replies 1 reply
  • Subscribers 99 subscribers
  • Views 77 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM62L: Ethernet rx interrupt delay

Tony Tang
Mastermind 30667 points

Part Number: AM62L

Customer test ECAT master found sometimes rx interrupt delayed very long.

Test mothod: 

As ECAT tx package will be sent back after reaching farest node. add time stamp in tx irq and rx irq, calcuate the delay between rx and tx, normally the delay is around 30us, but sometime it over 250us which is the cycle time

code modification based on am65-cpsw-nuss.c

global variant.jpg

 

rx-tx irp.jpg

Can refer below code to add to am65_cpsw_nuss_ndo_slave_smit() to print diff if test on your side.

print.jpg

  • 0
    TI__Mastermind 20250 points

    Hi Tony,

    Tony Tang said:
    As ECAT tx package will be sent back after reaching farest node. add time stamp in tx irq and rx irq, calcuate the delay between rx and tx, normally the delay is around 30us, but sometime it over 250us which is the cycle time

    Just to be clear is result of >250us corresponding with test with A. CODESYS EtherCAT Jitter or B. cyclictest + stress-ng simulated load done in https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1644810/am62l-am62l-real-time-performance-issue ?

    If it's B. cyclictest + stress-ng simulated load, then was there any Ethernet traffic activity involved? What was the cyclictest result from same run that >250us was discovered? If no Ethernet traffic activity involved (i.e. cat /proc/interrupt | grep ethernet show 0) then I would be curious to know if result from RX IRQ delay measurement test customer is doing is relevant.

    If it's A. CODESYS EtherCAT Jitter, what was the EtherCAT jitter observed?

    Also if it's A. CODESYS EtherCAT Jitter, couple of quick suggestions below: 

    1. Put Ethernet IRQs on same core as CODESYS core (ensuring no other interrupts are on that core)
    2. Put Ethernet IRQ threads on same priority as CODESYS EtherCAT_Task priority

    -Daolin