TMS320F28P650DK: EtherCAT: Failed to upload SDO when final address is odd

Hi,

We have also tested to write (u16EscAddrSendMbx + u16SendMbxSize - 4), (u16EscAddrSendMbx + u16SendMbxSize - 2) and (u16EscAddrSendMbx + u16SendMbxSize) in sequence. Still no success.

Checking with hardware experts please expect a delay.

Hi , I am still yet to receive  response from hardware team , will ping as soon as I get response from them. Please expect delay of few days,

Hi , is it possible to share the .xml file ? or the mail box configurations done ?

Hi , I have configured some settings in ssc tool similar to yours, 

and with length 253 i am able to go into operation mode. Just to be sure did you update the eeprom with latest esi file in twincat also right?

Also can you change the 

There were issues with earlier specified delay of #69.

Regards

Kunal.

Kunal Wasnik said:

Hi , is it possible to share the .xml file ? or the mail box configurations done ?

Servotronix_CDHD_PC0_Rv0_029001_1_45_31_Simple.xml

Kunal Wasnik said:

Also can you change the 

SYSCTL_REGWRITE_DELAY in syctl.h file in sdk. and try again.

No difference

You might have generated this xml via SSc Tool right , Can you please share complete screenshot of SSc tool with the changes you had made for the Process Data  , Mailbox settings . (If you directly used this xml for f29 code it wont work , you would have to make the changes via ssc tool then use that generated xml , because internal some code changes also takes place  in generated code according to the change in ssc tool. )

The xml file is not generated via SSC. It is an very old product using other EtherCAT slave stack.

Kunal Wasnik said:

Can you please share complete screenshot of SSc tool with the changes you had made for the Process Data  , Mailbox settings .

we only manually changed the EEPROM value. We'll try regenerate the code via SSC.

Kunal Wasnik said:

and with length 253 i am able to go into operation mode. Just to be sure did you update the eeprom with latest esi file in twincat also right?

Hi Kunal,

I have run the CPU1_ECHOBACK_SOLUTION on P65 controlboard. The issue is reproduced like follows,

This means Twincat is unable to read the SDO response.

If I change the SM length to 252, the fault message is changed like follows.

This is because the following objects are not implemented for writing.

Hi , can you try making changes in ssc tool matching your xml settings and try . Since I said earlier manually changing esi file wont work , since the values gets changed in generated code also . If you use the esi file directly the code will contain the default values which will cause error. Or hard way is to go through all the generated code and make the changes manually.

Mean while I will also try to replicate the settings for the xml , but please expect some delay .

Hi Kunal,

I think I have noticed the difference. You need to use the XML file I attached, instead of the generated ones. In the example, there is no required SDO download operation for objects like 1C12 and so on.

You can use any odd length.

But you can also go to the COE page, all SDO cannot be read. 

But when length is even, then SDO is ok

Hi if you use the xml file directly the code changes will not take place. The ssc tool apart from generating the esi file also generate stack files which have code changes according the configuration done. Can you please tell how did you run the program for the earlier device in detail. 

Jianyu Wang said:

We are using beckhoff SSC stack. In function MBX_CopyToSendMailbox() in file mailbox.c, there is HW_EscWriteWord(u16dummy,(u16EscAddrSendMbx + u16SendMbxSize - 2)); 

Please pay attention to our observation. The key isue is that writing SDO response is unable to trigger sync manager 1, so that SDO communication is OFF between Twincat and the slave.

The generated xml does not include PDO Mapping download, like object 1C12h for instance.

Jianyu Wang said:

I have run the CPU1_ECHOBACK_SOLUTION on P65 controlboard. The issue is reproduced like follows,

This means Twincat is unable to read the SDO response.

So you may go OP with the generated xml. However, our product is useless without PDO, the issue is still here.

Another way to reproduce the issue with the generated xml, like I mentioned,

Jianyu Wang said:

But you can also go to the COE page, all SDO cannot be read. 

But when length is even, then SDO is ok

I see you guys still don't understand the issue.

The difference between 28388 and p65 is that for 28388 we implemented the ESC stack in the arm core. The minimum size is 1 byte.

In file ethercat_slave_hal.c of 28388 project:

//*****************************************************************************
//
// ESC_writeWordISR
//
//*****************************************************************************
void
ESC_writeWordISR(uint16_t wordValue, uint16_t address)
{
    //
    // Write 16-bit word into ESC memory
    //
    HWREGH(ESC_BASE + address) = wordValue;
}

But in P65, the minimum size is 2 byte. I think this caused ESC responds incorrectly for sync manager when length is odd.

In file ethercat_subdevice_cpu2_hal.c

//*****************************************************************************
//
// ESC_writeWordISR
//
//*****************************************************************************
void ESC_writeWordISR(uint16_t wordValue, uint16_t address)
{
    //
    // Write 16-bit word into ESC memory
    //
    HWREGH(ESC_BASE + (address / 2U)) = wordValue;
}

Hi, any updates? The question is already two and half weeks.

Hi, 

I tested with patch file with git and GNUWIN32, all returns failure.

The workspace folder is "D:\git\lvd2", I tested both in and outside the project folder.

Let me check mean while I will share the files .

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/171/ethercat_5F00_odd.patch
Can you please check and let me know if this is working . Run "git apply ethercat_odd.patch"

If you have a different version of ssc tool , you will need to do the changes manually then . There are not a lot of changes can you please refer the patch for the changes to make.

I made the change on V5.12, the result is same. Pleas share a project which solved the odd address and can run on p65 controlcard. Thanks.

Hi , Unfortunately we cannot share the project because of beckhoff restrictions.Also we dont have access to 5.12 please try to switch to 5.13. I am attaching video showing the working and non working case. If after switching to 5.13 you are still having issue we would be happy to assist over call.

I am sharing video to show the working scenario.

Regards

Kunal.

Hi Jianyu , 

Glad to hear it got fixed. So you had to make some more changes in addition to the shared patch (apart from

Can you please let us know what were the other changes so we could fix in the next version. Also were you able to fix in 5.12 version or you switched to latest version.

I changed the code in SSC V5.12. C2000 SDK 5.05

My fix is less general that only dummy byte is considered, as COE messages are way less than 253 bytes. The key is both MBX_CheckAndCopyMailbox and MBX_CopyToSendMailbox would both suffer from odd address.

In mailbox.c, consider odd address for both dummy read and dummy write.

In ethercat_subdevice_cpu1_hal.c, add new function readoddword, writeoddword is same as shared.

Ok Thanks. ( In my patch I handled it actually , The reason I didnt create a different readodd function is because we just want to read the last byte to trigger. So even if we end up reading more than what is required it should be fine. Will again check with more  experts on this.)

Regards

Kunal.