STM32H7 CAN bus not receiving a particular unlucky message

[hsamurai]

I have a CAN bus between STM32H745 and STM32F042 processors using Standard CAN for communicating. The transfer, receive just works fine for any packet other than the following:

 

I cannot explain it. The data byte starts with 0xd2 0x01, STM32H7 does not receive it. This had been working fine until I changed the second byte to 1 from 0 (This is a version message, bumped the Major version from 0 to 1, hence the change). The logic analyzer is hooked to RX line of STM32H7. Using logic analyzer, I can see the message is coming all the way to STM32H7 passing through transceivers.

I use the same protocol between two STM32F042 processors. There is no problem talking. When one end is switched to STM32H7, then only the above particular message is not received. Everything else seems fine.

If I send <0xd2 0x00 etc> or <0xd2 0x02 etc> or <0xd2 0x03 etc> no problems on receiving. When the second character is 0x01, no message.

If it was a filter or configuration issue, I wouldn't receive any message. But I do receive all the messages. This is between two microcontrollers only.

Any ideas ? If you look at the line, CRC seems all 1's. Could it be that ? Do all 1s mean CRC error ? I repeat it's only this unlucky message.

Thanks for any leads.

[waclawek.jan]

There's no but stuffing beyond data byte 5, which is an error. Transmit the same message from the 'F042 and compare.

I am not familiar with the CAN module in H7 but find it unlikely to be error in the module itself, i.e. I'd start from the premise that this is software error. Try to transmit this message with as little software as possible, i.e. no Cube, RTOS, interrupts, etc.

JW

[Ozone]

> There's no but stuffing beyond data byte 5, which is an error.

I am not sure how that image was generated, the monitoring tool probably suppresses stuffing bits.

But it shows no value for DB4, bit 4, which seems a bit strange.

The config settings of the CAN unit might be different, especially for the sampling point.

Have you tried with significantly lower baudrate ?

[waclawek.jan]

I might have misunderstood the setup - is this a packet transmitted by 'F042 and received by 'H7?

If so, hook up the analyzer to the 'F042's Rx. Maybe there's problem with the echo.

Does the transmitter throw any error/flag?

> Have you tried with significantly lower baudrate ?

+1

JW

[hsamurai]

I finally found the problem. It turned out to be a hardware problem. One of the transceivers was acting due to another signal messing the CANH/CANL which causes stuffing errors, framing errors. I bought an off the shelf CAN analyzer. I hooked it up to individual nodes isolated, send packets and monitored traffic. Together with the scope, I was able to isolate it to transceiver. I don't know why it was acting only on 5th byte of certain data pattern and showed stuffing error. Who knows when hw is not setup right.

One thing I found, one of the nodes the baud rate is measured 252kHz on the scope while the other one is 250kHz, although both were setup to run 250kHz. But it didn't really affect the comm after hw is setup properly.

Thank you for the directions.

[waclawek.jan]

Thanks for coming back with the solution.

> I bought an off the shelf CAN analyzer.

Care to share model and impressions?

Please select your post as Best so that thread is marked as solved.

JW

[hsamurai]

The CAN analyzer I bought was Microchip CAN Bus Analyzer APGDT002.