CANopen SYNC message is not received #54364
Assignees
Labels
Comments
|
Please provide the changes to the Python test code you used to reproduce this issue. Also, are you upgrading from a previous Zephyr revision where the same tests pass? If so, which revision? Are you able to bisect where the bug was introduced? |
|
I can reproduce the issue. Looking into providing a fix. |
|
Thank you! I was already in the process of bisecting the git history of zephyr and the respective canopennode module, but proved a bit tedious on my hardware. |
henrikbrixandersen
added a commit
to vestas-wind-systems/zephyr
that referenced
this issue
Feb 13, 2023
The CANopenNode stack expects registered RX buffers to be processed and matched in priority order. The priority corresponds to the index of each each registered RX buffer with lower indexes having higher priority. Depending on the CANopen COB-ID network configuration used, it may result in overlapping CAN RX filters. In the case of overlaps, the priorities of the registered RX buffers matter. When receiving a CAN frame, process the RX buffers in priority order and only dispatch the callback for the matching object with the highest priority. Fixes: zephyrproject-rtos#54364 Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
|
@jmbrederveld Please test the fix in #54771 and report back. |
|
I can confirm this works on my setup! |
nashif
pushed a commit
that referenced
this issue
Feb 23, 2023
The CANopenNode stack expects registered RX buffers to be processed and matched in priority order. The priority corresponds to the index of each each registered RX buffer with lower indexes having higher priority. Depending on the CANopen COB-ID network configuration used, it may result in overlapping CAN RX filters. In the case of overlaps, the priorities of the registered RX buffers matter. When receiving a CAN frame, process the RX buffers in priority order and only dispatch the callback for the matching object with the highest priority. Fixes: #54364 Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
zephyrbot
pushed a commit
that referenced
this issue
Feb 23, 2023
The CANopenNode stack expects registered RX buffers to be processed and matched in priority order. The priority corresponds to the index of each each registered RX buffer with lower indexes having higher priority. Depending on the CANopen COB-ID network configuration used, it may result in overlapping CAN RX filters. In the case of overlaps, the priorities of the registered RX buffers matter. When receiving a CAN frame, process the RX buffers in priority order and only dispatch the callback for the matching object with the highest priority. Fixes: #54364 Signed-off-by: Henrik Brix Andersen <hebad@vestas.com> (cherry picked from commit bc4b49c)
stephanosio
pushed a commit
that referenced
this issue
Mar 1, 2023
The CANopenNode stack expects registered RX buffers to be processed and matched in priority order. The priority corresponds to the index of each each registered RX buffer with lower indexes having higher priority. Depending on the CANopen COB-ID network configuration used, it may result in overlapping CAN RX filters. In the case of overlaps, the priorities of the registered RX buffers matter. When receiving a CAN frame, process the RX buffers in priority order and only dispatch the callback for the matching object with the highest priority. Fixes: #54364 Signed-off-by: Henrik Brix Andersen <hebad@vestas.com> (cherry picked from commit bc4b49c)
nordicjm
pushed a commit
to nordicjm/zephyr
that referenced
this issue
Mar 8, 2023
The CANopenNode stack expects registered RX buffers to be processed and matched in priority order. The priority corresponds to the index of each each registered RX buffer with lower indexes having higher priority. Depending on the CANopen COB-ID network configuration used, it may result in overlapping CAN RX filters. In the case of overlaps, the priorities of the registered RX buffers matter. When receiving a CAN frame, process the RX buffers in priority order and only dispatch the callback for the matching object with the highest priority. Fixes: zephyrproject-rtos#54364 Signed-off-by: Henrik Brix Andersen <hebad@vestas.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I am currently facing an issue using CANopen on the STM32F205RB:
I am in the process of upgrading my (working) code base to support zephyr-3.3-RC1.
All CANopen related functionality seems to be present and working (NMT, SDO, ..), however I am facing issues regarding a configured TPDO.
Since the configured transmission type is set to
1, it should send the TPDO on every SYNC message (COB-ID 0x80) sent by the NMT master.In testing, it was observed that the SYNC message is not received by the stack, as it does not enter the
ifstatement located here:modules/lib/canopennode/stack/CO_SYNC.c:312I am able to reproduce this issue while running the
samples/modules/canopennodesample by adjusting the python canopen script as written in the README file, by setting the transmission type to 1.My setup currently is:
I hope you can aid me in resolving this issue.
Kind regards,
Justin
The text was updated successfully, but these errors were encountered: