AM335x EtherCAT data not valid

Hi Patrick,

This has been forwarded to the Industrial Protocol experts. Feedback will be posted here.

Hello Patrick,

Could you share the details of your process data configuration? If you are using the same process data as the default application, which data object are you toggling in the PLC program? How did you modify the application to present this output to the oscilloscope channel?

Thanks,
Srikant

Hi Srikant,

I use "LED 1" of "DO Outputs". I linked this to the PLC output variable. In the "APPL_OutputMapping()" procedure the process data ic copied mapped to "sDOOutputs.LEDs" variable (original code).

In the procedure "APPL_Application()" I do the following (temporary test code):

    //###
    bEtherCATOutput=(sDOOutputs.LEDs & 0x01);
    //###

In the same procedure I directly set or reset GPIO3_21 depending on "bEtherCATOutput" (channel 2 on the scope picture).

Unfortunately I'm short on free GPIO's. This makes debugging a bit difficult. I also do not know where to start. There might be a problem reading the process data from ESC (HW_EscReadIsr()).

With the EL2008 I wanted to check is the variable from the PLC is ok. So that seems to be ok.

Thanks for the support,
Patrick

Hi,

What I have done so far:

1. Check whether access to process data is blocked in some way in the procedure "bsp_get_process_data_address()" (by the way what does this procedure exactly?)
--> Access to process data is always possible (no timeout, no other problems)

2. Added additional delay in the procedure "HW_EscReadIsr()" just before reading the process data from ESC
--> With a long delay time (~3ms) it was possible to get valid output data (toggle of output in every cycle)

3. Patched Beckhoff Slave Sample Code V5.10 with newest patch file from SYS/BIOS Ind. SDK V1.1.0.5 and checked against used code
--> I found out that I did not have the newest code (e.g. file "ecatappl.c" had minor changes)
--> Incorporated newest patch change into code and total rebuild
--> No change in the behaviour

4. Changed procedure "PDI_Isr()" in such a way that "PDO_OutputMapping()" is not called. Changed "Sync0_Isr()" in such a way that "PDO_OutputMapping()" gets called, when slave works in DC-Synchron mode. Deleted the additional delay from point 2.
--> In DC-Synchron mode I get an absolut stable toggle of the output (like it should be)

5. Changed procedure "PDI_Isr()" as follows:

 

        /*###
        if ( bEcatOutputUpdateRunning )
        {
            // slave is in OP, update the outputs
            PDO_OutputMapping();
        }
        */
        if (!bDcSyncActive && bEcatOutputUpdateRunning)
        {
            // slave is in OP, update the outputs
            PDO_OutputMapping();
        }
        else

   Changed procedure "Sync0_Isr()" as follows:

#if MAX_PD_OUTPUT_SIZE > 0
        /*
        if(!bEscIntEnabled && bEcatOutputUpdateRunning)
        {
            // Output mapping was not done by the PDI ISR
            PDO_OutputMapping();
        }
        */
        if(bEcatOutputUpdateRunning)
        {
            // Output mapping was not done by the PDI ISR
            PDO_OutputMapping();
        }
#endif

--> SM-Synchron mode I get a nice toggle signal on the scope
--> In DC-Synchron mode I get a nice toggle signal most of the time. But there are still rare cases with one toggle miss.
--> There was also a problem when switching from DC-Synchron mode to SM-Synchron mode in TwinCAT. Then lots of toggle missed. Only a reset and restart of the AM3357 helped to get a stable toggle again.

==> Now I need a TI EtherCAT expert with knowledge of PRU-ICSS firmware to figure out what might be the problem (maybe code change in PDI_Isr() and Sync0_Isr() is needed?) and what I can try to debug.

Thanks.

Patrick

Hi,

Just some news:

After spending hours reactivating my old ICE V1 board, building the original code from SYS/BIOS Ind. SDK V1.1.0.5 and modifying the procedure "APPL_Application()" as follows (and deactivating LEDDriveError() statement in HW_SetLed()):

void APPL_Application(void)
{
    Uint8 LED; // initial test data
    static Uint8 prevState = 55;
    
    //### Test
    if (sDOOutputs.LEDs & 0x01)
    {
    	LEDDriveError(1);
    }
    else
    {
    	LEDDriveError(0);
    }
    //### Test Ende


    LED = sDOOutputs.LEDs;

I can see the same behaviour on the Error LED Output in DC-Synchron mode. Sometimes the toggle is missing. I have not seen missed toggle yet on SM-Synchron mode so far.

Thanks.
Patrick