DSP: Integer16 is not read as expected

[KFatyga]

Hello,
I have an issue with the node not producing heartbeat, while using the example ClockApp. I'm running it on an embedded system, based on TI F28379d Delfino MCU. I've developed basic drivers which worked with previous version (4.1) about a year ago, and the HB was operating.
I upgraded to the current version, and lost the heartbeat entirely. There is only a singular HB frame with value zero transmitted once at the start of the program. Any changes in HB entry in OD did not help. The node is responding to Sync frame, transmits PDOs synchronously. The clock from the ClockApp also works fine. Only the HB is missing.
My testbench is the TI F28379D Delfino Launchpad and Peak Can sniffer.
Would You have any suggestions as to where to look for the solution?

[michael-hillmann]

Sorry for the late response. Have you solved this issue?

As a first idea, I guess the breaking change for version 4.4.0 may cause this issue. You can check the required migration steps, stated in the release notes.

[KFatyga]

Hello,
I've checked for the change you mentioned - everything seems fine - both the underscore and CO_T prefix are included in the changed version.
The OD entry for the heartbeat:
{CO_KEY(0x1017, 0, CO_OBJ_____RW), CO_THB_PROD, (CO_DATA)(&Obj1017_00_10)},
with the data object:
static uint16_t Obj1017_00_10 = 500;
The result:

The HB is transmitted once on startup with zero value - which, if I remember correctly is a desired behaviour - but it is not followed by the HB afterwards
Edit:
I've added additional info from the HB state during runtime

[michael-hillmann]

Hmm, hard to tell from distance. Here are some checks to get hints for your missing heartbeats:

Please have a look to yourNode->Error, this should be CO_ERR_NONE after your call to ´CONodeInit()`.

Please have a look to yourNode->Nmt.Tmr: this is the timer responsible for calling the heartbeat producer function. This should be a valid TMR id (value >= 0).

If this is -1 (no active timer), you can set a breakpoint in function COTNmtHbProdInit(), which is responsible for creating the corresponding timer. Maybe you get a hint, why no timer is created.

If timer is created, place a breakbpoint in function CONmtHbProdSend() and check, that the timer is fired and calls the correct heartbeat producer callback function.

[KFatyga]

Following Your instructions, I checked: indeed, the node->Nmt.Tmr was set to -1,
Breakpoint in COTNmtHbProdInit() shows that the value read in line 148: (void)uint16->Read(obj, node, &cycTime, sizeof(cycTime)); is read as zero. I forced the value to 500, works just fine - HB launches, with 500 ms, so I assume the issue is somewhere on read OD value level?
if (size == COT_ENTRY_SIZE) { *((uint16_t *)buffer) = value; } else { result = CO_ERR_BAD_ARG; }
Here is the culprit: the size shows to be 1, and the COT_ENTRY_SIZE is 2. (lines 82-86 in co_integer16.c)

[michael-hillmann]

Ok, this is an issue related to DSP datatypes. Unfortunately, I can't test it myself because I have no access to a DSP microcontroller board.

Can you try to replace the line #27 in co_integer_16.c:
#define COT_ENTRY_SIZE (uint32_t)2
with
#define COT_ENTRY_SIZE (uint32_t)sizeof(uint16_t)

[KFatyga]

OK - this managed to fix it, now the HB is working as expected. Thank You so much!

[KFatyga]

Fixing the HB issue by the replacement: #define COT_ENTRY_SIZE (uint32_t)sizeof(uint16_t) breaks the PDO: while trying to get the 16 bit value from OD and send it via PDO, the stack still attempts to use size 2 and the size mismatch causes the data to be left unread. The PDO is still sent, but with the wrong data.
Reverting back to the size 2 fixes the problem.
Stack works fine with hard coded size 1 for 8bit and size 4 for 32bit, despite using 16bit registers.
Right now only the 16bit is the problem, but i expect that all of the types should be (32bit has size of 2, 16 and 8 have size of 1).

Edit:
I followed the solution proposed in: https://github.com/embedded-office/canopen-stack/issues/125
And replaced all the sizeof()-s in the project with hardcoded 4,2,1 values. This fixed both the hb problem and the 16bit OD entry.