NetMF 4.3 CERB 40 II CANBUS bug?

ControllerAreaNetwork.SendMessage does not send data from ControllerAreaNetwork.Message but fixed values (0xff, 0x00, 0x00, 0x00 ,0x34, 0x00, 0xff)

With the much appreciated native support for canBus in NetMF 4.3 I upgraded from 4.2 to 4.3 and replaced the managed driver code with the new ControllerAreaNetwork class. On reception everything works fine. When sending however the message seems to be transmitted with fixed data independent of content of the message (ArbitrationId is ok).

I tried following methods to initialize the data but none of them works:
var message1 = new ControllerAreaNetwork.Message() { ArbitrationId = 1};
for (byte i = 0; i < 8; i++)
message1.Data[i] = i;

            var message2 = new ControllerAreaNetwork.Message() { 
                   ArbitrationId = 1,
                   Data = new byte[] {1, 2, 3, 4, 5, 6, 7, 8 };

Remark: diagnostics made with independent PIC24 ecan module working fine with NetMF 4.2 and managed driver.

Bug ?

Not sure I understand. Please tell is what you send and what you actually receive the other end.

even I understand :smiley:
he sends: {1, 2, 3, 4, 5, 6, 7, 8} to aid 1
and receives (0xff, 0x00, 0x00, 0x00 ,0x34, 0x00, 0xff)

CAN is working fine in 4.3 for me.

[EDIT]: On G120 custom board.

That is correct:

I send: {1, 2, 3, 4, 5, 6, 7, 8}
and receive (0xff, 0x00, 0x00, 0x00 ,0x34, 0x00, 0xff)

This is NOT G120 board but CERB40 (first implementation for STM32) !

I do receive 8 bytes, otherwhise it would not be a valid CAN message (typo in previous post)
The point is that the data from sender side call is not transmitted but instead some fixed values. I assume the STM32 driver does not copy the data bytes to the STM32 registers on transmission and some arbitrary bytes are being transmitted

Reception and verification of the message content is done on independent PIC24 module (software on PIC24 is unmodified and worked fine togheter with CERB 40 NetMF 4.2 and managed driver)

@ LGOR - We did run a quick test on the Cerberus and it sent and received fine. As andre.m suggested, if you post a complete and minimal example that shows the issue we can go from there.

Problem solved: there is a Length property on ControllerAreaNetwork.Message which must be set explicit to 8 (looks a bit odd because can messages are always 8 bytes long and additional Data[] is always an array of length 8.

Anyway, code changed from

var msg = new ControllerAreaNetwork.Message() {
ArbitrationId = 1,
Data = new byte[] { 0, 1, 2, 3, 4, 5, 6, 7 }}


var msg = new ControllerAreaNetwork.Message() {
ArbitrationId = 1,
Data = new byte[] { 0, 1, 2, 3, 4, 5, 6, 7 },
Length = 8 };

and everything works fine!

@ LGOR - actually can messages can have anywhere from zero to right bytes. The bit field in the actual message is called dlc. A quick internet search will show more details.

Googled for can and dlc and … of course you are right! I just didn’t encounter applications with can messages different dan 8 bytes long! (maybe defaulting Length to 8 might be not a bad idea)

Learned something again … the hard way ???


If I remember right, the message has always 8 Bytes, but DLC tells the Receiver how many of them contain valid data.

No, that is not correct.

Possible, I’m not expert at CAN