ChibiOS Free Embedded RTOS

Using 32F767, but probably applies to all.

1. The hardware allows use of CAN2 without CAN1 being active; while there are interactions, these appear to be solely or largely in the area of filters. (See 40.9.4 in RM0410 makes it clear that this is a supported configuration). However the current driver requires CAN1 to be started, even if not used, before CAN2 can be started.

2. canSTM32SetFilters(), which I assume to be the 'official' API for setting of the filters clearly expects to be called before the driver is started. However it is possible to update the filters at run-time by setting FINIT in CAN_FMR register. (I've got other comments on the API to the filters, but since they're by way of enhancements, I'll post them elsewhere)

hi,

Could you post a patch for this?

Giovanni

Giovanni wrote:Could you post a patch for this?

Eventually - not expecting to have hardware to play with and test for a week or two. And it'll include some extensions to the API to support filter updates on the fly. (Code's pretty much done; just needs testing/debugging, so can make available if anyone else has this problem)

Bump, is this still a thing?

Giovanni

Giovanni wrote:Bump, is this still a thing?

Giovanni

Yes it is - working on CAN ATM, but not to the point of having anything to submit yet.

CAN1 must be started before CAN2 (even when only CAN2 is used) on STM32F405 too.

bump

It is not fixed in stable_18.2.x.
See ChibiOS/os/hal/ports/STM32/LLD/CANv1/hal_can_lld.c

It looks pretty definite that if CAN2 is enabled, CAN1 has to be also enabled within the HAL. Possibly this can be done automatically in the LLD.

Should have some proposed updates to the LLD eventually - one point being considered is where one draws the line between the standard LLD and optional 'helper' functions. These helpers are very ST-specific, so logically would go with the ST-specific driver. But its debateable whether they should be in the single LLD file, or in a separate file. Any thoughts?

The assertion is correct even if less than optimal.

Probably it should be automatic like steved suggested, it should not be hard to do. Enable clock in canStart(), disable clock in canStop() if both instances are stopped, one "if".

Giovanni