• State
  • Locked Locked
  • Replies 8 replies
  • Subscribers 101 subscribers
  • Views 230 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

AM6421: AM6421 Industrial Communication SDK 9.2

Narasimha Rao
Intellectual 595 points
Part Number: AM6421

Tool/software:

Hi,

   We are using Industrial communication SDK9.2 with Ethernet/IP Adapter Discrete IO profile.

  1) when continuously running the Ethernet/Ip adapter application we encountered the below exception, and the System got hung.There is no response from both R5F cores. with 

 [r5f0-0] 5682.008863s : tcp_write: pbufs on queue => at least one queue non-empty ASSERT: 5682.8917s: /nightlybuilds/ind
[r5f0-0] 5682.008956s : _comms_internal/jenkins/ind_comms_sdk_am64x_09_02_00_08/mcu_plus_sdk/source/networking/lwip/lwi
[r5f0-0] 5682.008998s : p-stack/src/core/tcp_out.c:tcp_write_checks:345: 0 failed !!!

2) On A53 Linux core is responding. but below message is printed on console.


root@am64xx-evm:~# {.bash_history,ARROW3-MBN-APP,DisplayErrMsg,Fault.csv,Warning.csv,am64-{am64-mcu-m4f0_0-fw,main-r5f{0_{0-fw,1-fw},1_1-fw}},myappstart.service,ti{boot3.bin,spl.bin},u-boot.img,ystemctl\ {--type=service\ --state=active,list-unit-files\ --type\ service\ -all}} {.bash_history,ARROW3-MBN-APP,DisplayErrMsg,Fault.csv,Warning.csv,am64-{am64-mcu-m4f0_0-fw,main-r5f{0_{0-fw,1-fw},1_1-fw}},myappstart.service,ti{boot3.bin,spl.bin},u-boot.img,ystemctl\ {--type=service\ --state=active,list-unit-files\ --type\ service\ -all}} {.bash_history,ARROW3-MBN-APP,DisplayErrMsg,Fault.csv,Warning.csv,am64-{am64-mcu-m4f0_0-fw,main-r5f{0_{0-fw,1-fw},1_1-fw}},myappstart.service,ti{boot3.bin,spl.bin},u-boot.img,ystemctl\ {--type=service\ --state=active,listroot@am64xx-evm:~# {.bash_history,ARROW3-MBN-APP,DisplayErrMsg,Fault.csv,Warning.csv,am64-{am64-mcu-m4f0_0-fw,main-r5f{0_{0-fw,1-fw},1_1-fw}},myappstart.service,ti{boot3.bin,spl.bin},u-boot.img,ystemctl\ {--type=service\ --state=active,list-unit-files\ --type\ service\ -all}} {.bash_history,ARROW3-MBN-APP,DisplayErrMsg,Fault.csv,Warning.csv,am64-{am64-mcu-m4f0_0-fw,main-r5f{0_{0-fw,1-fw},1_1-fw}},myappstart.service,ti{boot3.bin,spl.bin},u-boot.img,ystemctl\ {--type=service\ --state=active,list-unit-files\ --type\ service\ -all}} {.bash_history,ARROW3-MBN-APP,DisplayErrMsg,Fault.csv,Warning.csv,am64-{am64-mcu-m4f0_0-fw,main-r5f{0_{0-fw,1-fw},1_1-fw}},myappstart.service,ti{boot3.bin,spl.bin},u-boot.img,ystemctl\ {--type=service\ --state=active,list-unit-files\ --type\ service\ -all}} {.bash_history,ARROW3-MBN-APP,DisplayErrMsg,Fault.csv,Warning.csv,am64-{am64-mcu-m4f0_0-fw,main-r5f{0_{0-fw,1-fw},1_1-fw}},myappstart.service,ti{boot3.bin,spl.bin},u-boot.img,ystemctl\ {--type=service\ --state=active,list-unit-files\ --type\ service\ -all}} {.bash_history,ARROW3-MBN-APP,DisplayErrMsg,Fault.csv,Warning.csv,am64-{am64-mcu-m4f0_0-fw,main-r5f{0_{0-fw,1-fw},1_1-fw}},myappstart.service,ti{boot3.bin,spl.bin},u-boot.img,ystemctl\ {--type=service\ --state=active,list-unit-files\ --type\ service\ -all}}

Thank You. 

  • 0
    TI__Intellectual 790 points

    Hi Narasimha,

    in the next release, the LWIP will be using static memory pool instead of dynamic memory allocation. I expect that it will fix your issue.
    Other than that, can you please give us some context about your setup, what is the Cyclic I/O time? Does the problem occur soon after the board starts?

    Best regards
    Pourya

  • 0 in reply to Pourya Eskandari
    Intellectual 595 points

    Hi Pourya,

                     Thanks for the reply.

         We are using the Cyclic I/O of 20msec.

          The problem occurs in random time.

          We also have the other issue when using with Allen Bradley PLC When using class3 connection for explicit message request the Device connection  with  PLC goes to I/O Connection failure and disconnects for some time and reconnects after 3 secs.

         Please provide the steps to solve this issue.

        Thank You.

  • 0 in reply to Narasimha Rao
    TI__Intellectual 790 points

    Hi Narashimha,

    based on what you described, I see you are running multicore application. Are you trying to pass data related to Ethernet/IP between cores? if yes, is Cycle I/O data exchanged between cores?
    Can you please give us a general overview of your use case.

    Best regards
    Pourya

  • 0 in reply to Pourya Eskandari
    Intellectual 595 points

    Hi Pourya,

                     Thank you for the reply.

             Yes we are running multicore application.

             We are passing he Ethernet/IP related Cycle I/O data to other R5F1_0 core application. This is done using shared memory and IPC Notify.

    Thank You.

  • 0 in reply to Narasimha Rao
    Intellectual 595 points

    Hi Pourya,

              As replied by you in earlier reply, when is the tentative date for  next  release of Industrial Communication SDK.

             We have to make a release to our customer.

    Thank You.

  • 0 in reply to Narasimha Rao
    TI__Intellectual 790 points

    Hi Narasimha,

    I can't say for sure, but probably in early/mid September.
    Have you noticed in general a delay when asking other CPU for data, specially regarding 20ms Cyclic time exchange? My point is, are you blocking on any callback function which you have registered to Ethernet/IP stack?

    Best regards
    Pourya

  • 0 in reply to Pourya Eskandari
    Intellectual 595 points

    Hi Pourya,

              Thank you for the reply.

              Yes, we are blocking for 2~10msec in the callback function which is registered to Ethernet/IP stack, because we have to fetch data from                   back end in another core.

               Any other method available to avoid the delay in call back.

     Thank You.

               

  • 0 in reply to Narasimha Rao
    TI__Intellectual 790 points

    Hi Narasimha,

    I would generally discourage blocking on callbacks, because it will affect the run-time behavior of the stack.
    If possible in your design, you could dedicate some other task which is running on the same core as Ethernet/IP stack to fetch a copy of your required data from the other core and have them ready, and in your callbacks you use this copies without blocking.

    Best regards
    Pourya