Problem with Octet string in objdict.h

[Mathieu Goutel]

Hello everyone,

I am using the demo app on a Linux computer with some modifications on objdict.h
I want to exchange an Octet String between MN and CN.

I added these entries on objdict.h:

// Object 0x4000: TEST
OBD_BEGIN_INDEX_RAM(0x4000, 0x02, NULL)
OBD_SUBINDEX_RAM_VAR(0x4000, 0x00, kObdTypeUInt8, kObdAccConst, tObdUnsigned8, NumberOfEntries, 0x01)
OBD_SUBINDEX_RAM_OSTRING(0x4000, 0x01, kObdAccVPRW, DigitalOutput, 16)
OBD_END_INDEX(0x4000)

But with these lines, i have a segfault when the app try to start the stack. I have the following messages:

=> sudo ./demo_mn_console
/----------------------------------------------------
openPOWERLINK console MN DEMO application
using openPOWERLINK Stack: V2.0.2
/----------------------------------------------------
Initializing openPOWERLINK stack...
/--------------------------------------------------
List of Ethernet Cards Found in this System:
/--------------------------------------------------
1. enp3s10
2. enp3s11
3. Pseudo-device that captures on all interfaces
any
4. lo
/--------------------------------------------------
Select the interface to be used for POWERLINK (1-14):1
/--------------------------------------------------
Initialize ctrl module ...
Initialize OBD module...
Initializing kernel modules ...
Initialize kernel modules...
timerThread(): ThreadId:13200
workerThread(): ThreadId:13201
Get Mac addr 02:52:07:ffffff9b:ffffffbe:56
Initialize Eventu module...
Initialize Timeru module...
processThread() ThreadId:13205
initialize error handler user module...
Initialize DlluCal module...
Initialize Pdou module...
Initialize NMT_CN module...
Initialize NMTu module...
Initialize NMT_MN module...
Initialize Identu module...
Initialize Statusu module...
Initialize Syncu module...
Initialize SdoCom module...
Initialize Cfm module...
Initializing process image...
Size of input process image: 4
Size of output process image: 4
oplk_allocProcessImage(): Alloc(4, 4)
oplk_allocProcessImage: Alloc(0x90a47e0, 4, 0x90a47f0, 4)
nmtk_process(NMT-event = 0x0010): New NMT-State = 0x019
2014/10/09 16:53:17 - StateChangeEvent(0x19) originating event = 0x10 (NmtEventSwReset)
nmtk_process(NMT-event = 0x0020): New NMT-State = 0x029
nmtu_processEvent(): NMT state machine announce change of NMT State
.

Everithing seems to be good but the app return and i have a segfault on dmesg:
oplk-eventu[13204]: segfault at 812b000 ip b7547576 sp b4dfd988 error 6 in libc-2.20.so[b74cc000+1b1000]
.

The problem appears only when the OSTRING has the right to be mapped to a PDO (kObdAccVPRW here).

Has anyone an idea what the problem can be? An Octet String can't be mapped to a PDO ?

Thank in advance

[jbaumgar]

Hello Mathieu,

The problem appears only when the OSTRING has the right to be mapped to a PDO (kObdAccVPRW here).

Please change the access flag "kObdAccVPRW" to "(kObdAccRW | kObdAccPdo)". kObdAccVar must not be set for an octet string and is responsible for the crash.

An Octet String can't be mapped to a PDO ?

Theoretically, it can be mapped, but CANopen CiA302-4 and therefore openCONFIGURATOR provides no support. You can try to map it manually but it is not assured that it works.

Best regard,

Josef

[Powerlink-team Kalycito]

Hello Mathieu,

The modification made in the MN object dictionary seems to be correct.

Can you specify the modifications that were made in the MN and CN application to map and link the octet_string data in object dictionary?

Regards,
Powerlink team,
Kalycito

[Mathieu Goutel]

Hello !

Thank you for reply.

I tried only on MN. The crash occurs when i launch the MN, so i have not changed the CN yet.

On MN, i tried without modification on app (no link of the octet_string) and with this modification in initApp function (app.c):

static char test_string[16];

tOplkError initApp(void)
{
    tOplkError ret = kErrorOk;
    UINT varEntries = 1;
    UINT entrySize = 0;

    ret = oplk_linkObject(0x4000, test_string, &varEntries, &entrySize, 1);
    if(ret != kErrorOk)
    {
         printf("oplk_linkObject KO: 0x%x\n", ret);
    }
[...]
}

Same crash with these two tests.

Best regards,
Mathieu Goutel

[Powerlink-team Kalycito]

Hello Mathieu,

We are able to reproduce the issue on our side.Thanks for reporting.
About the issue:
The object initialization is failing when the object OSTRING is given the PDO access.
The cause of the issue looks like the null pointer error in obd macro of ostring variable.We are analysing the issue still further and will get back to you once we find a fix for it.

@Alexey:Strings and domains are always the part of PDO mapping.

Regards,
Powerlink team,
Kalycito

[Alexey]

Hello, Mathieu.
As i understand, domain and strings can't be mapped in PDO.
Best ragards, Alexey.

[Mathieu Goutel]

Thank you for the answer.
We will wait your fix for our next developement.

Best Regards,
Mathieu

[Powerlink-team Kalycito]

Hello Mathieu,

Please do the following workaround to fix the OString issue,

1)To fix the segmentation fault when OString object is given the kObdAccVPRW access,
- Change the (BYTE*)"" to NULL in the O-String macro (../stack/include/oplk/obdmacro.h)

2)To fix the object size mismatch failure (PDO data exchange failure),
- Initializing the size value of current instance pointer to the default size.
"static tObdOString MEM xCur##ind##_##sub##_g = {size, NULL}; "(../stack/include/oplk/obdmacro.h)

Please let us know if this workaround fix the issue in your side.

Regards,
Powerlink-team,
Kalycito

[Larry York]

Did this ever get resolved? I'm running into the size mismatch problem and I'm not clear what I'm supposed to change. Do I change
"static const tObdOStringDef xDef##ind##_##sub##_g = {size, ((BYTE)""), bCur##ind####sub##g};"
to look like
"static tObdOString MEM xCur##ind####sub##g = {size, NULL}; "?

[AEICOR IIoT Team]

Hi Larry,

The workaround given may allow you to map Octet string into PDO, but as @jbaumgar has pointed out before, though it is theoretically feasible to do this, it it not supported as per the CANOpen standar. If you need any help, please let me know. Thanks.

Best Regards,
aeicoriiotteam

[Mathieu Goutel]

Hello !

Thank your for the workaround, il will try it in a few days and will keep you informed.

Best Regards,
Mathieu