Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

rcar_h3ulcb: failed to run test case tests/drivers/can/api #45169

Closed
aaillet opened this issue Apr 27, 2022 · 4 comments · Fixed by #46566
Closed

rcar_h3ulcb: failed to run test case tests/drivers/can/api #45169

aaillet opened this issue Apr 27, 2022 · 4 comments · Fixed by #46566
Assignees
Labels
area: CAN bug The issue is a bug, or the PR is fixing a bug platform: Renesas R-Car Renesas R-Car priority: low Low impact/importance bug

Comments

@aaillet
Copy link
Member

aaillet commented Apr 27, 2022

Describe the bug
The test case tests/drivers/can/api is timing out on main branch (1e02dd0) when testing on Renesas R-Car H3ULCB platform (probably on H3 Salvator-X too)

To Reproduce

  1. west build -b rcar_h3ulcb_cr7 tests/drivers/can/api/
  2. (terminal n°2) picocom -b 115200 /dev/ttyUSB0
  3. west flash
  4. (terminal n°2) See timeout

or

  1. ./scripts/twister -p rcar_h3ulcb_cr7 --device-testing -T tests/drivers/can/api/ --device-serial /dev/ttyUSB0 -vv -i
  2. See error

Expected behavior
Test case should pass as expected.

Impact
The test case drivers.can.api failing, complete twister test suite is then also concerned and is reporting errors.

Logs and console output

DEBUG   - DEVICE: *** Booting Zephyr OS build zephyr-v3.0.0-3117-g1e02dd0dc195  ***
DEBUG   - DEVICE: Running test suite can_api_tests
DEBUG   - DEVICE: ===================================================================
DEBUG   - DEVICE: START - test_get_core_clock
DEBUG   - DEVICE: PASS - test_get_core_clock in 0.1 seconds
DEBUG   - DEVICE: ===================================================================
DEBUG   - DEVICE: START - test_set_state_change_callback
DEBUG   - DEVICE: PASS - test_set_state_change_callback in 0.1 seconds
DEBUG   - DEVICE: ===================================================================
DEBUG   - DEVICE: START - test_set_bitrate_too_high
DEBUG   - DEVICE: PASS - test_set_bitrate_too_high in 0.1 seconds
DEBUG   - DEVICE: ===================================================================
DEBUG   - DEVICE: START - test_set_bitrate
DEBUG   - DEVICE: PASS - test_set_bitrate in 0.1 seconds
DEBUG   - DEVICE: ===================================================================
DEBUG   - DEVICE: START - test_set_loopback
DEBUG   - DEVICE: PASS - test_set_loopback in 0.1 seconds
DEBUG   - DEVICE: ===================================================================
DEBUG   - DEVICE: START - test_send_and_forget
DEBUG   - DEVICE: PASS - test_send_and_forget in 0.2 seconds
DEBUG   - DEVICE: ===================================================================
DEBUG   - DEVICE: START - test_add_filter
DEBUG   - DEVICE: PASS - test_add_filter in 0.1 seconds
DEBUG   - DEVICE: ===================================================================
DEBUG   - DEVICE: START - test_max_std_filters
DEBUG   - DEVICE: PASS - test_max_std_filters in 0.1 seconds
DEBUG   - DEVICE: ===================================================================
DEBUG   - DEVICE: START - test_max_ext_filters
DEBUG   - DEVICE: PASS - test_max_ext_filters in 0.1 seconds
DEBUG   - DEVICE: ===================================================================
DEBUG   - DEVICE: START - test_receive_timeout
DEBUG   - DEVICE: PASS - test_receive_timeout in 0.110 seconds
DEBUG   - DEVICE: ===================================================================
DEBUG   - DEVICE: START - test_send_callback
DEBUG   - DEVICE: PASS - test_send_callback in 0.2 seconds
DEBUG   - DEVICE: ===================================================================
DEBUG   - DEVICE: START - test_send_receive_std_id
DEBUG   - DEVICE: PASS - test_send_receive_std_id in 0.4 seconds
DEBUG   - DEVICE: ===================================================================
DEBUG   - DEVICE: START - test_send_receive_ext_id
DEBUG   - DEVICE: PASS - test_send_receive_ext_id in 0.4 seconds
DEBUG   - DEVICE: ===================================================================
DEBUG   - DEVICE: START - test_send_receive_std_id_masked
DEBUG   - DEVICE: PASS - test_send_receive_std_id_masked in 0.4 seconds
DEBUG   - DEVICE: ===================================================================
DEBUG   - DEVICE: START - test_send_receive_ext_id_masked
DEBUG   - DEVICE: PASS - test_send_receive_ext_id_masked in 0.4 seconds
DEBUG   - DEVICE: ===================================================================
DEBUG   - DEVICE: START - test_send_receive_msgq
DEBUG   - DEVICE: PASS - test_send_receive_msgq in 0.25 seconds
DEBUG   - DEVICE: ===================================================================
DEBUG   - DEVICE: START - test_send_invalid_dlc
DEBUG   - DEVICE: E: DLC of 9 exceeds maximum (8)
DEBUG   - DEVICE: PASS - test_send_invalid_dlc in 0.3 seconds
DEBUG   - DEVICE: ===================================================================
DEBUG   - DEVICE: START - test_send_receive_wrong_id
DEBUG   - DEVICE: PASS - test_send_receive_wrong_id in 0.117 seconds
DEBUG   - DEVICE: ===================================================================
DEBUG   - DEVICE: START - test_recover
DEBUG   - DEVICE: PASS - test_recover in 0.1 seconds
DEBUG   - DEVICE: ===================================================================
DEBUG   - DEVICE: START - test_get_state
DEBUG   - DEVICE: PASS - test_get_state in 0.1 seconds
DEBUG   - DEVICE: ===================================================================
DEBUG   - DEVICE: START - test_filters_preserved_through_mode_change
DEBUG   - DEVICE: PASS - test_filters_preserved_through_mode_change in 0.3 seconds
DEBUG   - DEVICE: ===================================================================
DEBUG   - DEVICE: START - test_filters_preserved_through_bitrate_change
DEBUG   - Timed out while monitoring serial output on rcar_h3ulcb_cr7
DEBUG   - run status: rcar_h3ulcb_cr7/tests/drivers/can/api/drivers.can.api timeout
INFO    - 2/2 rcar_h3ulcb_cr7           tests/drivers/can/api/drivers.can.api              FAILED Timeout (device 64.705s)

Environment (please complete the following information):

  • OS: Linux Ubuntu 20.04
  • Zephyr SDK 0.13.1
  • Commit SHA : 1e02dd0
@aaillet aaillet added bug The issue is a bug, or the PR is fixing a bug priority: low Low impact/importance bug area: CAN platform: Renesas R-Car Renesas R-Car labels Apr 27, 2022
@henrikbrixandersen
Copy link
Member

This is likely related to

ret = can_rcar_enter_halt_mode(config);
where can_set_mode() makes the R-Car CAN controller enter halt mode.

Does halt mode discard added filters? If so, they need to be re-added here.

@henrikbrixandersen henrikbrixandersen added Waiting for response Waiting for author's response and removed Waiting for response Waiting for author's response labels May 2, 2022
@henrikbrixandersen
Copy link
Member

@aaillet I do not have access to the R-Car hardware, so I cannot really drive the needed changes.

@aaillet
Copy link
Member Author

aaillet commented May 6, 2022

@henrikbrixandersen Sorry I was for some days, I'll investigate on how to fix this issue.

@aaillet
Copy link
Member Author

aaillet commented May 17, 2022

Does halt mode discard added filters? If so, they need to be re-added here.

@henrikbrixandersen In fact, we need to be in halt mode in order to apply selected filters.
I'm investigating in order to find out why the test is failing !

aaillet added a commit to iotbzh/zephyr that referenced this issue Jun 15, 2022
Fix issue zephyrproject-rtos#45169.

With this CAN controller, changing bit timing has to be done in controller
reset mode, resetting some registers to their default values.
TCR register, that is enabling loopback mode is one of these.
Because of this reset, the controller switch back from loopback
to normal mode without the test suite being notified, preventing
receiving sent frames afterwards.

To fix this issue, we are now storing useful registers values before
switching to reset mode and restoring these values in halt mode
before going back in operation mode.

Signed-off-by: Aymeric Aillet <[email protected]>
fabiobaltieri pushed a commit that referenced this issue Jul 1, 2022
Fix issue #45169.

With this CAN controller, changing bit timing has to be done in controller
reset mode, resetting some registers to their default values.
TCR register, that is enabling loopback mode is one of these.
Because of this reset, the controller switch back from loopback
to normal mode without the test suite being notified, preventing
receiving sent frames afterwards.

To fix this issue, we are now storing useful registers values before
switching to reset mode and restoring these values in halt mode
before going back in operation mode.

Signed-off-by: Aymeric Aillet <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: CAN bug The issue is a bug, or the PR is fixing a bug platform: Renesas R-Car Renesas R-Car priority: low Low impact/importance bug
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants