Part Number: AM2434
Hi
we are doing a conformance test on our custom board with am2434 ind_comms_sdk_am243x_09_02_00_24 SDK and I have attached the error, as per the previous suggestions we had updated the code with product_code, Product name, Device revision, vendor ID)
Is there any other things we have to take care or change in the code.
Hi Yashaswini,
The error likely indicates that you haven't loaded your .SOC file. You'll need to adapt your .SOC file just as you did for the .EDS file. To do this, simply open your .SOC/.STC file via "STC Editor" panel -> Add -> (select your SOC file) -> OK (Add menu) -> OK ("STC Editor" menu)
If you don't have a .SOC file, you can start from an EIP example as a template. For instance, the SOC file for a Generic Device can be found at: "ind_comms_sdk_am243x_09_02_00_24\examples\industrial_comms\ethernetip_adapter_demo\device_profiles\generic_device\soc\am243x-lp_tiEtherNetIP_freeRTOS.soc"
Please ensure that your EDS file and SOC file are consistent with each other to avoid any mismatches.
Best regards,
Pourya
Hi Pourya
Thanks for your quick response
While running conformance test I got errors
On seeing the log I see device is unable to bind to the given address. Any idea why is this
Hi Pourya
Hi Yashaswini,
here are my observations:
1) In your STC (.SOC) file, the MAC address doesn't match the device being tested, which will cause errors in the LLDP and TCP/IP object tests.
2) Regarding my previous inquiry about reset requests, I notice that both Type2 and Type1 Reset requests are skipped. Could you please explain why this is happening and confirm whether the reset request is being handled correctly?
Could you also please confirm if the reset request is being handled correctly?
3) Your .SOC file appears to be incorrectly configured for IO connections, as any attempt to open an IO connection (ForwardOpen) is rejected by the device with an "invalid O->T size" error (extended status code 0x127). Please update your SOC file with the correct IO stream sizes for O->T and T->O to match the device.
The root cause of the remaining errors seems to be misconfiguration on the PC running the CT21 test. Please follow the instructions in the CT21 User Manual (accessible via Help > Reference > User Manual) for proper PC network configuration.
Best regards,
Pourya
Hi Yashaswini,
1) Reset Issue: do you observe that the device restarts? can you capture the UART log during the test?
If not, do you have any observable method (LED, etc.) to see that the device actually restarts?
If that also not feasible, you need to debug your application and put a breakpoint to see if CMN_OS_reset is called or not.
2) DUT Response time: Are you connecting your DUT directly to your Test-PC LAN port, or is there any USB-Ethernet adapter involved? If you are using any USB-Ethernet adapter that might cause unexpected delay.
Other than that, the other suspect is what you mentioned in another E2E ticket, namely the delay that you have added to main task.
3)TCP/IP Test Issue: yes, indeed when there is another part of your code which overwrites the IP address setting that can be the root cause.
4) Connection Manager Test: The O->T and T->O payload sizes must be known to you already, how else can PLC communicate with your device and establish IO connection? Just use exactly the same payload size that you are using in your EDS file. It is the size of Producing and Consuming assemblies.
Best regards,
Pourya
Hi Yashaswini,
have you checked the check-box during test-setup to run Reset Type1 and Type2?
Regards,
Pourya
Hi Yash,
Based on the logs analysis:
1) Incorrect Timing for List-Identity: This appears to be caused by delays in the Main task, as we previously discussed.
2)TCP/IP Object Failures: These occur because your application is overwriting IP configurations received from the network. For example, when the test tool attempts to change the IP address to 192.168.1.11, the setting fails to apply.
1) Task Independence: Ensure your DAC task operates independently from the Main task. If data exchange between these tasks is necessary, implement proper inter-task communication mechanisms such as signals or queues to manage safe data transfer. What is the task priority for DAC task?
Implement a proper state-machine, when and how the rotary switch setting should be applied and when the request from the network.
If you prefer that your device's TCP/IP attributes be exclusively controlled by the rotary switch and not be modifiable from the network, this is technically feasible. However, this functionality would require a customized patch for the EtherNet/IP stack, as it's not included in the standard EIP implementation delivered with the Standard SDK.
Best regards,
Pourya
