K60 CAN Message Buffer Structure

[robertin75]

Hello:

Apparently the Flex-CAN module from the K60 micro does not follow CAN 2.0B Bosch specification unless I am wrong.

On page 1345 from the document "K60 Sub-Family Reference Manual" section 48.3.56 there is no indication of what the bits in the ID fields are.

According to the Bosch spec both the SRR and IDE bit fields are part of the CAN ID but this micro has them separated (or are they both included on the ID field? I don't know).

Also on page 151 from the document Freescale MQX TM I/O Drivers Users Guide, the FLEXCAN_Tx_message() function does not mention what is the bit breakdown from parameter uint_32 format.

Anyone knows where can I find more in-depth information about what is the bit breakdown from the ID field from the Message Buffer Structure?

Thanks,

Roberto

[egoodii]

While SRR, IDE (and RTR) are all part of the first 32 CAN bits following SOF (in extended mode), those are in addition to what are the 29 bits of ID.  Suffice it to say that the FlexCAN MB uint32 at offset 4 is, as shown in 48.3.56, perfectly parsable as a direct J1939 29-bit packed PGN&address(es).

ERGII

[egoodii]

That is, for instance, the ID word can be extracted in one place thus:

*id = (pFlexCANReg->MB[iMB].ID & FLEXCAN_MB_ID_EXT_MASK)

and later parsed into J1939 data thus:

typedef union{                        //Byte/DWord duality, big-endian
  struct{
     uint8_t lo;
     uint8_t mlo;
     uint8_t mhi;
     uint8_t hi;
  } u8;
  struct {
     uint16_t lo;
     uint16_t hi;
  }u16;
  uint32_t u32;
}uint32_8_t;

uint32_8_t  pgn,  tmp;

tmp.u32= id;

  /* get source address of frame and then chop it off.   reference SAE J1939/21 for more information */
  msg.src=tmp.u8.lo;
  tmp.u8.lo = tmp.u8.mlo; tmp.u8.mlo = tmp.u8.mhi; tmp.u8.mhi = tmp.u8.hi;

  pgn.u16.hi = tmp.u16.hi & 0x1;
  if( tmp.u8.mlo < 240 ) {                  /* if the protocol format is less than 240, it is destination specific */

    /* destination specific */
    msg_dst = tmp.u8.lo;
    pgn.u16.lo = tmp.u16.lo & 0xFF00;

  } else {

    /* ps field is a group extension */
    msg_dst = J1939_ADDR_GLOBAL;
    pgn.u16.lo = tmp.u16.lo;
  }

--ERGII

[robertin75]

Dear ERG:

I think you are confused.

I am talking about CAN Bosch frame format, not J1939.

If you take a look at the current CAN Bosch extended frame format specification the order of the fields is the following:

Bit 0 RTR

Bits 1-18  Extended format (ID0-ID17)

Bit 19 - IDE

Bit 20 SRR

Bits 21-31 Base format (ID18-28

But according to the K60 manual only the extended and base ID formats are in one 32 bits space (offsex 0x4) but the other bit fields (RTR, IDE and SRR are in another memory position.

So you cannot just use a single u32 variable to send the CAN frame to the FlexCAN module just like most of the other micros would do.

You have to do some math to be able to extract and put the missing bit fields where they belong (memory address offset 0x0).

Please take a look at page 39 from the the attached PDF document from an MC68HC12 MSCAN module micro.

That's the bit order arrangement that I would expect with every micro that complies with the CAN 2.0B Bosch specification.

You can easily send the 32 bits CAN frame using a single u32 variable.

Thoughts?

Thanks,

Roberto

[egoodii]

I used J1939 as an example of working with the packed 29 bits of ID00-28, as held in MailBox offset 4.  Of those 32 bits following SOF, as defined by BOSCH, those three bits called SRR, IDE & RTR are pulled from the sequence for you and placed at those named bits in MailBox offset 0.  To the extent one generally doesn't want to handle those 3 bits in the same logic one parses the 29 ID bits (and for must uses have fixed values), I find the separation quite a useful optimization.  Bosch defines the wire bit order, as forced 'non consecutive' by legacy; how the I/O module helps to link to that wire is certainly up to the chip implementers.  No matter how you look at it, one 32 bit quantity can't contain ALL the control bits you need for an extended CAN message.  Why do you WANT these 'ood bits' scrambled into these 'odd places' as forced by history?  All CAN stacks I've worked with want the contiguous 29-bit ID at the API layer.

--ERGII

[egoodii]

Just as another point of reference:  While Freescale MSCAN implemented the mentioned 'full wire-order 32 bit header' (on both S08 & S12 parts) message structure, Atmel AVR micros supply the contiguous 29 bits of ID (albeit MSB justified).  Just another indication that the firmware-side of CAN I/O modules is a potpourri.

--ERGII