XMC4300 Relax EtherCat Kit-V1.1 State does not change from STATE_SAFEOP to STATE_OP

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
User16141
Level 1
Level 1
Hi,
I worked according the document "Getting Started - XMC4300_Relax_EtherCat_APP_Slave_SSC Example_V3.1.pdf".
XMC4300 Relax EtherCat Kit-V1.1 State does not change from STATE_SAFEOP to STATE_OP.
The error message is: ALSTATUSCODE_SMWATCHDOG or "Sync manager watchdog".
0 Likes
6 Replies
jferreira
Employee
Employee
10 sign-ins 5 sign-ins First like received
Hi,

Which software version of ECAT SSC and firmware are you using? Did you upgrade the APPs to the latest version?
BTW: There is a troubleshooting document from Beckhoff, https://www.ethercat.org/download/documents/EtherCAT_Diagnosis_For_Users.pdf

Regards,
Jesus
0 Likes
User16141
Level 1
Level 1
I am using:
DAVE 4.4.2
Slave Stack Code Tool 1.4.1.0
ETHCAT_SSC_XMC43.zip 3.1.0 2018-11-06
0 Likes
MichaelIFX
Employee
Employee
50 replies posted 25 replies posted 10 replies posted
Hi,
can you please check if you switched your slave into freerun-state?
For toggling freerun-state see slide 55 (TwinCAT3) and slide 46 (TwinCAT2) inside docu XMC43/3.1.

Only if you switched your device into freerun-state the slave can go into operational.

Kind Regards

Michael
0 Likes
User16141
Level 1
Level 1
Thanks,
I did it but:3341.attach
0 Likes
User15738
Level 1
Level 1
TwinCAT can't read the correct Identification values (Vendor ID, Product Code, Revision Number) from your slave. It seems to be that he eeprom handling in your source code is not working properly because the ID values are all 0.
Due to that TwinCAT is using the worng parameter to setup your slave and the stack response with an invlaid configuration (which is the correct behaviour).

In your case the eeprom is emulated, that means the eeprom access is handled by the slave application. Please check if the reference to the eeprom data is correct. If you con't know where it is assigned you could also debug your code and check the eeprom read commands.
To trigger an eeprom read command delete your slave (box 1 xxx) from the configuration and scan the network again. While scanning the function "EEPROM_CommandHandler" (file: ecatappl.c) is called.
If you need further support analysing your code you could also contact ethercatssc@beckhoff.com.
0 Likes
MichaelIFX
Employee
Employee
50 replies posted 25 replies posted 10 replies posted
Very good point from Rainer Hoffmann. Thank you!
However, I'm very confident there should be no issue with the example's sources version 3.1 you are using.

But the emulated EEPROM content might be corrupted. Let me explain:
The EEPROM content is generated by SSC in an array and thereby compiled into the SW.
During the very first startup it is checked if the emulated EEPROM (inside FLASH at the 2nd 64k sector) is empty. If it is empty the EEPROM content generated by SSC tool is copied from data section to the emulated EEPROM.
From that moment on EEPROM has a content and for the next startup the erase check fails. Only the content inside the EEPROM will be used. All further modifications will be stored inside the emulated EEPROM (Flash).
But the 2nd 64k sector inside Flash is not erased/cleaned when you download your SW. As a consequence, if you had any other content flashed to that section it will be identified as invalid content by the EEPROM emulation.

So, before you program your SW into the flash, make sure to erase the complete FLASH first (e.g. use JFLASH-Lite from SEGGER for this purpose) . Thereby also the EEPROM will be erased.
Same applies for any modifications you set inside SSC tool and which are resulting in a modification of the EEPROM content.
To activate them, you always first have to erase content inside the emulated EEPROM.
0 Likes