LP-AM243: Denial of service on sending more packets in LP-AM2434

Hi

Can you please elaborate on the following about the network when the issue happens:
1. Type of traffic
2. Traffic load 

Also, please share the Network Capture during the error scenario and with us.

In the meantime, you can check out Storm Prevention in ICSS EMAC, which may be relevant for your use-case.

Regards
Archit 

Hi

We used Nmap to connect to the port and then sent 1000 null bytes using a Python script. After that, the device stopped responding to ping requests. Is it possible that the device might automatically reset itself after some time if multiple packets are sent which device cannot handle? 

Hi Yashaswini,

Yashaswini S D said:

Is it possible that the device might automatically reset itself after some time if multiple packets are sent which device cannot handle?

I am confirming this with our EtherNet/IP Stack expert, I'll get back to you with an update soon.

Could you please provide the following so that we can analyze the behavior:

1. Network capture of the test which causes the app to go into abort
2. UART logs of the app from startup to abort

Regards
Archit

Hi Yashaswini,

Archit Dev said:

I am confirming this with our EtherNet/IP Stack expert, I'll get back to you with an update soon.

This is not expected from the EtherNet/IP Stack from TI.

Could you please provide the following so that we can analyze the behavior:

1. Network capture of the test which causes the app to go into abort
2. UART logs of the app from startup to abort

Regards
Archit 

Hi 

Below is the network capture of the issue

Hi Yashaswini,

Can you please share the full Wireshark log if possible? You can upload the PCAP file from the Insert menu in E2E.
Also, the UART logs would be much appreciated.

Regards
Archit

I am unable to upload the wireshark capture file ,as it is showing the above error . Can you please suggest alternatives to share/ upload the file 

I  don't have UART log file as this was tested in working environment by our cybersecurity team 

Hi Yashaswini,

There indeed seems to be a problem with uploading the PCAP file directly. However, if you enclose it within a zip file, you should be able to upload it here.

Yashaswini S D said:

I  don't have UART log file as this was tested in working environment by our cybersecurity team 

Understood.

Regards
Archit

Hi 

Thanks for responding, I have attached the zip file 

eip module 2.zip

Hi

Thanks for sharing the logs. We'll evaluate it and come back with an update regarding the findings soon.


Regards
Archit

Hi 

Thanks for the update. Could you please let us know by when we can expect the findings? It would be helpful if you could share them at the earliest possible, as we’re looking to proceed based on the outcome

Thanks 

Hi Yashaswini,

First things first, please try out the application from the latest Industrial Comms SDK for AM243x: INDUSTRIAL-COMMUNICATIONS-SDK-AM243X Software development kit (SDK) | TI.com

This is because the version that you're using does not include some critical bugfixes which have been made post the Industrial Comms SDK 09.02.00.15 (Sep 16, 2024).
Are there any specific design related reasons for sticking to the older version of the SDK?

If you're still running into the issue with the latest version of the SDK, I can try to reproduce the issue on my side with the AM243x-LP using the Network Capture that you shared. For this, I'd need the test topology that you're using for the test and answer some questions:

1. Was it a point-to-point connection between one port of the DUT to the PC? 
2. Were there any other nodes in the network during the test? 
3. Was the network topology a ring?

On a side-note, detailed analysis of the logs may take some time, since our Stack expert is out of office this week.

Regards
Archit

Hi Archit Dev,

We tried flashing our custom board with new SDK   "ind_comms_sdk_am243x_11_00_00_08 " we are using RGMII, ethernetip_apapter_demo  and we are getting following Uart  message, Is there any Hardware dependency or any configuration we have to change? 

Hi Yashaswini,

the example in SDK 11_00_00_08 uses newer SysConfig tool (version 1.22), when porting your example to the newer SDK, please make sure that your custom board sysconfig file is also compatible with newer one.
Another important consideration is the known limitation of the SBL OSPI bootloader in SDK 11. When flashing, please use an older version of the SBL OSPI bootloader instead (e.g. from SDK 9.2), as the SDK 11 version has size restrictions.

Best regards,
Pourya 

Hi Pourya 

we tried flashing using python script from older version of the SBL OSPI bootloader instead (e.g. from SDK ind_comms_sdk_am243x_09_02_00_08) we used same bootloader and the sysconfig file is also same except for the gpios which we have configured for custom board.  please let me know how to check the compatability to our custom board .

Thank you 

Hi Yashaswini,

When you flashed using the older OSPI SBL Bootloader, what messages appeared on the UART terminal? Could you please share the log?

I suspect you initially developed your Board's SysConfig file using an older version of SysConfig (version 1.20, perhaps). Is this correct?

1. Open SysConfig tool version 1.22
2. Load an existing syscfg file from SDK 11_00_00_08 examples that closely resembles your project (such as ethernetip_adapter_generic_device_rgmii_demo_am243x-lp)
3. Add your custom GPIOs to this configuration
4. Save it for your project
5. Test if this resolves your issue

Best regards,
Pourya

Hi Yashaswini,

There's also a known issue with the Secondary Bootloader in MCU+ SDK 11.00 - "MCUSDK-14566 :  OSPI failing with large sized application on AM243x-Launchpad".

I believe this is most likely the issue that you could be facing. There's a work-around that you can use in order to get the EthernetIP application to work with the bootloader, as follows.

Disable the bootloader scratch memory in the SBL OSPI example by adding the following code in main.c after the Bootloader_open API call:

/* After these existing lines:
* Bootloader_Config *cfg = (Bootloader_Config *)bootHandle;
* bootConfig = (Bootloader_Config *)bootHandle;
*/
bootConfig->scratchMemPtr = NULL;
bootConfig->enableScratchMem = 0;

Regards
Archit