This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Problems with EtherCAT and System Time PDI Controlled

Other Parts Discussed in Thread: SYSBIOS

For a new product, we need to synchronize the SYNC0  signal with an external 1KHz TTL signal. 

So the idea was to use an ICEv2 board and the  SYSTEM_TIME_PDI_CONTROLLED option to let  ECAT PRU adjust the System Time. 

I couldn't find specific TI documentation on how this SYSTEM_TIME_PDI_CONTROLLED option is supposed to be used so I rely on paragraph 9.3 of Beckhoff EtherCAT Slave Controller Hardware Data Sheet (Section 1), that at the end states that when the System Time register (0x0910:0x0917) is written from the PDI interface, the distributed clocks PLL is fed with the difference between the provided system time value and the content of the DC Latch0 Time Positive Edge register (0x09B0:0x09B3). 

And so we set up the application in this way:

  1. Routed the TTL signal to the Latch0 input (J3 host expansion connector, pin 3)
  2. Set the Latch0 positive edge in Single Event mode
  3. Set AL Event Mask register to receive latch notification through the PDI interrupt
  4. Execute the following pseudo-code upon latch events:

void latch_0_positive_edge_event_handler()

{

static bool is_first_event = true ;

static UInt64 reference_time = 0 ;

static UInt64 nominal_ttl_period = 1000000; // nanoseconds 

if( is_first_event )

{

reference_time = bsp_get_latch0_posedge_time() ;

is_first_event = false ;

}

else

{

reference_time += nominal_ttl_period ;

bsp_pdi_write_system_time( reference_time );

}

}

 So the first question is: does this make sense? Is this the right way to use the SYSTEM_TIME_PDI_CONTROLLED option?

Unfortunately it seems that the call to bsp_pdi_write_system_time has no effect.  Register 0x92C (System Time Difference) is always zero. We verified this even with a scope looking at the relative phase between the TTL signal and the SYCN0 output (J3 host expansion connector, pin 7); the two kept  drifting.

 Here it follows more details about the settings and some considerations about  the code:

  1. We are using  SYSBIOS Industrial SDK 2.1.1.2
  2. ti\sysbios_ind_sdk_2.1.1.2\sdk\starterware\board\am335x\am335x_icev2_pinmux_data.c has been modified to properly configure the latch inputs to PRU
  3. The ESC settings to get the Latch0 Positive Edge time stamp (bits in square brackets) are as follows:

    Register

    Value

    Description

    0x140[11]

    1

    Enable DC Latch unit

    0x980[4]

    1

    Latch 0 assigned to PDI (latch event routed to PDI interrupt)

    0x9A8[0]

    1

    Latch 0 positive edge in Single Event mode

    0x220[1]

    1

    PDI interrupt on Latch event

  4. Beckhoff slave stack has been modified to receive latch notification from the PDI_Isr() function
  5. To verify the functionality distributed clocks on the slave have been enabled, so as to have the SYNC0  output available to a scope
  6. It turned out that it is possible to program register 0x09A8 through PDI interface when 0x980[4] == 1 (the same holds for  0x09A9 when 0x980[5] == 1) but the application does not receive any latch event notification (through the PDI interrupt). To receive them,  it is necessary to program registers  0x09A8 and  0x09A9 through ECAT interface (that is from the network side). This behaviour seems not to be correct.
  7. Compiling the application with the SYSTEM_TIME_PDI_CONTROLLED, write access from ECAT interface to most of the registers in the 0x900 range (the ones involved in synchronization and latching functionalities) is disabled. To properly set up the application we had to include the  SYSTEM_TIME_PDI_CONTROLLED API but leaving the write access as in the standard case.

 Please find attached the full sample application (it includes the TwinCAT project we used to test it, too) and the modified pinmux settings.

Could anyone see what we are doing wrong? Which are the right settings?

Kind regards,

Paolo 

  • Hi,

    I will forward this to the Industrial team.
  • Hi Paolo,

    thank you for your offline email.
    Biser has forwarded your issue to the Industrial Team and will take care for an answer.

    Regards, Bernd
  • From an offline email I've been informed that there may be a bug in Industrial SDK 2.1.1.2 EtherCAT PRU firmware preventing the drift loop to be active if System Time Delay (0x0928) is zero. Setting it different from zero (i.e. to 1) from the PDI side (not from the network side) solves part of the problem.

    The issue at point 6 of the original post is anyway still pending, and it is quite annoying. The point is:

    1. I would like to receive latch notifications through the PDI interrupt and trigger the drift compensation loop inside the PDI isr (this makes more sense to me that polling the latch registers)
    2. to achieve this 
      1. latch units must be assigned to PDI (0x980[4]=1)
      2. latch units must be in Single Event mode (0x9A8[0]=1). if in Continuous mode, no interrupt is generated, as in EtherCAT specifications.
    3. Register 0x980 must be set from the network side since from the PDI side is not writable (see this paragraph 3.48.3, Cyclic Unit Control)
    4. Register 0x9A8[0] is writable from the PDI side only when latch unit is assigned to PDI (see this paragraph 3.48.5)
    5. When latch unit is assigned to PDI, it makes sense that the slave application itself decide whether using the latch uint in continuous or single event mode. But if I set the 0x9A8 register from the PDI side, the register is correctly written but I do not receive the latch notifications through the PDI interrupt.
    6. I'm using TwinCAT. and to assign latch units to PDI I have to check the corresponding boxes in (TIESC Device)->EtheCAT->AdvancedSettings->Distributed Clocks->(Assign to Local uC) tab.
    7. Once I do this, I can't select anymore the Continuous/SingleEvent mode in (TIESC Device)->EtheCAT->AdvancedSettings->Distributed Clocks->Latch tab, since the slave application itself is supposed to do it, and there is no way of modifying the Init Command list in  the (TIESC Device)->EtheCAT->AdvancedSettings->General->(Init Commands)  tab.

    Conclusion: I must set register  0x9A8 manually each time I run the TwinCAT project using (TIESC Device)->EtheCAT->AdvancedSettings->ESC Access->Memory tab.

    So now the questions are:

    1. Is there a workaround for this problem?
    2. Is this going to fixed in the future firmware releases?

    Thanks in advance for the support.

    Kind Regards,

    Paolo Mastrapasqua

  • Hi Paolo,

    are you sure this is a TI ESC firmware issue and not Beckhoff EtherCAT slave stack? Did you discuss with Beckhoff people already? There is a forum on ethercat.org.

    regards,
  • Hi Frank,

    I modified my post a little bit, since you probably read it.

    In my set up the sequence of events is this:

    1. The master assigns the latch units to PDI (0x980[4]=1) while the slave is in pre-operational
    2. The master requests a state transition to safe-operational 
    3. The slave set 0x9A8[0]=3 from the PDI side (rising and falling edge in single event mode) and perform the state transition to safe-operational

    After this, the slave does no receive any latch notification through the PDI interrupt.

    If now I write  0x9A8[0]=3 from the network side (using the (TIESC Device)->EtheCAT->AdvancedSettings->ESC Access->Memory tab), then the slave starts receiving the latch interrupts and the all application behaves correctly.

    This behavior seems not correct to me and it is not related to TwinCAT.

    I hope this clarify a little bit more the situation.

    Paolo

  • Hi Paolo,

    ok, I understand now. But the register you mention is listed as read-only from PDI side currently (see processors.wiki.ti.com/index.php/PRU_ICSS_EtherCAT_firmware_API_guide point 6). So that is a feature at the moment and not a bug.
    I assume that this read-protection can be changed. Need to wait for a comment from engineering.

    regards,
  • Paolo,

    of course we need to change write protection. I haven't touched the EtherCAT ESC driver for some time. But in tiescbsp.c I found a section on PDI reg permissions. main gate:

    #ifdef ENABLE_PDI_REG_PERMISSIONS

    and then:

    for(i = 0; i < 26; i++)
    {
    pdi_reg_perm_array[i + 0x990] = TIESC_PERM_READ_ONLY;
    }

    So if the flag is set PDI side can't write your register. You could change that yourself at least for testing. In the future we may enhance this with some dynamic write protection.

    regards,
  • Ok, I understand.

    Anyway, if I write register 0x9A8 from PDI side, I see the effect reading it from the network side... so it seems "PDI-writable". ..only the interrupt generation is missing.

    Paolo
  • yes, as a default the flag is not set...

    Will need to get back to engineering.
  • Hi,

    Can you try writing 0x1FCC0 to memory address 0x4a32_e010 and see interrupts are coming...This will enable Latch0 single shot mode in H/W...

  • Seems to work!

    Thank you very much,

    Paolo