What Frame configuration bits are included in the CO_IF_FRM.Identifier variable?

[sudoDavi]

Is your question related to a problem? Please describe.
I'm writing a driver for the STM32F207 and I need to know how the CO_IF_FRM received in DrvCanSend is formated so I can setup the Hardware specific header in the correct way. What does frm->Identifier contain?

I couldn't find this info in the documentation and source files how it sets up this configurations bits, and from reading the CiA 301 spec there are instances where a RTR is sent or that a network can use Extended CAN Frames.

Below I have some code I've written for another CANopen stack where the configurations bits are sent on the identifier of the frame so you need to mask them to check.

Example of configuration of a CAN Frame header, specific to STM32F207

static int16_t DrvCanSend(CO_IF_FRM *frm)
{
    uint8_t success = 0;
    static CAN_TxHeaderTypeDef tx_header;
    tx_header.StdId = frm->ident & CAN_ID_MASK;
    tx_header.ExtId = 0x01; // This won't be used if using a standard ID frame
    tx_header.RTR = (frm->ident & FLAG_RTR) ? CAN_RTR_REMOTE : CAN_RTR_DATA; // This configures the type of frame RTR or Data frame
    tx_header.IDE = CAN_ID_STD; // This configures the frame to either be a standard or extended ID frame
    tx_header.DLC = frm->DLC;
    tx_header.TransmitGlobalTime = DISABLE;
    success = HAL_CAN_AddTxMessage(CANmodule->CANptr, &tx_header, buffer->data, &TxMailbox);
    
    // Example of transmission handling for CANopen-stack
    if(success == HAL_OK)
    {
	    // Successful transmission
	    return sizeof(CO_IF_FRM);
    }
    else if(success == HAL_ERROR)
    {
	    // An error occurred and it isn't related to the tx mailboxes being full
	    return (int16_t)-1;
    }
}

[michael-hillmann]

As remote transfers and extended CAN Ids are not implemented, we can take your suggestion.
Currently the stack is working with standard CAN identifiers only.

[dozack]

CO_IF_FRM Identifier

Currently CO_IF_FRM Identifier contains only CAN-ID information. Detection of extended ids is supported if user configures it so (SYNC, SDO, even PDO, see [CiA 301]) and imho straightforward:

static int16_t STM32FdcanCanSend(CO_IF_FRM *frame) {
    FDCAN_TxHeaderTypeDef txHeader;
    static uint8_t frameMarker;

    /*
     * Translate canopen-stack frame type to HAL header
     */

    txHeader.Identifier                     = (uint32_t) frame->Identifier;
    txHeader.IdType                         = (frame->Identifier > 0x7ff) ? (FDCAN_EXTENDED_ID) : (FDCAN_STANDARD_ID);
    txHeader.TxFrameType                    = FDCAN_DATA_FRAME;
    txHeader.DataLength                     = (frame->DLC << 16);
    txHeader.ErrorStateIndicator            = 0;
    txHeader.BitRateSwitch                  = 0;
    txHeader.FDFormat                       = FDCAN_CLASSIC_CAN;
    txHeader.TxEventFifoControl             = FDCAN_NO_TX_EVENTS;
    txHeader.MessageMarker                  = (uint32_t) frameMarker++;

    if (HAL_FDCAN_AddMessageToTxFifoQ(&CoFdcan, &txHeader, &frame->Data[0]) != HAL_OK) {
        /* 👍 for @sudoDavi, there i should distinguish between interface busy and error results :) */
        return (0u);
    }

    return sizeof(CO_IF_FRM);
}

RTR frames

In case of RTR frames, i would suggest against supporting this feature with reference to CiA AN802. Most of hardware products nowadays utilize version of CANOpen that supports functionality beyond requiring RTR frame transmission.