Buffer overflow for certain SDO writes

[408b7f8b]

I am currently trying to get EtherCAT.NET to configure EtherCAT slaves via their SDO. Right now I am confronted with an error for which I cannot find a reason when trying to send SDO to a EL7031 stepper interface.

I use the Master example. I iterate through the slaves and when I hit the correct ProductCode, I add SdoWriteRequests like this:

if (slave.ProductCode == 0x1b773052) {
    var requests = new List<SdoWriteRequest>();

    foreach (var sdoParameter__ in sdoParameter)
    {
        var dataset = new List<object>();

        foreach (var entry in sdoParameter__.Dataset)
        {
            if (entry.Type == "UINT16")
            {
                var conv = Convert.ToUInt16(entry.Value);
                dataset.Add(conv);
            }
        }

        requests.Add(new SdoWriteRequest(sdoParameter__.Index, sdoParameter__.SubIndex, dataset));
    }
    
    slave.Extensions.Add(new EtherCAT.NET.Extension.InitialSettingsExtension(requests));
}

I use a JSON file for the instructions:

{
  "sdoParameter": [
    {
      "Slave": 2,
      "Index": 32784,
      "SubIndex": 3,
      "Dataset": [
        {
          "Type": "UINT16",
          "Value": 3500
        }
      ]
    },
    {
      "Slave": 2,
      "Index": 32784,
      "SubIndex": 4,
      "Dataset": [
        {
          "Type": "UINT16",
          "Value": 300
        }
      ]
    },
    {
      "Slave": 2,
      "Index": 32784,
      "SubIndex": 6,
      "Dataset": [
        {
          "Type": "UINT16",
          "Value": 200
        }
      ]
    },
    {
      "Slave": 2,
      "Index": 32784,
      "SubIndex": 2,
      "Dataset": [
        {
          "Type": "UINT16",
          "Value": 500
        }
      ]
    },
    {
      "Slave": 2,
      "Index": 32784,
      "SubIndex": 1,
      "Dataset": [
        {
          "Type": "UINT16",
          "Value": 600
        }
      ]
    }
  ]
}

The Master does execute the SdoWriteRequests when connecting. All SdoWriteRequests are executed correctly, besides this one:

{
  "Slave": 2,
  "Index": 32784,
  "SubIndex": 1,
  "Dataset": [
    {
      "Type": "UINT16",
      "Value": 600
    }
  ]
}

Whenever this instruction is part of my overall instruction set, the Master.Configure(rootSlave) fails with

*** buffer overflow detected ***: terminated

So far I was unable to get more output and to figure out any reason. When I exclude this certain instruction while keeping the others, the Configure step is executed flawlessly. According to the Beckhoff manual for the slave, the SDO entry is defined exactly like all others (RW, UINT16).

If anybody could give me a hint about my probable misuse or misconfiguration of the library, I would be very thankful.

[Apollo3zehn]

I do not see any error on your side but at the same time I also do not see how such an error could be caused. From the error message it looks like it comes from the underlying C-library. Either the small wrapper that EtherCAT.NET/SOEM.PInvoke adds or the much larger SOEM library.

You could do the following:

• Check the actual value of conv, maybe the conversion is messed up and you get a negative number
• Make a Wireshark dump to see if the offending SDO command is being sent to the slave or if it fails before that
• Try to debug into the underlying C-library (this works best when compiling the dependency SOEM.PInvoke yourself without optimizations enabled and with debugging symbols created) and see where it fails

Since a few years now I was dreaming of a pure C# EtherCAT master so that we get rid of these kind of errors but other duties come into my way all the time :-(

[408b7f8b]

I had the time to dig a little bit further.

The callback line for the sdoWriteRequests
EcUtilities.CheckErrorCode(this.Context, EcUtilities.SdoWrite(this.Context, slaveIndex, sdoWriteRequest.Index, sdoWriteRequest.SubIndex, sdoWriteRequest.Dataset), nameof(EcHL.SdoWrite));

in EcMaster.cs fails with the buffer overflow once it tries to do that one WriteRequest. The values of the parameters are fine, no difference to the other WriteRequests.
It's the callbacks executed after

_actualIoMapSize = EcHL.ConfigureIoMap(this.Context, _ioMapPtr, slaveRxPdoOffsets, slaveTxPdoOffsets, out _expectedWorkingCounter);

when configuring the slaves. I went and changed the code to get a little bit more information.

sdoWriteRequests.ToList().ForEach(sdoWriteRequest =>
{
  var code_ = EcUtilities.SdoWrite(this.Context, slaveIndex, sdoWriteRequest.Index, sdoWriteRequest.SubIndex, sdoWriteRequest.Dataset);

  EcUtilities.CheckErrorCode(this.Context, code_, nameof(EcHL.SdoWrite));
});

with the working sdoWriteRequests, the return is 1. With the one non-working, it is 0, which the CheckErrorCode evaluates to the "Buffer Overflow detected". Then I went into Wireshark and had a look into the packets send and it seems like the "Initiate Download" request made to the slave is not correctly defined. I attached a screenshot. The left one is the failing one, the one in the middle and the one on the right are working. While Index and SubIndex are correctly defined, the Data property isn't evaluated as HEX and there is an additional Length property. Why, I have no idea. The reason is probably somewhere in SOEM..? Guess EtherCAT.NET does not generate stuff here. Or could it perhaps come from some misconfiguration when getting trying to link the slave with its ESI?

[408b7f8b]

The SdoWrite-Method in EcUtilities.cs also works fine, values aren't mangled up there either, so I guess its happening somewhere in the SOEM lib.

[408b7f8b]

I think I found the error, though I am not sure if it actually is an error, because I do not know the code's logic well enough.

SOEM_wrapper in SOEM_wrapper.c, line 1006:
if (sdoSubIndex <= 1 && context->slavelist[slaveIndex].CoEdetails & ECT_COEDET_SDOCA)

So if sdoSubIndex == 1 is TRUE like in my case, it is treated differently. I do not know if the "<=1" is deliberate or a mistake. I changed it to
if (sdoSubIndex < 1 && context->slavelist[slaveIndex].CoEdetails & ECT_COEDET_SDOCA)
and now the sdoWriteRequest to the slave is built correctly and gets accepted by the slave without error and now "buffer overflow" error is showing. Could be considered a fix if the sdoSubIndex <= 1 does not introduce some wrong behaviour.

[Apollo3zehn]

I think you are right and it should be < 1 or (== 0) because ECT_COEDET_SDOCA means complete access and complete access makes only sense when the whole object is being accessed, i.e. the index is zero. But I am not sure right now if the SDO sub index is zero-based or one-based or - in the worst case - slaves differ in their behavior. I will have a look into the specs.

[Apollo3zehn]

I had a look into the spec and it says the following about the sub index:

Subindex of the Object, shall be zero or one if
Complete Access = 0x01

and the following about complete access:

0x00: entry addressed with index and subindex
will be downloaded

0x01: complete object will be uploaded, subindex
shall be zero (subindex 0 included) or one
(subindex 0 excluded)

So the condition in soem_wrapper.cs is correct but I don't know what else could have gone wrong. In your case the sub index is 1, so only the following line will be executed:

returnValue += ecx_SDOwrite(context, slaveIndex, sdoIndex, sdoSubIndex, TRUE, totalByteCount, dataset, timeout);

Maybe totalByteCount has the wrong value. Apart from SOEM itself or incorrect slave configuration (maybe the slave does not support complete access), this is the only possible source of the error I can think off.

[408b7f8b]

I can have a further look into the issue tomorrow and try to understand the logics. Is line 1030 in SOEM_wrapper.c the right approach with running ecx_SDOwrite with Complete Access = TRUE?
Unfortunately I also cannot get the PDOs to get written to the slave. With a regular Beckhoff PLC it works fine right out of the box. Some additional thing I have to find some fix. Thanks so far.

[408b7f8b]

The totalByteCount is calculated as 2, which should be correct?

I don't have any idea how to setup a real tooling/debug chain for this, so I can only abuse the return value of the C function to get other values right now.

[408b7f8b]

Since a few years now I was dreaming of a pure C# EtherCAT master so that we get rid of these kind of errors but other duties come into my way all the time :-(

Some other question not directly related. I plan on using Ethercat in future projects productively. So far I probably have to stick to a commercial C library. I'd obviously prefer some native C# solution and I could imagine supporting the implementation of one. As you're more into the topic, maybe we could have a short chat about the probable extent and approach somewhere.