AM2434: Are there any restrictions on changing EtherCAT status?

Hi,

Can you share the wireshark logs for the failing scenario? When you pause the R5F core, is the application getting stuck at any particular place?

I’m trying to understand if the issue is at the EtherCAT firmware (packets are not processed correctly) or if the host (R5F) is not able to update the state transition.

Regards,
Aaron

Hi Aaron,

The application is not in the same location, but is looping in a specific section.

I will send you the wireshark logs via mail.

Best regard,

Oyama

Hello Oyama,

I have few more queries related to your test case.

Please let me know how you are making sure that the transition to a new state is complete? Are you reading the current ESM state back and then request a new state? or the task is requesting a new state every 1ms irrespective of the previous state transition request is complete or not?

Have you tested with the EtherCAT Simple Demo application from the ICSDK or with your customized application based on Simple Demo?

Did you observe these debug prints from your EtherCAT SubDevice?

State change: 0x2 -> 0x1
State change: 0x1 -> 0x2
State change: 0x2 -> 0x1
State change: 0x1 -> 0x2
State change: 0x2 -> 0x1
State change: 0x1 -> 0x2

Could you please also share more information on your test setup and CodeSys configurations so that I can try to reproduce the same issue at my end? 

Kind Regards,

Hi Oyama,

An additional query related to the test environment/SDK:

• Which version of Industrial Communications SDK are you using? If you're not using Industrial Communications SDK 11.00, then I would recommend you to use the latest firmware available in Industrial Communications SDK 11.00 in your project. Details on how to migrate to the latest EtherCAT firmware can be found here: EtherCAT Firmware Migration guide.

Prior to this migration, please do provide the wireshark logs.

Tomoya Oyama said:

I will send you the wireshark logs via mail.

We haven't received yet. Please let us know if you need any guidance here.

Regards,
Aaron

Hi,

Harsha Begihally Shanmukhaswamy said:

Please let me know how you are making sure that the transition to a new state is complete? Are you reading the current ESM state back and then request a new state? or the task is requesting a new state every 1ms irrespective of the previous state transition request is complete or not?

The state change request is made after the state transition is complete.

Harsha Begihally Shanmukhaswamy said:

Have you tested with the EtherCAT Simple Demo application from the ICSDK or with your customized application based on Simple Demo?

I tested it with the default EtherCAT simple demo application.

Harsha Begihally Shanmukhaswamy said:

Did you observe these debug prints from your EtherCAT SubDevice?

Yes. And after hung-up, this debug prints also stopped.   

Harsha Begihally Shanmukhaswamy said:

Could you please also share more information on your test setup and CodeSys configurations so that I can try to reproduce the same issue at my end? 

The state transition is performed by the EtherCAT task.
No other operations are performed.

Aaron Thomas said:

Which version of Industrial Communications SDK are you using?

I use Version: 11.00.00.08.

Aaron Thomas said:

We haven't received yet. Please let us know if you need any guidance here.

I just sent it. If you haven't received it yet, please let me know how to send it.

Best regard,

Oyama

Tomoya Oyama said:

I use Version: 11.00.00.08.

I also tried with SDK version 11.00.00.13, but the result is the same.

Hi,

What is the situation now?
Have you been able to reproduce it?

Best regard,

Oyama

Hi,

Can I have more details on the topology you are testing here? Are you trying this in a redundancy setup ? Or is the PLC connected to the EtherCAT OUT port?

Regards,
Aaron

Hi Aaron,

The Wireshark logs I sent were obtained using the following configuration.

It is not a redundant setup. Nothing is connected to the LP's Out port.

Best regard,

Oyama

Hi,

Thank you for the details. We will try to reproduce the issue from our side.

Regards,
Aaron

Hi Aaron,

Is there any progress?

It is possible that the cause is in the master, so I would like to know the situation.

Best regard,

Oyama

Hi,

One major observation from your logs is that most of the frames having INIT Write datagram to 0x120 Reg is not returned:

I'm not sure if this is pointing to lost frame. I don't see this behavior for frames having PREOP Write datagram to 0x120 Register.

To add on,

Just to be aligned, are you connecting EtherCAT IN to Port0 and EtherCAT OUT to Port1(left open in your case)?

Hi Aaron,

Yes, I've tried both ports and get the same results.

Best regard,

Oyama

Hi,

The reason we wanted to verify if the OUT and IN port are correctly assigned is due to the presence of "Circulating bit" set in the wireshark logs you shared:

We are trying to understand the consequences when "Circulating Bit" is set. I haven't observed this bit being set in normal daisy-chain setup in TwinCAT or SOEM environment.

I have installed CODESYS but haven't gotten the complete setup ready. I will try to reproduce the issue or check internally with folks who has tested with CODESYS if this behavior is observed. Please expect an update by Friday.

Regards,
Aaron 

Hi,Aaron,

I have sent the wireshark logs again, so please check it.

So it can't be reproduced with TwinCAT ?

Best regard,

Oyama

Thank you for the logs. We do see some frames not getting acknowledged by the EtherCAT SubDevice.

• For INIT to 0x120 using APWR, I only see 241 returning frames (filter: ecat.cnt == 1 && ecat.reg.alctrl == 0x0001) for a total of 16756 APWR packets (filter: ecat.cnt == 0 && ecat.reg.alctrl == 0x0001) sent from the MDevice.
  • Frame #461212 is the last frame where PREOP write to 0x120 of the AM243x (Physical address = 0x3ea) is acknowledged, that is, WKC is incremented.
  • 
    • Frame #461219 again writes PREOP to 0x120 of the DUT, but the returning frame (461220) doesn’t seem to acknowledge the FPWR frame. Looks like the application goes into bad state from here. FPWR failure may be due to incorrect value in Reg.0x10. I don’t see Reg.0x10 corruption from the MainDevice device.
    • Looking at Frame #461222, the DUT is in INIT state and never changing in the following frames. Going further below, I see MDevice setting DUT to PREOP but the corresponding WKC is 0 (write is not happening I believe).
• Couple of follow-ups:
  • Can you make sure that Reg.0x10 is not getting corrupted/over-written, so that FPWR datagram will successfully write to the ESC Register for state transition.
  • Can you provide the ICSS Memory dump. You can capture log the following Register spaces based on the ICSS instance you are using:
    1. 0x30000000 - 0x30040000 (for ICSSG0)
    2. 0x30080000 - 0x300C0000 (for ICSSG1)

Tomoya Oyama said:

So it can't be reproduced with TwinCAT ?

I've tried the following with TwinCAT and did not observe any issue:

Connect LP to the master (TwinCAT).
Once it becomes OP, return to INIT.

Once the transition to INIT is complete, change to preOP.
Once the transition to preOP is complete, return to INIT.
Repeat this state transition.

Regards,
Aaron

Hi Aaron,

Aaron Thomas said:

Can you provide the ICSS Memory dump. You can capture log the following Register spaces based on the ICSS instance you are using:

I am attaching two files.　Are there file format OK?

_working : Before hanging up

_stopped: After hanging up

Aaron Thomas said:

Can you make sure that Reg.0x10 is not getting corrupted/over-written, so that FPWR datagram will successfully write to the ESC Register for state transition.

Do you know an effective way to check this?

Best regard,

Oyama

ICSSG1_0x30080000_0x300C0000_working.datICSSG1_0x30080000_0x300C0000_stopped.dat

Tomoya Oyama said:

I am attaching two files.　Are there file format OK?

Yes, the format is fine. Thank you. I will review this.

Tomoya Oyama said:

Do you know an effective way to check this?

You can monitor (0x30090000 + 0x10) Register from the DUT. 0x30090000 is the base address for the ESC Memory space from the host (R5F) perspective. For now I am able to see the value correctly assigned (0x3EA) from the memory dump you shared:

Regards,
Aaron

Hi Aaron,

Aaron Thomas said:

Can you make sure that Reg.0x10 is not getting corrupted/over-written, so that FPWR datagram will successfully write to the ESC Register for state transition.

I checked the value of Reg.0x10 using the code below, and confirmed that it always shows the same value after the EtherCAT connection is established.

static void EC_SLV_APP_SS_applicationRun(void *pAppCtxt_p)
{
    uint32_t readdata=0;

    readdata=CSL_REG32_RD_RAW((uint32_t *)(0x30090000+0x10));

    if((readdata&0x3EA)==0x3EA){
        OSAL_printf("x");
    }
    else{
        OSAL_printf("o");
    }
}

Best regard,

Oyama

Hi Oyama,

Thank you for the confirmation.

Aaron Thomas said:

I have installed CODESYS but haven't gotten the complete setup ready. I will try to reproduce the issue or check internally with folks who has tested with CODESYS if this behavior is observed. Please expect an update by Friday.

I'm still trying to get CodeSys working on my system. Facing issue in the Gateway login.

Regards,
Aaron 

Hi Aaron,

Has there been any progress since then?
Without changing the test configuration, we continuously changed the state of the first slave (not AM243), and it worked for a long time without any problems.
However, when we changed only the master device, the problem occurred again within a few minutes.

Best regard,

Oyama

Hi Oyama,

We just got a setup ready with CODESYS internally. Now we need to test the state transition and understand the behavior. I should be able to provide more details by mid-next week.

Tomoya Oyama said:

However, when we changed only the master device, the problem occurred again within a few minutes.

Sorry I'm not clear. So with other EtherCAT MainDevices, the issue is not observed and only with CODESYS it is observed?

Regards,
Aaron

Hi Aaron,

Aaron Thomas said:

Tomoya Oyama said:

However, when we changed only the master device, the problem occurred again within a few minutes.

The master device here refers to another EtherCAT MainDevices using CODESYS .
In other words, the problem could also happen with other MainDevices using CODESYS .

Best regard,

Oyama

Hi Aaron,

How is the progress? Can you reproduce it with CODESYS?

Best regard,

Oyama

Hi Oyama,

Apologies for the delay in response. I'm trying to reproduce the issue from my side (got delayed due to couple of other high priority tasks). I'll provide an update soon.

Regards,
Aaron