The issue with NXP's canopen protocol stack, regarding the length error when setting RPDO

[suki]

Background: I'm using an NXP MCU and the CANopen protocol stack provided in the SDK package (EmSA CANopen (FD) Libraries for NXP SDKs). Most of the code is enclosed in the .a library files, and the hardware CAN module part is also included in these .a library files. So, I can't see the code of the CAN module and am unable to troubleshoot the issues. According to the ChangeLogKSDK.txt document, the protocol stack version is 7.10_rev1.

Problem: When using a CAN analyzer's PC software as the host computer to send RPDO to the MCU, I've encountered a problem. For some reason, the host computer needs to send one more byte for the MCU to enter the MCOUSER_RPDOReceived callback function. For example, if the mapping object of the RPDO in the object dictionary is set to 4 bytes (e.g., 0x20120020, where the last 0x20 indicates 4 bytes), the DLC (Data Length Code) on the host computer needs to be set to 5 bytes (or more) for the MCU to successfully receive the data, execute the callback, and successfully set the content in the object dictionary. (The code for setting the values in the object dictionary is not in the callback; the callback is just for users to write additional application code.) Otherwise, not only will the callback not be executed, but the content in the object dictionary will not change either.

For instance, if 1 byte is set, the DLC needs to be set to 2 bytes for the MCOUSER_RPDOReceived callback function to execute and obtain the correct data. This pattern continues in a similar manner.
If 8 bytes are set, when the DLC is less than or equal to 8, the situation is the same as above, and the callback will not be executed. However, if the DLC is greater than 8, the data received in the MCOUSER_RPDOReceived callback function will be garbled, and the content in the object dictionary cannot be changed, meaning the setting fails.

What could be the reason for this? Is it a certain setting inherent in the CANopen protocol? Is there a macro that can turn on or off this setting?#RT1170-EVK

[Sam_Gao]

Please follow https://www.esacademy.com/en/client-work/nxp.html to find detials.

[Sam_Gao]

Hi,

'CANopen protocol stack provided in the SDK package (EmSA CANopen (FD) Libraries for NXP SDKs). Most of the code is enclosed in the .a library files....'

--> Please clarify both hardware EVK and SDKs in details, it seems be all source code to customers if you download from offical EVK bord (e.g, RT1170-EVKB: https://mcuxpresso.nxp.com/en/builder?hw=MIMXRT1170-EVKB )

i.mx RT list: https://nxp.com/imxrt

[suki]

Hello, the example code path I am using is ...\SDK_2_16_000_MIMXRT1170-EVK\boards\evkmimxrt1170\canopen_examples\mco_slave, and the development board is MIMXRT1170-EVK

Problem: When using a CAN analyzer's PC software as the host computer to send RPDO to the MCU, I've encountered a problem. For some reason, the host computer needs to send one more byte for the MCU to enter the MCOUSER_RPDOReceived callback function. For example, if the mapping object of the RPDO in the object dictionary is set to 4 bytes (e.g., 0x20120020, where the last 0x20 indicates 4 bytes), the DLC (Data Length Code) on the host computer needs to be set to 5 bytes (or more) for the MCU to successfully receive the data, execute the callback, and successfully set the content in the object dictionary. (The code for setting the values in the object dictionary is not in the callback; the callback is just for users to write additional application code.) Otherwise, not only will the callback not be executed, but the content in the object dictionary will not change either.


For instance, if 1 byte is set, the DLC needs to be set to 2 bytes for the MCOUSER_RPDOReceived callback function to execute and obtain the correct data. This pattern continues in a similar manner.
If 8 bytes are set, when the DLC is less than or equal to 8, the situation is the same as above, and the callback will not be executed. However, if the DLC is greater than 8, the data received in the MCOUSER_RPDOReceived callback function will be garbled, and the content in the object dictionary cannot be changed, meaning the setting fails.

Is this issue caused by my incorrect operation or a bug in the .a library file? If it’s due to improper operation, what steps should I take to correct it

[Sam_Gao]

Hi,

Did you follow user manual or steps from Readme.md before you ask this question?

Especially for hardware and board setting.

[suki]

I connected the CAN analyzer to the CANL and CANH lines on the development board. Using the CAN analyzer, I can monitor the heartbeat packets from the slave device and switch its state.

[suki]

Additional note: TPDO and SDO can read/write and modify object dictionary entries normally, but there is an issue with RPDO

[Sam_Gao]

@suki 

So even you follow up the steps as README shown, this demo/example(NO ANY Modification) is still not workable from your side? If yes, please clarify in details.

[2419725132]

His problem has been described very clearly. This is a very obvious error. When using the standard routine and development board for CANopen communication, the NMT state can be switched, the heartbeat packet can be received and the frequency of the heartbeat packet can be modified. Both the SDO and TPDO are operating normally and can read, write, and modify the content of the object dictionary. However, only the RPDO is not working properly. I used two CAN protocol analyzers from different brands to send data, and this situation occurred in both cases. I also consulted many CANopen experts and learned that this is an abnormal situation. Therefore, I think it is likely a bug in this CANopen protocol stack.

[Sam_Gao]

@2419725132 So, in your opinion, this is a bug from CANopen protocol stack even without the technical details/behaivor?

Did you submit to CANOpen about your opinion to github issue to help fix this 'bug'? https://github.com/CANopenNode/CANopenNode 

[2419725132]

I have already consulted the author of the (EmSA CANopen (FD) Libraries for NXP SDKs) protocol stack. They provided me with a new.a library file. After I replaced the original one with this new file, everything worked properly. This indicates that it was indeed a bug.

[Sam_Gao]

@2419725132 Would you please share it here? and please share how did you get it?

@suki please follow to check if the 'dedicated new lib' is open here.

[2419725132]

I found that although this library has fixed the RPDO, there are still other bugs. Therefore, I won't share it here to avoid causing any misguidance. I'm still pursuing the investigation of these new bugs. I directly contacted them on the official website (www.em-sa.com/nxp) of the (EmSA CANopen (FD) Libraries for NXP SDKs) protocol stack, and that's why they replied to me. I think that since they are responsible for adding the CANopen protocol stack to your NXP chip's SDK, once bugs occur, it should be you who asks them to fix these bugs and then update the SDK, instead of me having to do the asking.