You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
Environment (please complete the following information):
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)>
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
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)
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](https://user-images.githubusercontent.com/8076962/187722382-a2c00689-bcb9-4296-97f1-f8f8565596ca.png)
Environment (please complete the following information):
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
The text was updated successfully, but these errors were encountered: