Fix fdcan array length

[MaJerle]

This PR fixes issue #123

In the STM32G0xx reference manual, chapter FDCAN, the structure of FDCAN Rx FIFO element is described as:

With DLC bits explained as:

As CanOpen is only operating in the Classic CAN, we can be in a situation where data length code is between 9-15, while the received message is only 8 bytes.

Such message could be legitimate simply because older (bxCAN) implementation may have wrongly set the reserved bit that indicated newer features for latest FDCAN implementation.

[MaJerle]

@Arslan8 @HamedJafarzadeh

[Arslan8]

Apologies for the late reply; I was busy with some other stuff. You're correct that Classical CAN can never carry more than 8 data bytes. I was referring to the raw DLC field, not the actual payload length.

In Classical CAN, DLC values 9–15 are valid on the wire but still represent an 8-byte payload. The potential issue is that the STM32 FDCAN RX header appears to preserve this raw DLC, while HAL_FDCAN_GetRxMessage() uses the DLC directly with DLCtoBytes[]. For example, raw DLC 9 maps to 12 bytes in that table even though FDFormat indicates Classical CAN and the actual payload is only 8 bytes.

So the case I am concerned about is:

Classic CAN, 8-byte payload, raw DLC = 9–15

rather than a Classical CAN message containing more than 8 bytes.

If the FDCAN peripheral or HAL normalizes/rejects DLC 9–15 before this point, then I agree the 8-byte buffer is sufficient, and I would prefer not to increase it. Otherwise, we can increase the receive buffer appropriately and submit a PR.

[Arslan8]

oh nvm, i started commenting without my coffee and thought this was the original issue :) .. @MaJerle, Yeah you got it! Thanks!