Issue with RxPDO Updates on EVB_LAN9252_SPI_ATSAM51J19A with Multiple 32-bit or 16-bit Variables

[DarioFantini]

Hi everyone,

I'm working with the SOES stack on the EVB_LAN9252_SPI_ATSAM51J19A board and using TwinCAT as the EtherCAT master.

I’ve successfully configured and tested RxPDOs with:

One uint32_t variable, or
Two uint16_t variables
In both cases, the slave enters OP state and the RxPDO values are updated correctly in TwinCAT.

However, when I try to:

Map two uint32_t variables, or
Map more than two uint16_t variables
…the slave still reaches OP state, but RxPDO values stop updating in TwinCAT. The only way to get them to update again is to reset the microcontroller.

The ESI XML and object dictionary are correctly aligned with the SOES configuration. I’ve verified the SyncManager sizes and the PDO mapping seems valid.

Has anyone experienced similar behavior? Could this be related to buffer alignment, SyncManager size, or something specific to the LAN9252 or ATSAM51 SPI implementation?

Any help or suggestions would be greatly appreciated!

Thanks in advance!

[nakarlsson]

Can you share more info, how you run SOES? Simple Loop polling PDI Isr?

I’m not sure on RxPDO VS TxPDO here, TxPDOs are sent to master from slaves, hence they can be updated as Inputs in TwinCAT? Is that what you mean?

Anyway, you can debug print data in SOES in RXPDO/TXPDO update, check when and what data is written to the SyncManagers. Along with a Wireshark you should get a clear picture where the data stop updating.

[DarioFantini]

Thanks for the reply. I'm currently using polling. The issue is with the TxPDO: 0x1A00, which links to object 0x6000. I'm sharing the XML and object list files where the mappings are defined.

As I mentioned before, when I use two 16-bit objects (ADCs.ADC0 and ADCs.ADC1), as shown in the attached files, everything works perfectly. However, when I try to add two more 16-bit objects (ADCs.ADC2 and ADCs.ADC3), these new ones appear in TwinCAT, but their values are never updated.

XML.txt

objectlist.txt

[nakarlsson]

Hi,

The ESI is not 100% correct, loading it in CTT say for example related to 1A00.

2025-06-16 16:51:03; Critical; SubDevice (evb9252_dig): Failed to initialize: Offline Dictionary (Index: 0x1A00, Name: ADCs, Type: DT1A00, BitSize: 128, Access: ro): Failed to convert '#x60000110' to UNSIGNED16: Value was either too large or too small for a UInt16.;

You can try using SOEM and slaveinfo and/or simple_test? They will rely on OD instead of ESI.

[DarioFantini]

Thanks for the reply. I used the Ethercat SDK supplied by RT-Labs to generate the xml (ESI), and the ecat_options.h, slave_objectlist.c and utypes.h files. I compiled the project in MPLAB, remembering that I use the evb_lan9252_spi board, and the xml was sent to Twincat. The board (the slave) connects without any error, but it still has the same problem: the variables (RxPDO) are not displayed with the real value nor do they update their value, only when the board's MCU is reset. Furthermore, if I write the 16-bit variable from Twincat, it is updated on the board. I'm really lost with this behavior. I did the test with SOEM to check the mapping between OD and ESI, and as expected, since I used the RT-Labs tool, it was correct. The problem is when the RxPDO exceeds 32 bits (sum of the 4 variables = 64). Would I have to use .application_hook = init_default, as explained by RT-Labs?

[nakarlsson]

Does the IO work as expected when using SOEM? You can check using test\simple test. Provide a Wireshark of the startup when slave is setup as 2x32bit.

only when the board's MCU is reset

I don't get that bit, what does that imply? Isn't the slave config static? Or do you have some dynamic PDO config schema?

You should be able to pinpoint what is going on by verifying the data in TXPDO_update.

SOES/soes/ecat_slv.c

Line 146 in 6ef7b94

void TXPDO_update (void)

Are the IO changing there?
Is that function called properly?
Is ESC_SM3_sml the correct length (for 2x32bit)?
If IO are update in TXPDO_update, do they reach TiwnCAT, check via Wireshark

Above would give you the answers or pinpoint where to dig deeper.