Skip to content

Conversation

@congnguyenhuu
Copy link
Contributor

@congnguyenhuu congnguyenhuu commented Nov 22, 2022

This patch introduces support for NXP S32 CANEXCEL (CANXL) peripheral. CAN protocol supporting:

  • CAN classic
  • CAN FD

Currently, remote transmission request is not supported as this feature is not available on NXP S32 CANXL HAL.

Updates in NXP HAL: zephyrproject-rtos/hal_nxp#206

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.

@congnguyenhuu Thank you for your contribution. However, please split the suggested API change for the CAN RX filters into a separate PR so that it can be reviewed stand-alone (the current approach will cause all other boards to fail as they do not implement filtering of FD frames). You can put this PR as draft until a decision regarding the API change has been made and merged.

@congnguyenhuu congnguyenhuu marked this pull request as draft November 23, 2022 01:44
@zephyrbot zephyrbot added manifest manifest-hal_nxp DNM This PR should not be merged (Do Not Merge) labels Dec 1, 2022
@zephyrbot
Copy link

zephyrbot commented Dec 1, 2022

The following west manifest projects have been modified in this Pull Request:

Name Old Revision New Revision Diff
hal_nxp zephyrproject-rtos/hal_nxp@d33133d zephyrproject-rtos/hal_nxp#206 zephyrproject-rtos/hal_nxp#206/files

Note: This message is automatically posted and updated by the Manifest GitHub Action.

@congnguyenhuu congnguyenhuu marked this pull request as ready for review January 4, 2023 13:54
@zephyrbot zephyrbot added the area: native port Host native arch port (native_sim) label Jan 4, 2023
Comment on lines 176 to 180
Copy link
Member

Choose a reason for hiding this comment

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

I am still not 100% sold on this change.

We need to document that the full width of the timestamp field is not used by all drivers; some timestamps will wrap around at 32 bit. You also need to look into the format specifiers used (e.g. in the CAN shell). They likely need updating to match the 64 bit size?

Another option could be to mask the upper 32 bit of the timestamp on NXP CANXL, as this seems to be the only device supporting 64 bit timestamps for now?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I still keep change timestamp 64bit. I updated document and related files.

Copy link
Member

Choose a reason for hiding this comment

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

I have tried to survey the market for other CAN controllers supporting 64 bit timestamps, but came up short. Please leave out this change for now.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Before you said that there are some CAN controllers supporting 32 bits timestamp, So I updated to support that.
What do you think that?

Copy link
Member

Choose a reason for hiding this comment

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

I am sorry, my initial comment said 32 bit, where I meant the existing 16 bits. Please leave out any changes to the timestamp counter bit size from this PR and - if deemed needed - submit a separate PR for this after the S32 CAN driver PR goes in.

Copy link
Member

Choose a reason for hiding this comment

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

How should this error be handled?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

it seems my error msg is not correct with which handling here. In this handler called Canexcel_Ip_ReceiveFD to check MB empty (complete receive msg)to ready for receiving next msg. the msg should be MB %d is not ready for receiving next message

Comment on lines +737 to +843
Copy link
Member

Choose a reason for hiding this comment

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

If so, it needs to be enabled in listen-only mode so it does not disturb the bus with ACKs/error frames until explicitly enabled by calling can_start().

@dleach02
Copy link
Member

dleach02 commented Apr 4, 2023

@henrikbrixandersen, thank you for your feedback and review on this PR. Can you highlight which items are still considered a blocker so the author can address them?

Copy link
Member

@manuargue manuargue left a comment

Choose a reason for hiding this comment

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

Just a minor request in the docs

manuargue
manuargue previously approved these changes Apr 19, 2023
Copy link
Member

@manuargue manuargue left a comment

Choose a reason for hiding this comment

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

Hi @henrikbrixandersen, thanks for the thoroughly review. Could you please have another look to the changes to see if there are still unresolved comments? We would like to have this feature included in v3.4 if possible. We can also consider having a first working version merged, and address further improvements with a follow up PR.

@dleach02
Copy link
Member

@henrikbrixandersen can you return to this PR to determine if your change requests have been addressed?

Comment on lines 176 to 180
Copy link
Member

Choose a reason for hiding this comment

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

I have tried to survey the market for other CAN controllers supporting 64 bit timestamps, but came up short. Please leave out this change for now.

Copy link
Member

Choose a reason for hiding this comment

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

So, does setting .retransmission = 0 mean no retransmissions? If so, it is a violation of the Zephyr can_send() API when CAN_MODE_ONE_SHOT is not set.

Comment on lines 480 to 485
Copy link
Member

Choose a reason for hiding this comment

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

Please leave these additions out.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I left out the update for support counter statistic

Comment on lines +737 to +843
Copy link
Member

Choose a reason for hiding this comment

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

Please point me to where this is done?

@congnguyenhuu
Copy link
Contributor Author

@henrikbrixandersen Thank for revisiting this PR. I addressed all comment.

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.

Please leave out the timestamp changes, at least for now, and I think we're good to go.

This patch introduces support for NXP S32 CANEXCEL (CANXL) peripheral.

CAN protocol supporting:
- CAN classic
- CAN FD

Remote transmission request is not supported as this feature is not
available on NXP S32 CANXL HAL.

Signed-off-by: Cong Nguyen Huu <[email protected]>
Enable CAN instances on s32z270dc2_r52 boards

Signed-off-by: Cong Nguyen Huu <[email protected]>
Add CAN document to the list of supported features

Signed-off-by: Cong Nguyen Huu <[email protected]>
@congnguyenhuu
Copy link
Contributor Author

@henrikbrixandersen I left out the timestamp change. Do you have any blocker for PR?

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.

Thank you, looks good - and thank you for your patience with the review process!

@dleach02
Copy link
Member

@congnguyenhuu please remove the west.yml from your PR. The HAL change was merged a while ago and is part of the current Zephyr west.yml.

@congnguyenhuu
Copy link
Contributor Author

@dleach02 I removed it as soon as the HAL change was merged.

@carlescufi carlescufi merged commit 55fa936 into zephyrproject-rtos:main Apr 29, 2023
@manuargue manuargue deleted the s32ze-support-can branch April 30, 2023 15:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area: CAN area: Devicetree Binding PR modifies or adds a Device Tree binding area: native port Host native arch port (native_sim) area: Networking area: Sockets Networking sockets manifest manifest-hal_nxp platform: NXP NXP

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants