CAN or CAN(NOT)

[me_mickey_2006]

Posted on August 21, 2006 at 11:56

CAN or CAN(NOT)

[me_mickey_2006]

Posted on October 13, 2005 at 13:59

Dear moderator! :-Y

I must say the datasheet on CAN controller of STR7 is very very poor!

First: when CAN controller is in test mode with silent and loopback on it doesn't activate RxOk flag in CAN Status Register when message arrives, whic should not be so!?

Question: why is in ST Library version 3.0 extended id etracted in this way:

pCanMsg->Id = ((CAN->sMsgObj[1].A2R >> 2) & 0x07FF)

| ((u32)CAN->sMsgObj[1].A1R << 11)

| (((u32)CAN->sMsgObj[1].A2R & 0x0003) << 27);

?

In documentation there states that A1R holds lower 16 bits of extended ID and A2R holds higher 13 bits of extended id, is this not so?

Are there any known problems in receiving of extended id messages as upon reception content of A1R and A2R registers are all 0.

Thank you.

[me_mickey_2006]

Posted on October 13, 2005 at 16:47

Well this is the thing,

I still think RxOk flag doesn't get activated in loopback silent mode!

On extended identifiers it is perfectly ok to use A1R for lower 16 bits and A2R for upper 13 bits of extended identifier, I don't know why is all of that shifting done in library functions!

[davidbellegarde9]

Posted on October 17, 2005 at 08:17

Hello,

About the first point which is the assertion of the RxOK bit in the status register: this bit IS NOT asserted in loopback mode because the Rx pin is not monitored in this mode, only TxOK will be asserted when a transmission will occur.

About the second point which is regarding to the Id of the message, it seems it could be 2 ways to understand the datasheet, here is the right one: when an extended Id is stocked, the 11 LSBs should be the ID[28:18] (which are the standard ID) (in A1R), the next higher bit are the ID[15:0] (in A2R) and the MSBs are ID[17:16] (in A1R). Perhaps a easier way would have to be done. This should explain the way the library extracts the Id.

About the lack of information in datasheet, it seems the Ip came from a third party which gave a previous reference manual which was as ''poor'' as this one.

[me_mickey_2006]

Posted on October 17, 2005 at 15:18

Hallo,

thanks for the answers.

I did not expect that RxOk is not asserted because it can't than be used for checking the interrupt routines, at least not correctly.

For the extended identifier explanation now it is clear, but I think that if you asked a hundred people on what they think is written in datasheet I'm sure at least 90% would say that 16 LSB of id are in A1R and remaining 13 of MSB are in A2R register.

Anyways thanks.

[me_mickey_2006]

Posted on October 18, 2005 at 09:04

BTW, I think that in your second answer you mixed A1R and A2R, in A1R is 16 bits of ID, and in A2R is 13 bits.

[me_mickey_2006]

Posted on October 19, 2005 at 17:18

You are wrong on extended identifiers, it is like so 16 LSB of ID are in A1R and remaining 13 bits are in A2R.

[shangdawei1]

Posted on December 09, 2005 at 08:38

Std ID : ID[28:18]

Ext ID : ID[17:16] ID[15:0] ID[28:18]

MSB-------------------------LSB

or

Std ID : ID[28:18]

Ext ID : ID[28:18] ID[17:16] ID[15:0]

MSB-------------------------LSB

Which is true ?

[shangdawei1]

Posted on December 09, 2005 at 09:11

Quote:

On 19-10-2005 at 20:48, Anonymous wrote:

You are wrong on extended identifiers, it is like so 16 LSB of ID are in A1R and remaining 13 bits are in A2R.

I think, you are wrong.

when an extended Id is stocked, the 11 LSBs should be the ID[28:18] (which are the standard ID) (in A2R), the next higher bit are the ID[15:0] (in A1R) and the MSBs are ID[17:16] (in A2R).

Ext ID : ID[17:16] ID[15:0] ID[28:18]

---------MSB--------------------------LSB

is it true ?

[davidbellegarde9]

Posted on December 14, 2005 at 07:17

All apologies, my previous message was wrong and A2R should be reversed with A1R.

And I added this in order to be clearer.

The Id of a message depend of the point of view you take: physical CAN trame, arbitration registers and software buffer.

With the protocol CAN 2.0B (extended Id), the arbitration part of the trame is transmitted as follows:

STDID[10..0] EXTID[17..0]

MSB-----LSB MSB-------LSB

The CAN arbitration registers are:

A2R[12..2] for the STDID

MSB----LSB (ID[28..18] of A2R)

A2R[1..0] A1R[15..0] for the extended part

MSB---------------LSB (ID[17..16] of A2R and ID[15..0] of A1R)

The pCanMsg->Id software buffer:

bit[28..0]

EXT Id part, STD id part

MSB------------------LSB

Maybe the last one should be coded differently.

[edb]

Posted on July 31, 2006 at 21:43

I must disagree with your analysis of 29-bit CAN ID's.

I am working in a automotive environment where the ID values are pre-defined. I have to discover whether the car I am attached to is using 11 or 29 bit addresses by sending a packet with the defined ID and see whether I get a responce.

In both cases I have a table of 11 and 29 bit ID's in hex to use. My application does not care which bits of the 29 bit ID are the ''base ID'' bits and which are the ''extended ID'' bits. I want to be able to put the hex value from the specification (ISO 15765-4) into the Id field of the canmsg structure and have CAN_SendMessage send a packet with the correct ID.

As far as I am concerned the ''correct'' behavior is:

Code:

11 bit ID:

A2R [12:2] (ID [28:18]) <- canmsg.Id[10:0]

A2R [ 1:0] (ID [17:16]) <- 0

A1R [15:0] (ID [15: 0]) <- 0

29 Bit ID:

A2R [12:0] (ID [28:16]) <- canmsg.Id[28:16]

A1R [15:0] (ID [15: 0]) <- canmsg.Id[15:0]

This is also true for setting the mask and arbitration fields of RX messages.

My primary evidence is that I have a tool that reports activity on the CAN bus and it reports the ID value [28:0] without any of the shifting the library code is doing.

Implementing it this way should make the librarly code smaller because all you need are 2 masks and 1 bit shift to load or store a 29 bit ID.

For application where you need to explicitly deal with the base and extended ID values, you can add macros to the library to generate 29 bit ID's from the components.