CCS/AMIC110: PRU ICSS EtherCAT PDI Watchdog not triggered

Falk

One thing to take care is that PDI WD can occur while halting the core in CCS for debug.

I need more details regarding the issue.

1. What changes have been made from the TI's example?
2. Can you share the steps to reproduce this issue on our setup?

Regards
Dhaval Khandla

Hello Dhaval,
thanks for your quick response.
We have used the ethernet_slave_full_AMIC11x_arm example as the base for our application. We started by adapting the example to our hardware requirements. This adapted example project is running OK. The PDI watchdog (actually SyncManager watchdog) seems to be triggered, even with the default adjustment of PDI_WD_TRIGGER_LATCH_IN. We can go from SAFE_OP to OP.

Our own project uses these adaptations, but is more complex and has its own SII configuration but it is not a DC application. The SyncManager watchdog is not triggered by the PRU/Hardware with any (PDI_WD_TRIGGER_RX_SOF/PDI_WD_TRIGGER_LATCH_IN etc.) configuration. As a workaround we are now doing the following:

    while(1)
    {
        PRUICSS_pruWaitEvent((PRUICSS_Handle)pArgs, evtOutNum);
        /* ISR processing */
        PDI_Isr();
        HW_EscWriteByte(0, ESC_PD_WD_TIME);
    }

This resets the watchdog and we can go from SAFE_OP to OP.

Unfortunately we can not provide you the project for reproducing the problem (not a CCS project and different hardware).

But, can you please consider the following questions:

1. Is there a way to find out why the PRU/Hardware is not triggering the watchdog? There must be some registers that can tell us why PDI_WD_TRIGGER_RX_SOF has no effect. If you could tell us where to look we can possibly find the reason.
2. Is this workaround acceptable?

Best Regards
Falk Bastille

Falk

Falk Bastille said:

1. Is there a way to find out why the PRU/Hardware is not triggering the watchdog? There must be some registers that can tell us why PDI_WD_TRIGGER_RX_SOF has no effect. If you could tell us where to look we can possibly find the reason.

1. Is there any way in your system to see if master data is reaching the slave? Like the LED in TI's example.
2. Can you look into physical memory of the ICSS to see if all the three buffers are getting updated?
3. What is the size of Rx and Tx PDOs?
   
   

Falk Bastille said:

Is this workaround acceptable?

Regards
Dhaval Khandla

Hello Dhaval,
here are the answers to your questions:

1. Yes we do receive process data and we can send process. This works fine.

2. I don't know which physical memory you mean. We can look into the buffers that the application is using to send and receive data. I assume the 3 buffers you mean are somewhere in the PRU? If you can tell us where to look we would check them out.

3. At the moment we are running with 2 Bytes Inputs and 2 Bytes Outputs.

Maybe I should point out that the phy addressing is different from the the one in your ethernet_slave_full_AMIC11x_arm example:

Port1 = 1

Port2 = 9 (was 3 in example)

But, this I believe is covered by Board_getPhyAddress() and the respective definitions.

I should also point out that we have the Dp83822i Phy on our board as opposed to the Tlk105 in the example.

Best Regards

Falk Bastille

Falk

Falk Bastille said:

I don't know which physical memory you mean. We can look into the buffers that the application is using to send and receive data. I assume the 3 buffers you mean are somewhere in the PRU? If you can tell us where to look we would check them out.

Hello Dhaval,

we have checked the data at the physical address and it's OK. As I said before in/out process data is working fine. 

We have done some more testing and found out the the problem seems to be in our ESI-File.

We have removed the ESI file from TwinCAT so that TwinCAT is forced to use the online description (SII). Then we configured the FMMU and SyncManager settings manually like shown in the screenshot.

With this settings, we are able to go OP without getting a SyncManager watchdog ( we disabled the workaround).

Adding the ESI-File to TwinCAT again and creating an new configuration based on the ESI, the watchdog occurs again.

I compared the content of the ESI and of the SII settings, but didn’t find any differences (see attached files).

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/791/SyncManagerWatchdog.7z

Can you please have a look at the ESI-File?

Thanks alot &

Best Regards

Falk Bastille

Hello,

unfortunately we are not able to use our ESI file with the TI Ecat implementation. It must be possible to see what is preventing the watchdog from being triggered. This ESI file worked with our previous implementation (not TI). We would change the ESI file to fix the problem, but all our attempts did not succeed.

We would therefore appreciate if you could let us know what adjustments inside the PRU that are caused by the ESI file are not OK.

Thank you &

best regards

Falk Bastille

Hi Falk
I am sorry for the delayed response.

We found one notable difference in the TI_ESC.xml and your XML. Your XML is not setting default size for following, whereas TI's does.

Snippet from your file:

<Sm ControlByte="#x64" Enable="1" StartAddress="#x1100">Outputs</Sm>

<Sm ControlByte="#x20" Enable="1" StartAddress="#x2000">Inputs</Sm>

Snippet from TI's file:

<Sm DefaultSize="5" StartAddress="#x1800" ControlByte="#x64" Enable="1">Outputs</Sm>
<Sm DefaultSize="7" StartAddress="#x1c00" ControlByte="#x20" Enable="1">Inputs</Sm>

We have seen issues sometimes when this is missing. Can you check if adding "DefaultSize" helps in your case?

Regards
Dhaval Khandla