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

can: isotp: Add CAN-FD support to ISO-TP #60323

Merged
merged 5 commits into from Sep 14, 2023

Conversation

gramsay0
Copy link
Contributor

@gramsay0 gramsay0 commented Jul 13, 2023

  • Add CAN-FD support to ISO-TP
  • Update ISO-TP sample to work with CAN-FD
  • Update existing ISO-TP unit tests to work with CAN-FD
  • Add CAN-FD specific unit tests
    • Mandatory padding of frames > 8 bytes to next DLC
    • Validation that RX_DL in consecutive frames matches first frame

Thanks @dale-herman for doing most of the work

@alexanderwachter
Copy link
Member

Just scrolled over it. Looks good at a first glance! You may extend the copyright notice, because it is a bigger extension of functionality.

@gramsay0
Copy link
Contributor Author

Just scrolled over it. Looks good at a first glance! You may extend the copyright notice, because it is a bigger extension of functionality.

@alexanderwachter thanks!

If you have time, could you please have a look over this RFC #59896 and give some feedback?
Apologies for not tagging you in it sooner, I would appreciate your input

Copy link
Member

@martinjaeger martinjaeger left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the contribution, only got some minor comments.

May I ask you to move the changes related to CONFIG_ISOTP_ENABLE_TX_PADDING and CONFIG_ISOTP_REQUIRE_RX_PADDING into a dedicated commit? As far as I can see they are not related to CAN-FD support. This will make it easier to understand why the change was made in the future.

samples/subsys/canbus/isotp/src/main.c Outdated Show resolved Hide resolved
samples/subsys/canbus/isotp/Kconfig Outdated Show resolved Hide resolved
tests/subsys/canbus/isotp/conformance/testcase.yaml Outdated Show resolved Hide resolved
subsys/canbus/isotp/isotp.c Outdated Show resolved Hide resolved
@gramsay0
Copy link
Contributor Author

May I ask you to move the changes related to CONFIG_ISOTP_ENABLE_TX_PADDING and CONFIG_ISOTP_REQUIRE_RX_PADDING into a dedicated commit? As far as I can see they are not related to CAN-FD support. This will make it easier to understand why the change was made in the future.

@martinjaeger Okay, will do

@gramsay0
Copy link
Contributor Author

@martinjaeger here is the padding fix PR #60661
I'll rebase this PR once that is merged

@gramsay0 gramsay0 force-pushed the isotp-canfd branch 2 times, most recently from ad26165 to d5be785 Compare July 30, 2023 04:14
martinjaeger
martinjaeger previously approved these changes Aug 2, 2023
Copy link
Member

@henrikbrixandersen henrikbrixandersen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is ISO-TP via CAN-FD part of ISO 15765-2?

subsys/canbus/isotp/Kconfig Outdated Show resolved Hide resolved
@martinjaeger
Copy link
Member

Is ISO-TP via CAN-FD part of ISO 15765-2?

Yes, it's part of the third edition of the spec (from 2016).

@martinjaeger
Copy link
Member

Please ignore the first two commits. The will be removed through rebasing after #61732 is merged.

Copy link
Member

@henrikbrixandersen henrikbrixandersen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good, @martinjaeger. I'd prefer if the last commit could be squashed into the previous commits to avoid the odd history, though.

@@ -1106,7 +1124,7 @@ void *isotp_conformance_setup(void)
zassert_true(device_is_ready(can_dev), "CAN device not ready");

ret = can_set_mode(can_dev, CAN_MODE_LOOPBACK |
(IS_ENABLED(CONFIG_ISOTP_USE_CAN_FD) ? CAN_MODE_FD : 0));
(IS_ENABLED(CONFIG_CAN_FD_MODE) ? CAN_MODE_FD : 0));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this needs to fallback to classic CAN if the CAN controller does not support CAN-FD.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In that case IS_ENABLED(CONFIG_CAN_FD_MODE) should evaluate to 0 and FD would not be enabled.

Or do you have a case in mind where we'd have one controller with FD capabilities and one without on the same board/SOC, so that we have CONFIG_CAN_FD_MODE=y even though one controller doesn't support it?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

CONFIG_CAN_FD_MODE can be enabled whether the CAN controller supports CAN-FD or not.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, that's exactly how the test is run at the moment, e.g. with native_posix. The first case is with default setup CONFIG_CAN_FD_MODE=n (even though it would be supported) and the two other cases with extra config CONFIG_CAN_FD_MODE=y and some different max data length settings.

Or maybe I misunderstand your question/request?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The tests need to be able to run on any CAN controller, regardless of CONFIG_CAN_FD_MODE being y or n and whether the CAN controller driver supports CAN-FD or not.

I'd suggest using can_get_capabilities() to determine if CAN_MODE_FD should be passed to can_set_mode() . That does not require any #ifdef on CONFIG_CAN_FD_MODE.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It was slightly more complicated than just checking with can_get_capabilities and applying the mode accordingly. Now we have the existing main test suite, which is skipped if FD is enabled for a controller that does not have FD capabilities. To check that correct errors are returned in such cases, I added another test suite canfd_notsup.c.

@martinjaeger
Copy link
Member

This looks good, @martinjaeger. I'd prefer if the last commit could be squashed into the previous commits to avoid the odd history, though.

I added a new commit so that the authorship of the different changes is clear. But I'm fine with squashing it if @gramsay0 agrees.

Copy link
Contributor Author

@gramsay0 gramsay0 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good work!

include/zephyr/canbus/isotp.h Outdated Show resolved Hide resolved
include/zephyr/canbus/isotp.h Outdated Show resolved Hide resolved
subsys/canbus/isotp/isotp.c Show resolved Hide resolved
tests/subsys/canbus/isotp/conformance/src/main.c Outdated Show resolved Hide resolved
ISO-TP CAN-FD support can be enabled at runtime.

Signed-off-by: Grant Ramsay <gramsay@enphaseenergy.com>
Signed-off-by: Martin Jäger <martin@libre.solar>
Enable this sample to be used with CAN-FD

Signed-off-by: Grant Ramsay <gramsay@enphaseenergy.com>
Allow existing tests to run with CAN-FD.
Add new CAN-FD specific tests.

Signed-off-by: Grant Ramsay <gramsay@enphaseenergy.com>
Signed-off-by: Martin Jäger <martin@libre.solar>
@martinjaeger
Copy link
Member

I hope that all review comments are addressed now and unrelated CI failures are gone.

The ISO-TP test suites and sample were successfully tested on the following boards:

  • native_posix
  • nucleo_g474re (CAN-FD support)
  • nucleo_f072rb (classical CAN only)

Copy link
Member

@henrikbrixandersen henrikbrixandersen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good. A couple of minor observations:

tests/subsys/canbus/isotp/conformance/src/mode_check.c Outdated Show resolved Hide resolved
Comment on lines +4 to +9
# | Case # | Controller type | Selected mode | Example board |
# +--------+------------------------+----------------------+----------------+
# | 1 | Classical CAN only | CONFIG_CAN_FD_MODE=n | nucleo_f072 |
# | 2 | Classical CAN only | CONFIG_CAN_FD_MODE=y | nucleo_f072 |
# | 3 | Classical CAN + CAN-FD | CONFIG_CAN_FD_MODE=n | native_posix |
# | 4 | Classical CAN + CAN-FD | CONFIG_CAN_FD_MODE=y | native_posix |
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These cases significantly increase the time required for running the ISO-TP conformance test suite on real hardware. Can the tests be optimized in time somehow?

Example of time spent running this test suite on five random boards on my desk:

INFO    -  6/35 frdm_k64f                 tests/subsys/canbus/isotp/conformance/canbus.isotp.conformance.fd.txdl_64 PASSED (device: 0240000047784e45004e9003d9170022e561000097969900, 8.151s)
INFO    -  7/35 lpcxpresso55s36           tests/subsys/canbus/isotp/conformance/canbus.isotp.conformance.fd.txdl_64 PASSED (device: 001069887263, 14.602s)
INFO    -  8/35 stm32f3_disco             tests/subsys/canbus/isotp/conformance/canbus.isotp.conformance.fd.txdl_64 PASSED (device: 066EFF555052836687113518, 4.123s)
INFO    -  9/35 mimxrt1060_evkb           tests/subsys/canbus/isotp/conformance/canbus.isotp.conformance.fd.txdl_64 PASSED (device: 0229000033f4cd1100000000000000000000000097969905, 33.479s)
INFO    - 10/35 nucleo_g474re             tests/subsys/canbus/isotp/conformance/canbus.isotp.conformance.fd.txdl_64 PASSED (device: 0041001B3438510B34313939, 13.539s)
INFO    - 11/35 frdm_k64f                 tests/subsys/canbus/isotp/conformance/canbus.isotp.conformance.fd.txdl_32 PASSED (device: 0240000047784e45004e9003d9170022e561000097969900, 10.311s)
INFO    - 12/35 lpcxpresso55s36           tests/subsys/canbus/isotp/conformance/canbus.isotp.conformance.fd.txdl_32 PASSED (device: 001069887263, 11.119s)
INFO    - 13/35 stm32f3_disco             tests/subsys/canbus/isotp/conformance/canbus.isotp.conformance.fd.txdl_32 PASSED (device: 066EFF555052836687113518, 3.966s)
INFO    - 14/35 mimxrt1060_evkb           tests/subsys/canbus/isotp/conformance/canbus.isotp.conformance.fd.txdl_32 PASSED (device: 0229000033f4cd1100000000000000000000000097969905, 37.112s)
INFO    - 15/35 nucleo_g474re             tests/subsys/canbus/isotp/conformance/canbus.isotp.conformance.fd.txdl_32 PASSED (device: 0041001B3438510B34313939, 13.679s)
INFO    - 16/35 frdm_k64f                 tests/subsys/canbus/isotp/conformance/canbus.isotp.conformance.fd.unused PASSED (device: 0240000047784e45004e9003d9170022e561000097969900, 16.917s)
INFO    - 17/35 lpcxpresso55s36           tests/subsys/canbus/isotp/conformance/canbus.isotp.conformance.fd.unused PASSED (device: 001069887263, 10.552s)
INFO    - 18/35 stm32f3_disco             tests/subsys/canbus/isotp/conformance/canbus.isotp.conformance.fd.unused PASSED (device: 066EFF555052836687113518, 14.584s)
INFO    - 19/35 mimxrt1060_evkb           tests/subsys/canbus/isotp/conformance/canbus.isotp.conformance.fd.unused PASSED (device: 0229000033f4cd1100000000000000000000000097969905, 33.130s)
INFO    - 20/35 nucleo_g474re             tests/subsys/canbus/isotp/conformance/canbus.isotp.conformance.fd.unused PASSED (device: 0041001B3438510B34313939, 14.217s)
INFO    - 21/35 frdm_k64f                 tests/subsys/canbus/isotp/conformance/canbus.isotp.conformance PASSED (device: 0240000047784e45004e9003d9170022e561000097969900, 17.851s)
INFO    - 22/35 lpcxpresso55s36           tests/subsys/canbus/isotp/conformance/canbus.isotp.conformance PASSED (device: 001069887263, 11.913s)
INFO    - 23/35 mimxrt1060_evkb           tests/subsys/canbus/isotp/conformance/canbus.isotp.conformance PASSED (device: 0229000033f4cd1100000000000000000000000097969905, 31.035s)
INFO    - 24/35 stm32f3_disco             tests/subsys/canbus/isotp/conformance/canbus.isotp.conformance PASSED (device: 066EFF555052836687113518, 14.670s)
INFO    - 25/35 nucleo_g474re             tests/subsys/canbus/isotp/conformance/canbus.isotp.conformance PASSED (device: 0041001B3438510B34313939, 14.054s)

Do we really need to test with different TX_DLs on all boards or could a simple unit-like test (e.g. on POSIX) be sufficient for the different configurations? I mean, these tests validate the protocol implementation, not as much as the protocol interaction with the particular CAN controller?

Another option could be to tag some of these tests as "slow".

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There will be some more upcoming ISO-TP updates. Let's leave the optimization of test time for a future PR.

Copy link

@dale-herman dale-herman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good.

@martinjaeger
Copy link
Member

Fixed the typo in the test naming identified by @henrikbrixandersen. Please re-approve once again, @alexanderwachter . Thanks!

martinjaeger
martinjaeger previously approved these changes Sep 13, 2023
Copy link
Member

@martinjaeger martinjaeger left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approval and thanks for the parts of the work @gramsay0 and @dale-herman have done. Also thanks for all reviews.

Add a test to check error codes if attempting to use ISO-TP with CAN FD
mode even though the controller supports classical CAN only.

Signed-off-by: Martin Jäger <martin@libre.solar>
Even though it was leading to the same result, the function should use
its parameter and not the global variable for desired frames.

Signed-off-by: Martin Jäger <martin@libre.solar>
Copy link
Member

@alexanderwachter alexanderwachter left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks Martin!

@carlescufi carlescufi merged commit ef77fe3 into zephyrproject-rtos:main Sep 14, 2023
17 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants