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

CAN2 interface on STM32F105 not working #49747

Closed
danielstuart14 opened this issue Aug 31, 2022 · 3 comments
Closed

CAN2 interface on STM32F105 not working #49747

danielstuart14 opened this issue Aug 31, 2022 · 3 comments
Assignees
Labels
area: CAN bug The issue is a bug, or the PR is fixing a bug platform: STM32 ST Micro STM32

Comments

@danielstuart14
Copy link
Contributor

danielstuart14 commented Aug 31, 2022

Describe the bug
While testing a STM32F105RBT6 board, I found that the CAN2 inteface wasn't working properly.
While sometimes the can_stm32 driver wouldn't be able to initialize the hardware on startup (can_stm32: Failed to exit sleep mode), even when it initializes correctly I wasn't able to send frames through the interface (error -5).

CAN1 interface seems to work flawlessly, I'll attach here the board configuration I'm using.
I tested it on the latest release (v3.1) and with the current development branch (5b3f800). Both have the same behaviour.

To Reproduce
Steps to reproduce the behavior:
1 - Create a project with the CAN shell and logging enabled.
2 - Use a board with STM32F105 mcu and CAN2 interface configured.
3 - Try to send frames through the CAN_2 interface (can send CAN_2 XX XX)

Expected behavior
Devices is able to send frames through the CAN_2 interface

Impact
As the second CAN interface is one of the most important features of the STM32F105 family, this makes Zephyr a no go for this kind of device.

Logs and console output
image

image

Environment (please complete the following information):

  • OS: Linux
  • Toolchain: Zephyr SDK, STM32-HAL
  • Commit SHA or Version used: 5b3f800 and v3.1

Additional context
As no board layout is available for the STM32F105, I have attached the one I'm using. (CAN1 default pin, CAN2 remap1 pin, 12Mhz crystal, UART4 console)>

logs_can2.txt
boards.zip

@danielstuart14 danielstuart14 added the bug The issue is a bug, or the PR is fixing a bug label Aug 31, 2022
@str4t0m
Copy link
Collaborator

str4t0m commented Aug 31, 2022

Hi, I don't have any hardware where I could test this, and others I know are using the driver also mostly for STM32F4.
So we will need a bit more information in order to be able to solve this.
Are you observing the exact same behavior on v3.1 and the 5b3f800? Or does it differ, if yes how?

There were definitely a few changes since v3.1 was released.
Multi-instance support (#46646) was not merge in v3.1 and #49450 was also not merged, so I am pretty sure CAN2 would not work properly with the v3.1 release.
But from the driver side I currently don't see why it would fail to exit from sleep mode, on stm32f1 but not on stm32f4.

Another related point I found is that the pin remapping configuration was not valid for CAN2 on STM32F10x target.
I have opened a PR to fix that: #49765

@danielstuart14
Copy link
Contributor Author

Hello @str4t0m, both v3.1 and 5b3f800 have the same behaviour. I'm going to test on v2.7 later, but it demands some changes to the DTS which I still need to do.
Prior to multi-instance, only one CAN interface could be used at a time. Because of that, I tested CAN2 without CAN1 enabled, but the behaviour was the same.
I also tested with the default PIN mapping and got the same issue.

I'll run more tests on my side and report here.
If anyone is interested, I'm using this hardware here: https://github.com/EliasKotlyar/Canfilter
For Zephyr to work with it, you'll need to change the crystal (or run it in a lower Core frequency), since PLL2 isn't working with Zephyr (At least I wasn't able to make it work). I changed it to a 12MHz crystal. (I'll open a bug about this issue once I do more tests)

@danielstuart14
Copy link
Contributor Author

danielstuart14 commented Sep 5, 2022

Testing with latest commits (currently at e9e7ad3) got CAN_2 working!
It seems like #49765 from @str4t0m fixed the issues with can2.

Huge thanks @str4t0m!
image

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: STM32 ST Micro STM32
Projects
None yet
Development

No branches or pull requests

2 participants