Description
Description of defect
The mbed documentation of the CAN api refers to filter handle in two places:
int CAN::read(CANMessage &msg, int handle)int CAN::filter(unsigned int id, unsigned int mask, CANFormat format, int handle)
However, the meaning of the handle parameter in the STM32 code is different than the mbed documentation, and means two different, incompatible things.
The meaning of handle in the STM32 CAN::read is actually a FIFO number (0 or 1) to read from.
However, there is no way in the mbed API to use FIFO 1, because the STM32 CAN::filter always sets filters to use FIFO 0. In the STM32 CAN::filter, handle is actually referring to a filter bank number.
Further, the default CANFormat for CAN::filter is CANAny, but the STM32 code can't configure filters for this. But instead of returning 0 if its format parameter is CANAny, the STM32 can_filter() returns 1 and does nothing (it should return 0 in this case).
Target(s) affected by this defect ?
All STM32 targets that have CAN peripherals.
See mbed-os/targets/TARGET_STM/can_api.c, lines 989-991 (can_filter()) and lines 825-865 (can_read())
Toolchain(s) (name and version) displaying this defect ?
All
What version of Mbed-os are you using (tag or sha) ?
mbed-os-5.14
What version(s) of tools are you using. List all that apply (E.g. mbed-cli)
mbed-cli 1.10.1
How is this defect reproduced ?
- Passing a non-zero
handleparameter toCAN::readwill never return a message - Passing a
formatparameter ofCANAnytoCAN::filterwill not do anything but will return 1 anyway