• State Resolved
  • Locked Locked
  • Replies 1 reply
  • Subscribers 31 subscribers
  • Views 468 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.

Original question:

AM2634: LWIP IGMP support

AM2634: AM2634 Enet CPSW EST Example :EST Schedule intervals timing issues

Jay Sun
Expert 1095 points
Part Number: AM2634


Hi TI

We follow Enet CPSW EST Example  with AM2634 EVM + SDK 08.02.01 as following 

AM263x MCU+ SDK: Enet CPSW EST Example (ti.com)

(1) We set CycleTime and gate control list and time interval as following

EST schedule parameters
Parameter Time Value
BaseTime Current time + ENET_APP_EST_ADMIN_LIST_DELAY
CycleTime 250 usecs
Gate control list
Gate Control Time Interval
ooCCCCCC 62.5 usecs
CCooCCCC 62.5 usecs
CCCCooCC 62.5 usecs
CCCCCCoo 62.5 usecs

we check test result as following, it show the frame time interval = (4us,63us,63us), not fit (62.5us,62.5us,62.5us) for EST Gate control list config

(1) We set CycleTime and gate control list and time interval as following

EST schedule parameters
Parameter Time Value
BaseTime Current time + ENET_APP_EST_ADMIN_LIST_DELAY
CycleTime 520 usecs
Gate control list
Gate Control Time Interval
ooCCCCCC 130 usecs
CCooCCCC 130 usecs
CCCCooCC 130 usecs
CCCCCCoo 130 usecs

we check test result as following, it show the frame time interval = (70us,131us,131us), not fit (131us,131us,131us) for EST Gate control list config

Please guide as how to fix the frame time interval to fit EST gate control list config .

BR

JAY

  • +1
    TI__Genius 9295 points

    Hi Jay,

    How are are calculating the first time interval being 70 usecs?

    Keep in mind that the first packet that you are sending might hit the wire in the middle of a time interval. Unless you are priming the TX queue for that priority (i.e. by sending packets in advance) before EST is enabled, you can't guarantee that packet will always hit the wire at the beginning of the time interval.

    In other words, when EST is already enabled and application sends a packet, the packet could either (a) be sent whenever the time interval for that priority opens next, or (b) right away if the time interval is already open. In case of (b), the time difference wrt first packet in next interval will be less that the time interval duration. Which I think is what you are observing.

    Regards,
    -Misa