CAN frame structure in STM32

[Bs.1]

Hi,

I am trying to implement CAN bus using STM32F072RB

using normal mode.

I have found successfully transmission & reception from both the nodes.

I am having one doubt regarding the frame formation.

CAN is having the format as

SOF|11 bit identifier|SRR|IDE|18 bit identifier|RTR|R1|R0|DLC|8 byte data|CRC|ACK|EOF|IFS

But in stm32 I found only some of the fields in structure

i.e. ID | IDE | RTR | DLC | Timestamp | FilterMatchIndex

typedef struct

{

 uint32_t StdId;  /*!< Specifies the standard identifier.

             This parameter must be a number between Min_Data = 0 and Max_Data = 0x7FF. */

 uint32_t ExtId;  /*!< Specifies the extended identifier.

             This parameter must be a number between Min_Data = 0 and Max_Data = 0x1FFFFFFF. */

 uint32_t IDE;   /*!< Specifies the type of identifier for the message that will be transmitted.

             This parameter can be a value of @ref CAN_identifier_type */

 uint32_t RTR;   /*!< Specifies the type of frame for the message that will be transmitted.

             This parameter can be a value of @ref CAN_remote_transmission_request */

 uint32_t DLC;   /*!< Specifies the length of the frame that will be transmitted.

             This parameter must be a number between Min_Data = 0 and Max_Data = 8. */

 uint32_t Timestamp; /*!< Specifies the timestamp counter value captured on start of frame reception.

             @note: Time Triggered Communication Mode must be enabled.

             This parameter must be a number between Min_Data = 0 and Max_Data = 0xFFFF. */

 uint32_t FilterMatchIndex; /*!< Specifies the index of matching acceptance filter element.

             This parameter must be a number between Min_Data = 0 and Max_Data = 0xFF. */

} CAN_RxHeaderTypeDef;

How the CRC, ACK, R1, R0 etc. all other fields formation is done??

[Oliver Sedlacek]

The other CAN fields are generated in hardware by the CAN peripheral. These fields are hidden from the processor because it can't do anything with them.

[Tesla DeLorean]

Stuff handled in HW logic as it can operate efficiently at line speeds. ​Ensures signals/packets are standards compliant without a lot of micro management from user space.

[Bs.1]

Ok.

But in case if there is any crc or bit error occures, then how to handle it?

[Bs.1]

Thanks for the valuable guidance.

[Ozone]

> CAN is having the format as

> SOF|11 bit identifier|SRR|IDE|18 bit identifier|RTR|R1|R0|DLC|8 byte data|CRC|ACK|EOF|IFS

You are messing something up here.

A CAN frame can have either an 11-bit identifier or alternatively a 29-bit identifier, but not both at the same time.

The ID mode is given in the control field.

I didn't work with STM32 CAN yet, but there is surely a CAN peripheral control register setting reflecting this, and appropriate HAL code.

Set the peripheral unit up correctly, and everything else is handled by the autonomous CAN controller unit (the peripheral block, usual a Bosch IP).

You only have to deal with the status registers/flags and the receive/transmit data.

[Tesla DeLorean]

Aren't these flagged by the controller? Errors/Status are handled at a higher level.

ST has used the bxCAN IP in many of its STM32 implementations, it manages a lot of the gritty detail of the bus level transaction, allowing you to concentrate on the packet content, and less on the bus level integrity, acknowledge and retry aspects.

I don't think it provides for a promiscuous mode where you can snoop everything, or push test/error patterns onto the wire. If you want to build an analyzer/tester there are probably better parts to do that.

[Bs.1]

Yes...I have checked with the same...as you said....ST provides the error status....

I am asking just for my knowledge.....