CAN: read can do only up to 8 bytes, error if more is reported

[0xc0170]

Summary of changes

If HAL implementation writes more than 8 bytes of data, error immediately. CANMessage defines only 8 bytes of data, lenght cannot be > 8.

This fixes #15361

@Martyx00 Please review

Impact of changes

Migration actions required

Documentation

---

Pull request type

[x] Patch update (Bug fix / Target update / Docs update / Test update / Refactor)
[] Feature update (New feature / Functionality change / New API)
[] Major update (Breaking change E.g. Return code change / API behaviour change)

---

Test results

[x] No Tests required for this change (E.g docs only update)
[] Covered by existing mbed-os tests (Greentea or Unittest)
[] Tests / results supplied as part of this PR

---

Reviewers

---

[0xc0170]

I'll check if we need the same fix for 5.15 branch, if yes, I'll create new PR as well.

[0xc0170]

CI startd

[Martyx00]

The only issue that I can see is that if the FD CAN is used:

mbed-os/targets/TARGET_STM/can_api.c

Line 21 in 1dd0bce

#ifdef FDCAN1

than the data could be up to 64 bytes (https://www.can-cia.org/can-knowledge/can/can-fd/). If I am not mistaken, currenly MbedOS does not support FD CAN. However, when it will, it will be necessary to not only extend the size of the data field in the CAN_Message structure

mbed-os/hal/include/hal/can_helper.h

Line 63 in c02e101

unsigned char data[8]; // Data field

, but also adjust this condition.

[mbed-ci]

Jenkins CI Test : ✔️ SUCCESS

Build Number: 1 | 🔒 Jenkins CI Job | 🌐 Logs & Artifacts

CLICK for Detailed Summary

jobs	Status
jenkins-ci/mbed-os-ci_build-cloud-example-ARM	✔️
jenkins-ci/mbed-os-ci_build-cloud-example-GCC_ARM	✔️
jenkins-ci/mbed-os-ci_unittests	✔️
jenkins-ci/mbed-os-ci_build-greentea-ARM	✔️
jenkins-ci/mbed-os-ci_build-greentea-GCC_ARM	✔️
jenkins-ci/mbed-os-ci_build-example-ARM	✔️
jenkins-ci/mbed-os-ci_build-example-GCC_ARM	✔️
jenkins-ci/mbed-os-ci_greentea-test	✔️

[0xc0170]

The only issue that I can see is that if the FD CAN is used:

@Martyx00 correct, it will require rework in the driver itself (contstructor limites also lenght to maximum 8) and assumping the message is predefined to be just 8 bytes in the driver, all HAL implementations use 8 bytes mode only (if they do not, we will catch it via this error).

I wonder if this FDCAN1 in HAL makes sense as if a user would something define this, it could lead to similar issues that this PR is fixing - however we will catch it with this fix so overflow should not happen
@jeromecoutant is this correct or I misunderstood FDCAN1 in CAN HAL?

[jeromecoutant]

If I am not mistaken, currenly MbedOS does not support FD CAN.

I don't know CAN very much... but I thought that ST FD CAN was OK in mbed-os.

#ifdef FDCAN1

In all STM32 newest families, FDCAN IP has replaced CAN IP.

[Martyx00]

Not sure if MbedOS officially supports FD CAN. But none of the boards mentioned here: https://os.mbed.com/platforms/?q=&Communication=CAN have FD CAN. I have the Nucleo with the L5 chip somewhere around so I can test if it is possible to use FD CAN with MbedOS in coming days. If it is possible, than there is likely to be some trouble due to the size restriction of the CAN_Message (it may take some time as I have to also find a second board that can send the FD CAN frames - I only have one L5 Nucleo).

[Martyx00]

Did a quick check in the source code, FD CAN does not seem to be supported. Any limitations of this PR should be taken into account when implementing it in the future.

[0xc0170]

@Martyx00 happy with this pull request?

[Martyx00]

@Martyx00 happy with this pull request?

Yes