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

DAVE™ Forum Discussions

User20030
Level 1
Level 1
I am using XMC4800 to develop an etherCat slave device with Dave 4 IDE. After I changed the HW connections, I re-generated code and built the project and loaded the code to XMC4800.
When I connect the slave device to TwinCat 3, I got the following error message:

‘INIT to PREOP’ failed!
Error: ‘Check Product code’. Comparison ‘0x00000b22’ == ‘0x50f10002’ failed.

The left side of comparison is the vendor ID of the device and the left side is product code of the device.
Did I forget to patch Dave 4 generated code?
I don’t understand why this could happen and don’t know how to fix it.

Your help is highly appreciated!
0 Likes
6 Replies
MichaelIFX
Employee
Employee
50 replies posted 25 replies posted 10 replies posted
Dear JimLu,
from what you explain, we give it a good chance, the problem is fixed, if you erase the complete flash before downloading the new software to your device.

Background:
When you generate the SSC-code, the EEPROM content is compiled into your binary (see eeprom.h).
The data of the EEPROM emulation is located in the 64k of physical sector PS4 (Sector S4-S7).

During every startup it is checked, if EEPROM emulation data is already available inside flash PS4.
1. If EEPROM data is available inside PS4,
the content is loaded from FLASH into RAM.
All EEPROM-read/writes during operation are then executed using the data located inside RAM.
EEPROM data inside flash is updated per need to implement persistence.
2. If EEPROM data is not available inside PS4,
the initial EEPROM content which was compiled into your binary is used for first time initialization of the EEPROM emulation inside PS4.

If you just flash a new binary into your device without first erasing the complete flash (including PS4), the EEPROM content compiled into your binary might never get copied to the PS4/emulation EEPROM which still holds old data.
e.g. the device description inside xml on EtherCAT-master and EEPROM content on your slave-device are out of sync.
This can lead to conflicts you are reporting.

Kind Regards

Michael
0 Likes
User20030
Level 1
Level 1
Michael,

Thanks for your quick reply.

I used SEGGER J-Flash Lite V6.80b erased the whole chip before I downloading the the software.
Please see attached image.

4715.attach
0 Likes
User20487
Level 1
Level 1
I am having the same issue as this one, if you erase the chip it flashes the EEPROM area correctly, and TwinCat brings up the device into OP mode.

However if you bring the device back into INIT (either straight away, or through SAFE OP, PREOP, INIT) it shuts down succesfully, but when trying to transition again from INIT back up to PREOP it definately does something funny with the EEPROM.

I sometimes get "check product code" or sometimes "check vendor id".

Just restarting the board fixes this error, so I'm thinking it has something to do with how the emulated EEPROM is connected to the SSC? Funny how on first run it is fine, but when trying to move through the states it fails.

I am using SSC Tool v 5.12, using the provided Infineon_XMC_ECAT_SSC_Config.xml on an XMC4300.
0 Likes
User20487
Level 1
Level 1
Okay, so I've got further with this through debugging the xmc_eschw.c and ecatappl.c files.

It looks like in the default configuration the EEPROM that Michael mentions above is never set up, and instead the SSC just reads the data directly from the EEPROM.h file generated by the SSC. I'm not sure why, but that wasnt the issue here. Perhaps Michael you can step and correct us on this, when the EEPROM_CommandHandler is called inside the SSC it looks to see if we have set up any specific handlers from the EEPROM, for reading this would be pAPPL_EEPROM_Read.

However in the Generated Dave Code this is never set up, so anyway it just responds pulling data out of memory.

Where I was going wrong, was that I had a UINT32 in my PDO, and when writing this data away, the SubIndex was aligned into a 32bit word, and so the example code which takes 2 bytes off for the SubIndex was not trimming enough bytes, and the memcpy was overflowing into other space.

This caused the pEEPROM variable to move, meaning when the Vendor or Product ID was requested, it was accessing the wrong part of the memory.

So, JimLu I would put a watch on the pEEPROM variable inside ecatappl.h and check when it changes, it should only change in xmc_eschw.c using "pEEPROM = &aEepromData[0U];" OR in ecatappl.c MainInit has a definition which does the same thing.

Make sure you are not walking off the buffer provided in APPL_InputMapping, this was my issue.

Perhaps we can now look into why the EEPROM is not being stored correctly? Ideally we need this working so that when Configuration parameters are sent to the drive over CoE to 0x8000 addresses, the SSC can update the EEPROM to store these values for next power up.
0 Likes
MichaelIFX
Employee
Employee
50 replies posted 25 replies posted 10 replies posted
Dear jcarter,
yes, the PDO data must always be aligned to 32bit boundaries, So you might need to fill it up with padding-bytes.
For details on this SSC internal handling and correct implementation/types of PDO, please clarify with the ETG who know the SSC-stack the best and are always supportive.

In regard to XMC specific EEPROM write triggers:
There are basically two triggers, which trigger an update persistent EEPROM content inside flash:

1. When the last DWORD inside configuration area of EEPROM is written (CRC)
2. When the last DWORD of the complete EEPROM is written.

The Implementation you find inside xmc_eschw.c/UINT16 HW_EepromWrite(UINT32 wordaddr):
...
if ( (wordaddr == (uint32_t)7U) || (wordaddr == (((uint32_t)ESC_EEPROM_SIZE >> (uint32_t)1U) - (uint32_t)1U)) )
...

Kind Regards

Michael
0 Likes
User20030
Level 1
Level 1
Thanks all for your reply.

I have found the root cause of the problem. I changed Thread Settings of CMSIS_ROTS_RTX5_0, the problem disappeared.
0 Likes