Because of the Thanksgiving holiday in the U.S., TI E2E™ design support forum responses may be delayed from November 25 through December 2. Thank you for your patience.

AM6421: Industrial Communication SDK

Part Number: AM6421

Tool/software:

Hi Pourya,

           As replied by you earlier for our issue reported, when will be Industrial Communication SDK released with LWIP using static memory pool instead of dynamic memory allocation.

     Please update the details.

Thanks.

T Narasimha rao

Previous reply 2 months ago...

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

  • Hi Narasimha,

    Multiple stability issues related to dynamic memory allocation have been fixed in the Industrial Comms SDK v 9.2.0.15. I'd suggest you to check it out.

    Download Link: https://www.ti.com/tool/download/INDUSTRIAL-COMMUNICATIONS-SDK-AM64X/09.02.00.15 
    Release Notes: https://software-dl.ti.com/processor-industrial-sw/esd/ind_comms_sdk/am64x/09_02_00_15/docs/am64x/ethernetip_adapter/eip_releasenotes.html 

    Please be aware that there can be some deadlock conditions when accessing I2C0 from the example due to I2C driver not being thread-safe. As a workaround, GPIO based LEDs can be used depending on the hardware.

    Regards
    Archit Dev

  • Hi Archit Dev,

                 We are testing the Ethernet-IP Adapter Discrete IO example from new INDUSTRIAL COMMUNICATION SDK 9.02.00.15.

               The Ethernet/I Adaptor Discrete IO Application crashes randomly when we run continuously (randomly more than 2 Hours).

      We have observed the below log when crash has happened.

    [r5f0-0] 11594.314224s : ENIP_IPSTK_allocFrameBuf returned NULL, out of memory?
    [r5f0-0] 11603.314015s : ENIP_IPSTK_allocFrameBuf returned NULL, out of memory?
    [r5f0-0] 11612.313768s : ENIP_IPSTK_allocFrameBuf returned NULL, out of memory?
    [r5f0-0] 11612.319392s : pbuf_free: p->ref > 0ASSERT: 11612.319429s: /nightlybuilds/ind_comms_internal/jenkins/ind_comms
    [r5f0-0] 11612.319474s : _sdk_am64x_09_02_00_15/mcu_plus_sdk/source/networking/lwip/lwip-stack/src/core/pbuf.c:pbuf_free
    [r5f0-0] 11612.319515s : :755: 0 failed !!!

    Can please tell us how this can be stopped.

      Thank you.

  • Hi Narasimha,

    Can you please answer the following questions:

    1. What is the test that you're running?
    2. What is the test topology?
    3. Do you have run-time dynamic memory allocation calls in your application code?

    Regards
    Archit Dev

  • Hi Archit Dev,

       Thank You for the response.

       Below are the details requested:

    1. What is the test that you're running?

         We are running Ethernet/IP Adaptor Discrete IO Application. Communicating data to/from PLC


    2. What is the test topology?

         The data is collected from Application running on R5F1_0 core through IPC Notify and Shared Memory.

         The data Collected from R5F1_0 are sent to PLC as Cyclic Data (Implicit Message).

        I f there is any request from PLC for data it is fetched from R5F1_0 and sent back to PLC as Acyclic data (Explicit Message).


    3. Do you have run-time dynamic memory allocation calls in your application code?

           We do not have any run-time dynamic memory allocations calls in our Application.

    Thank You.

  • Hi Narasimha,

    Thanks for the details.

    Just to confirm, you are connecting 1 AM64x Device with the PLC and establishing the IO Connection. There are no other nodes in your topology/network - is my understanding correct here?

    Also, what is the Cycle Time configured in your case?

    Regards
    Archit Dev

  • Hi Archit Dev,

        Yes, we are connecting only 1 AM64x Device with the PLC and establishing the IO Connection.

         The cycle time is within 20msec.

    Thanks

  • Hi Archit Dev,

                    Any Update on the above issue.

    Thank You

  • Hi Narasimha,

    I have notified our EthernetIP Stack Expert regarding this query. He will get back to you shortly.

    Thank you for your patience.

    Regards
    Archit Dev

  • Hi Narasimha,

    Based on your description, it means you have the stack running on one core ( R5F0_0 ? ) and you are trying to collect the data from another core.
    The common pitfall I see in this configuration is that you probably block on your callbacks to fetch data from the other core, which in turn deprive the stack run time, which eventually will cause buffer overflow or crash.
    Solution would be to not use blocking calls directly on stack callbacks. You could have a cached copy of your values ready to be used by the stack callbacks without blocking. ( Another task running on the same core as the stack is responsible to fetch data from the other core and have a local copy available, so that your callbacks use those copies).

    Best regards
    Pourya