Anyone that knows the details? Seems backwards.
CubeMx generates an init-fuction for CAN which eventually calls HAL_CAN_Init(). The very first part of this function is to exit sleep-mode. As per documentation this means "syncing" - waiting for 11 idle bits.
Once this has been done HAL_CAN_Init() enters init mode and configures among other things the BTR, bitrate.
But does this not seem a bit odd? Syncing with the bus before knowing what bitrate to use? What bittrate is the very first HAL_CAN_Init() using to sync? The reset value of the prescaler register is 0 so It is a very high bitrate - perhaps like 3 Mbit/s.
OK. So with this kind of speed perhaps no problem ever getting past that part as any reasonable actual CAN bitrate, 11 idle bits will look like many many bits, but then one actually fails doing what one is supposed to do - wait on 11 idle bits !?
Additionaly,
A case where this actually will be noticed is when HAL_CAN_Init() does fail - e.g. when the CAN PHY is initially configured in Standby mode at startup then initial HAL_CAN_Init() will fail here and return - skipping setting e.g. the requested bitrate yet bxCAN still "exiting sleep". Later when the main application sets PHY to normal, bxCAN exits sleep mode (finding idle) and is then in Normal mode but with a "undefined" configuration and will be a bad CAN node on the bus since it is acting using a undefined configuration.
It would be more robust/consistent if HAL_CAN_Init() would not stay in "exit sleep" when it returns.
