Invalid SM IN cfg

[phamnhatha090805]

Hello,
I'm trying to run a virtual version of my custom EtherCAT device on the Rasp Pi. What I have done is that I create my EtherCAT device using the LAN9253-ATSAMD51 Evaluation Board, this board is working fine, it can move through all the EtherCAT state machine and visible on the network. I exported the BIN file and the XML file from that board and added them to the KickCAT project and run the Rasp Pi. However, when I try scan the Rasp Pi again with the TwinCAT, it gave me Invalid SM IN cfg. Anyone know what is the root cause of this? I have attached the XML file and the BIN file of my custom EtherCAT so you can try to run it on your side.
sample_app_digitalio.zip
LAN9253_SAMD51.json

[leducp]

Well the only thing I see is that the FoE is enabled in the eeprom but not in the ESI. Maybe you can try to disable it in the eeprom first (especially because FoE is not yet support by KickCAT)
I didn't had the time to test it so far, and I'll try to give it a try this weekdn. In the meantime, do you have more logs to shares? For instance traces from the code running on the PI side?

[trns1997]

Thanks @phamnhatha090805 for sharing the files. Here is the breakdown.

Enable debug output

For starters i recommend activating debug modes its helps get more in depth insight on whats going on. EIther Add -DDEBUG_ESI_ERROR -DDEBUG_ESI_INFO -DDEBUG_ESI_WARNING to your CMake flags to see warnings on startup. Or you can use ccmake to toggle debug features.

What the warnings mean

Group 1 — Sync manager parameter objects (0x1c32 / 0x1c33)

[W] Cannot load default data for 0x1c32.2, expected size mismatch.
-> Got 16 bits, expected: 32 bit
[W] Cannot load default data for 0x1c32.4, expected size mismatch.
-> Got 32 bits, expected: 16 bit

The <Info> section is missing a default for Cycle Time (subindex 2), causing a positional shift in the EsiParser so subindices 4 and 5 land on the wrong slots. Harmless; no effect on the state machine. But there might be a problem in our EsiParser mechanism if it is the case. Need to cross check with the doc if this coupling is correct/legal.

Group 2 — PDO objects (0x6000 / 0x7010)

[W] Cannot load default data for 0x6000.1, expected size mismatch.
-> Got 8 bits, expected: 1 bit

BOOL / BitLen=1 entries produce bitlen/8 = 0 bytes in the parser, so default values are skipped. Symptom of the root cause below.

Root cause of Invalid SM IN cfg

KickCAT requires all PDO entries to be byte-aligned — sub-byte types (e.g. 1-bit BOOL) and gap/padding entries (index = 0x0000) are not supported. Hence the workaround below.

Workaround

Change your PDO entries from BOOL / 1-bit to USINT / 8-bit and remove the 4-bit padding entries. Update DefaultSize from 1 to 4 (4 × 1 byte):

<!-- Before (1-bit BOOL, does not work in KickCAT) -->
<Entry>
    <Index>#x6000</Index>
    <SubIndex>1</SubIndex>
    <BitLen>1</BitLen>
    <DataType>BOOL</DataType>
</Entry>
<!-- ... 3 more entries + 4-bit padding entry -->

<!-- After (8-bit USINT, works in KickCAT) -->
<Entry>
    <Index>#x6000</Index>
    <SubIndex>1</SubIndex>
    <BitLen>8</BitLen>
    <DataType>USINT</DataType>
</Entry>
<!-- ... 3 more entries, no padding needed -->

<!-- Before -->
<Sm DefaultSize="1" StartAddress="#x1400" ControlByte="#x20" Enable="1">Inputs</Sm>
<Sm DefaultSize="1" StartAddress="#x1100" ControlByte="#x64" Enable="1">Outputs</Sm>

<!-- After (4 channels × 1 byte each) -->
<Sm DefaultSize="4" StartAddress="#x1400" ControlByte="#x20" Enable="1">Inputs</Sm>
<Sm DefaultSize="4" StartAddress="#x1100" ControlByte="#x64" Enable="1">Outputs</Sm>

Each channel becomes a uint8_t on the application side (0 = off, non-zero = on). This is a simulation-only workaround — your real hardware continues to use 1-bit packed BOOLs over the wire.

Note: It would be great get some detail on your setup. Are you running on a real slave? Or you are working purely on an emulated setup? What are you using to generate your eeprom bins and the esi xml? Are you working with real hardware?

[phamnhatha090805]

One more thing, to test the Beckhoff official EtherCAT bus/devices, the EsiParser have been modified. If you look into this EL1xxx.xml, it's not contain only 1 device, so we implement the EsiParser that it can read the VendorId, ProductCode, RevisionNo inside the provided xml and compare these values with the values inside the provided eeprom. Overall, the eeprom only contain 1 device but the xml can contain several devices like this EL1xxx so our implemented EsiParser can search for the VendorId, ProductCode, and RevisionNo inside the provided xml that match with the provided eeprom. And if there's no matching VendorId, ProductCode, RevisionNo, it will complain.
Beckhoff EL1xxx.xml

[trns1997]

Did changing the entries from BOOL / 1-bit to USINT / 8-bit resolve your issue? If so i'll go ahead and maybe add a check in the EsiParser to throw and explain to the user why. What do you think?

[phamnhatha090805]

Yes, it fix the issue. Thank you so much!

[trns1997]

Yes, it fix the issue. Thank you so much!

Btw @leducp has a fix and has pinged you in the PR, it would be great if you could test it and give us some feedback :)

[phamnhatha090805]

sure