CAN communication on STM32MP157f-dk2 in Classical CAN (CAN2.0)

[ienecode]

Hi,

I would like to use CAN communication on my devboard : STM32MP157f-DK2.

So I prepared OS, unfortunatelly I have to flash STM32MP157c-DK2 version according with problem described below:

Faulty boards out of the box 

So, after run OS, I edited *.dts file, by initialized &m_can1 device on PA11 and PA12 pins, which one exposed  on the board connector - CN2, and connected "MCP2542 click CAN bus transceiver" board.

In OpenSTlinux userspace I try recive CAN frames by command: candump can0, and there is any problem, because when I send full frame with 8 bytes that it doesn't arrive to device. Maksimum only 5 bytes in frame arrives, like below:

What can be wrong with CAN in STM ?
Please for any tips.

[Ozone]

I assume the problem is in your interpretation of the output.

A standard CAN frame always contains an 8 byet payload. However, it is preceeded by a length code (DLC)  which tells the receiver how many of this 8 bytes are valid.

I would say, check with the documentation of the "host" (STM32MP157) CAN application, and the connected device(s).

My company e.g. extensively uses CANopen, were several defined frames have just a 1 or 2 byte payload.

[ienecode]

@Ozone 
Interpretation of the output ? In OpenStlinux The BOSCH M_CAN driver is enabled by default, to read frames by CAN I am susing can-utils (This repository contains some userspace utilities for Linux CAN subsystem (aka SocketCAN)).

To send frames from host I use below USB converter :

isCAN<->usb 

[Ozone]

Do you have a PC CAN adapter, and some monitoring software ?
Something like the relatively affordable PCAN dongle and the free PCAN-View do the job quite well.

I didn't work with STLinux can-utils yet, but the CAN standard is pretty clear.
The CAN low-level protocol is relatively complex compared to e.g. UART, I2C or SPI, and frame reception is usually handled by the peripheral (IP) alone. CAN frames with errors like incorrect length will be rejected/discarded immediately, and not passed into the "CAN mailbox" buffer or to the application.

[xchen]

Check your hardware setup as following.
1. The 120 ohm terminal resisters.
2. Use the same ground.
3. Make sure power supply is good.

[ienecode]

I do not use 120 ohm resistor because twice 60 ohm are included in transceiver MCP2542 Click. - please look on the below schematic:

[Ozone]

This is most probably not a signal issue.

If that was the case, no message reception would be reported by candump, and the MP157 CAN node would quickly run into error-passive and finally bus-off mode.

[SofLit]

Hello,

if you can let me intervene even I'm not MPU products expert.

From your first post, you shared a figure where the frame sent by your host contains 5 bytes and are received well by the MP157. Which is expected. But STM32MP1 has FDCAN interface supporting CAN-FD frames.

You didn't show the behavior where data length > 5 bytes.

Note that the data length with FDCAN can reach 64 bytes if you are using the peripheral in CANFD mode and the data length is included in the frame in the DLC field. So the application needs to read that field to extract the exact number of bytes received.

So the question here, how did you configure FDCAN from the MPU side? in CAN2.0 or in CANFD mode? from your transmitter screen shot I conclude you are sending data in CAN2.0 format. Are you sure you set FDCAN peripheral in Classical mode (CAN2.0)?

[Ozone]

> Note that the data length with FDCAN can reach 64 bytes if you are using the peripheral in CANFD mode  ...

I suspect now you confused the OP even more ...

I would definitely recommend to consult someone with CAN experience directly, perhaps a work mate or friend.

[SofLit]

---

@Ozone wrote:

> Note that the data length with FDCAN can reach 64 bytes if you are using the peripheral in CANFD mode  

I suspect now you confused the OP even more ...

---

Sorry? 

This is to warn him about the usage of the FDCAN cell in incorrect mode. That's why I asked him about his FDCAN peripheral configuration: CAN2.0: max 8 bytes or CANFD: max 64 bytes.