devel@lists.zephyrproject.org | CANopen error message

Cristian Anceschi <cristian.anceschi@...>

#7548

Hi all

I'm developing a CANOPEN node based on an nRF52DK nRF52832 (PCA10040) board wired to a MCP2515 and a MCP2551 devices.
So far, through a CAN Interface for USB plugged to a PC, I can receive and transmit packets and command from and to the board

When I compile the project and launch the Zephyr debug, the first message received by the PC over the CAN bus is an error message (hex string). Received only once, at reset.

08A 00 61 01 2A 00 00 00 00 00

which means that the system it is unable to allocate memory for object (CO_EM_MEMORY_ALLOCATION_ERROR).
The log file at the boot is

*** Booting Zephyr OS build v2.4.0-ncs1 ***
[00:00:02.737,579] [0m<inf> fs_nvs: 6 Sectors of 4096 bytes [0m
[00:00:02.737,579] [0m<inf> fs_nvs: alloc wra: 1, e90 [0m
[00:00:02.737,579] [0m<inf> fs_nvs: data wra: 1, 210 [0m
[00:00:02.739,776] [0m<dbg> canopen_storage.canopen_settings_set: restored object dictionary EEPROM entries [0m
[00:00:02.739,807] [0m<dbg> canopen_driver.CO_CANmodule_init: rxSize = 13, txSize = 9 [0m
[00:00:02.740,814] [1;31m<err> canopen_driver: failed to attach CAN rx isr, no free filter [0m
[00:00:02.740,875] [1;31m<err> canopen_driver: failed to attach CAN rx isr, no free filter [0m
[00:00:02.740,905] [1;31m<err> canopen_driver: failed to attach CAN rx isr, no free filter [0m
[00:00:02.740,966] [0m<inf> app: CANopen stack initialized [0m

After this a guard message (hex string) , every 1 second, is received over the CAN bus

70A 7F

The node appears in pre-operational state.
No other error messages are shown by the PC via the Zephyr debug system.

In this condition, sending NMT commands, it is possible to force the node to:
Enter in STOP mode
Enter in Pre-operational mode (from STOP mode)
Reset node
Reset communication
The node however doesn't enter in operational mode.

Might the reason for this latest fact be, that there is an error at reset, so that the node won't enter in operational mode because of this?
What can be the cause of the error? Is there a THREAD STACK SIZE or some other parameter I have to change to solve the problem?

Or can I suppose that the error message can be overlooked because the node has to start and then everything works as expected? I mean, the node after all IS receiving commands like I said above.

In any case I believe that the node has to be moved away from the error condition in order to proceed. What should be the best way to do this? Thanks in advance for any hints and support Kind regards Cristian

"Karsten König <karsten.koenig.030@...>

#7549

Hi,

failing to register rx filters sounds like a mismatch between the number of filters that canopen expects and the ones configured for the MCP2515. Until recently these were independent KConfigs, but I removed that distinction here, especially due to the risk of running into this.
https://github.com/zephyrproject-rtos/zephyr/pull/31197

Can you check whether you have that change already in your local branch?
If yes I'd still check why it failed attaching more filters, that looks suspicious. CO_CANrxBufferInit() returns an error if there is not enough filters, yet CO_init() seems to return successfully, looks like there is also a missing check for return values, but I don't really know canopen :-(

Cheers,
Karsten

Show quoted text

On 1/21/21 5:37 PM, Cristian Anceschi wrote:
    Hi all
I'm developing a CANOPEN node based on an nRF52DK nRF52832
    (PCA10040) board  wired to a MCP2515 and a MCP2551 devices.
    So far, through a CAN Interface for USB plugged to a PC, I can
    receive and transmit packets and command from and to the board
When I compile the project and launch the Zephyr debug, the first
    message received by the PC over the CAN bus is an error message (hex
    string). Received only once, at reset.
08A 00 61 01 2A 00 00 00 00 00
which means that the system it is unable to allocate memory for
    object (CO_EM_MEMORY_ALLOCATION_ERROR).
    The log file at the boot is
  *** Booting Zephyr OS build v2.4.0-ncs1  ***
    [00:00:02.737,579] [0m<inf> fs_nvs: 6 Sectors of 4096 bytes [0m
    [00:00:02.737,579] [0m<inf> fs_nvs: alloc wra: 1, e90 [0m
    [00:00:02.737,579] [0m<inf> fs_nvs: data wra: 1, 210 [0m
    [00:00:02.739,776] [0m<dbg> canopen_storage.canopen_settings_set:
    restored object dictionary EEPROM entries [0m
    [00:00:02.739,807] [0m<dbg> canopen_driver.CO_CANmodule_init: rxSize
    = 13, txSize = 9 [0m
    *[00:00:02.740,814] [1;31m<err> canopen_driver: failed to attach CAN
    rx isr, no free filter [0m
    [00:00:02.740,875] [1;31m<err> canopen_driver: failed to attach CAN
    rx isr, no free filter [0m
    [00:00:02.740,905] [1;31m<err> canopen_driver: failed to attach CAN
    rx isr, no free filter [0m*
    [00:00:02.740,966] [0m<inf> app: CANopen stack initialized [0m
After this a guard message (hex string) , every 1 second,  is
    received over the CAN bus
70A 7F
The node appears in pre-operational state.
    No other error messages are shown by the PC via the Zephyr debug system.
In this condition, sending NMT commands, it is possible to force the
    node to:
* Enter in STOP mode
      * Enter in Pre-operational mode (from STOP mode)
      * Reset node
      * Reset communication
The node however doesn't enter in operational mode.
Might the reason for this latest fact be, that there is an error at
    reset, so that the node won't enter in operational mode because of this?
    What can be the cause of the error? Is there a THREAD STACK SIZE or
    some other parameter I have to change to solve the problem?
Or can I suppose that the error message can be overlooked because
    the node has to start and then everything works as expected? I mean,
    the node after all IS receiving commands like I said above.
In any case I believe that the node has to be moved away from the
    error condition in order to proceed. What should be the best way to
    do this?                                                                                         Thanks in advance for any hints and
    support                                                             Kind regards                                                                                                               Cristian