i.MX RT Crossover MCUsのトピックRe: The issue with NXP's canopen protocol stack, regarding the length error when setting RPDO

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

suki — Fri, 18 Apr 2025 02:07:13 GMT

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

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

Sam_Gao — Mon, 21 Apr 2025 07:34:07 GMT

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

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

suki — Mon, 21 Apr 2025 10:00:30 GMT

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

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

Sam_Gao — Tue, 22 Apr 2025 04:40:54 GMT

Hi,

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

Especially for hardware and board setting.

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

suki — Tue, 22 Apr 2025 05:56:04 GMT

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.

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

suki — Tue, 22 Apr 2025 06:03:55 GMT

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

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

Sam_Gao — Wed, 23 Apr 2025 03:58:09 GMT

@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.

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

2419725132 — Wed, 23 Apr 2025 08:38:40 GMT

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.

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

Sam_Gao — Fri, 25 Apr 2025 08:21:06 GMT

@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

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

2419725132 — Mon, 28 Apr 2025 08:59:08 GMT

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.

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

Sam_Gao — Mon, 28 Apr 2025 10:01:25 GMT

@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.

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

2419725132 — Tue, 29 Apr 2025 07:56:33 GMT

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.

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

Sam_Gao — Wed, 30 Apr 2025 05:16:14 GMT

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