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.

MCU-PLUS-SDK-AM243X: Problems on port 2 when receiving telegrams

Part Number: MCU-PLUS-SDK-AM243X
Other Parts Discussed in Thread: IND-COMMS-SDK

Tool/software:

We are also using IND-COMMS-SDK 9.2.0.24 and TMG PROFINET-Stack V6.0.0.0. Sending and receiving of telegrams works fine on port 1. Sending of telegrams seems also to work fine on port 2. But there is a problem with receiving of telegrams on port 2. When sending e.g. LLDP-telegrams from a device to DUT, ICSS_EMAC_rxInterruptHandler is called, but there is no frame in receive buffer of host port. By inspecting the L3 OCMC RAM I can see only fragments of the received frame at a wrong address in L3 OCMC RAM.

  • Hi,

    We are aware of few issues that existed on receive functionality on port 2 with IND-COMMS-SDK 09.02.00.24, which were fixed in the latest version of SDK 11.00.00.08. Could you kindly re-test this with the latest SDK and let us know whether the issues are still observed?

    www.ti.com/.../11.00.00.08

    Regards,

    Laxman

  • Hi Laxman,

    thank you for your quick response.

    Switching over to SDK 11.00.00.08 is quite an effort for me. Is it maybe possible to send me a patch with bugfixes so I could continue with SDK 09.02.00.24? I have took a look into release notes of SDK 11.00.00.08. In Fixed Issues I have found no entry describing the solved problem, why?

    Regards, Joachim

  • Hi Joachim,

    We have already shared the patch to TMG just after releasing the ICSDK 09.02.00.24 as they had reported this bug. You can use the same patch for resolving this issue.

    Regarding the release notes, since this patch was shared to TMG, we unfortunately did not update the fixed issues section to reflect this correction. I apologize for any confusion this may have caused.

    Drive Link: https://tidrive.ext.ti.com/u/6Mb1BVrG9UD6xvUc/6c689804-a94d-4a2f-a1e4-562bbced3710?l

    Access Code: KZk29ur.

    Regards,
    Laxman 

  • HI Laxman,

    icss_emac.c does not compile, it does not fit to icss_emac.h. I suppose there were made some patches before that patch. Can you send me these patches, too? As I mentioned, I have a problem when receiving LLDP-telegrams. You gave me a patch for DCP. Regards, Joachim

  • Hi Joachim,

    Could you share the error you are facing during the build? I have tried re-installing ICSDK 09.02.00.24 package for AM243x and apply the shared patch. With this I am able to build the application successfully, post rebuilding the icss-emac library for AM243x .

    Kindly note to copy the patch in this path(ICSDK source files) "{ind_comms_sdk_am243x_09_02_00_24}\source\networking\icss_emac\source" and not (MCU-SDK source files) "{ind_comms_sdk_am243x_09_02_00_24}\mcu_plus_sdk\source\networking\icss_emac\source".

    As I mentioned, I have a problem when receiving LLDP-telegrams. You gave me a patch for DCP. Regards, Joachim

    The fix is common for all NRT frames, hence this patch should work for both LLDP and DCP frames.

    Regards,

    Laxman

  • Hi Laxman,

    the patch compiles with ICSDK source files. Port 2 seems to work fine, when using these sources and flag enableHostQueueIsolation is set to 1. By default it is set to 0, even in the patch. Why are there two different versions of icss_emac sources? What is flag enableHostQueueIsolation for, as port 2 seems only to work fine when this flag is set to 1?

    Regards, Joachim

  • Hi Joachim,

    Thanks for confirming the status with the patch applied. 

    Why are there two different versions of icss_emac sources? What is flag enableHostQueueIsolation for, as port 2 seems only to work fine when this flag is set to 1?

    We implemented separate host queues(isolated host queues) for each port to address issues we observed during multiple iterations of Netload tests. Previously, we used common host queues for receiving frames from both ports, which occasionally resulted in dropped packets during 100% line rate traffic.

    With this latest fix, each port now has its own independent host queue and the failure was never observed during high Netload traffic tests.

    Regards,

    Laxman 

  • Hi Laxman,

    this answered my questions. Thank you for your help.

    Regards, Joachim