SAMC MCAN CANbus controller message RAM management

[Simon]

I'm starting to write code for the CAN bus controller on the SAMC, this is a bosch MCAN controller used under licence.

I have one message from slot 0 transmitting but other slots are a challenge. I have tried to check that my memory address math is correct and that I am pointing to the right location in RAM memory. I have noticed that the debugger mentions other variables or even functions when I look at the location.

Is it that if I simply point to the address in the code without claiming this space as a variable that the RAM my get used by something else as the compiler is unaware of the dual use?

Am I safer creating say a structure for each buffer to be mapped to in RAM in a similar way to how the registers are mapped in the chip header files so that it's clear that this space is off limits to other stuff?

[ataradov]

Is it that if I simply point to the address in the code without claiming this space as a variable that the RAM my get used by something else as the compiler is unaware of the dual use?

Yes, of course. How would compiler know?

Am I safer creating say a structure for each

This is the only correct way of doing it. Apart of reserving the memory in a linker script. But that's just extra work for no benefit.

[Simon]

I see, well this is the first time I work with something where I am using raw RAM like  registers.

[Rudolph Riedel]

Here, this is what I am using for a while now:

Code: [Select]

#define CAN0_TX_BUFFER_NUM 4
#define CAN0_RX_FIFO_NUM 32
#define CAN0_ELEMENT_DATA_SIZE 64
#define CAN0_STANDARD_ID_FILTER_NUM 4
#define CAN0_EXTENDED_ID_FILTER_NUM 4

struct can_tx_element
{
    volatile CAN_TXBE_0_Type T0;
    volatile CAN_TXBE_1_Type T1;
    uint8_t data[CAN0_ELEMENT_DATA_SIZE];
} __attribute__((__aligned__(4)));

struct can_rx_element
{
    volatile CAN_RXBE_0_Type R0;
    volatile CAN_RXBE_1_Type R1;
    uint8_t data[CAN0_ELEMENT_DATA_SIZE];
} __attribute__((__aligned__(4)));

struct can_rx_fifo_element
{
    volatile CAN_RXF0E_0_Type R0;
    volatile CAN_RXF0E_1_Type R1;
    uint8_t data[CAN0_ELEMENT_DATA_SIZE];
} __attribute__((__aligned__(4)));

struct can_standard_message_filter_element
{
    CAN_SIDFE_0_Type S0;
} __attribute__((__aligned__(4)));

struct can_extended_message_filter_element
{
    CAN_XIDFE_0_Type F0;
    CAN_XIDFE_1_Type F1;
} __attribute__((__aligned__(4)));

static struct can_tx_element can0_tx_buffer[CAN0_TX_BUFFER_NUM];
static struct can_standard_message_filter_element can0_standard_id_filter[CAN0_STANDARD_ID_FILTER_NUM];
static struct can_rx_fifo_element can0_rx_fifo[CAN0_RX_FIFO_NUM];
static struct can_extended_message_filter_element can0_extended_id_filter[CAN0_EXTENDED_ID_FILTER_NUM];

And then I have this in my setup function:

Code: [Select]

    if (can_channel == CAN0)
    {
        /* TX Buffer Configuration */
        can_channel->TXBC.reg = CAN_TXBC_TBSA((uint32_t) can0_tx_buffer) | CAN_TXBC_NDTB(CAN0_TX_BUFFER_NUM);

        /* RX FIFO Configuration */
        can_channel->RXF0C.reg = CAN_RXF0C_F0SA((uint32_t) can0_rx_fifo) | CAN_RXF0C_F0S(CAN0_RX_FIFO_NUM) | CAN_RXF0C_F0OM; // FIFO 0 overwrite mode

        /* ID filter buffer configuration */
        can_channel->SIDFC.reg = CAN_SIDFC_FLSSA((uint32_t) can0_standard_id_filter) | CAN_SIDFC_LSS(CAN0_STANDARD_ID_FILTER_NUM);

        /* ID filter buffer configuration */
        can_channel->XIDFC.reg = CAN_XIDFC_FLESA((uint32_t) can0_extended_id_filter) | CAN_XIDFC_LSE(CAN0_EXTENDED_ID_FILTER_NUM);
    }


[Simon]

Thank you. I'll take a look, I tried something similar but ended up with blank messages so I have probably made a mess of the pointers.

one thing I have found is that one a transmission is triggered is just keeps going. I start it with the bit in the TXBAR register.

[Siwastaja]

I have attached a spreadsheet I made some years ago, I hope it's helpful. Just modify numbers in yellow highlighted cells. It even "generates" code you can copypaste. This reduces the risk of mistakes when calculating addresses into message ram.

This was for STM32H7 but I guess the MCAN is exactly the same on SAMC? Maybe worth checking if the total amount of memory is the same.

[Rudolph Riedel]

This was for STM32H7 but I guess the MCAN is exactly the same on SAMC?

No, the SAMC21 is using the main memory while the STM32H7 have a dedicated 10kiB SRAM that two units have to share.

Maybe worth checking if the total amount of memory is the same.

The ATSAMC21 come in variants with 4/8/16/32 kiB of SRAM, whatever the reason for the first two variants to even exist is as there also is the ATSAMC20 without CAN.

[Simon]

Well the mcan peripheral seems to be used in many devices, I guess the RAM settings will be the same.

[ataradov]

RAM layout and requirements are the same. The only difference is where the address registers point.

[Simon]

Here, this is what I am using for a while now:

Code: [Select]

#define CAN0_TX_BUFFER_NUM 4
#define CAN0_RX_FIFO_NUM 32
#define CAN0_ELEMENT_DATA_SIZE 64
#define CAN0_STANDARD_ID_FILTER_NUM 4
#define CAN0_EXTENDED_ID_FILTER_NUM 4

struct can_tx_element
{
    volatile CAN_TXBE_0_Type T0;
    volatile CAN_TXBE_1_Type T1;
    uint8_t data[CAN0_ELEMENT_DATA_SIZE];
} __attribute__((__aligned__(4)));

struct can_rx_element
{
    volatile CAN_RXBE_0_Type R0;
    volatile CAN_RXBE_1_Type R1;
    uint8_t data[CAN0_ELEMENT_DATA_SIZE];
} __attribute__((__aligned__(4)));

struct can_rx_fifo_element
{
    volatile CAN_RXF0E_0_Type R0;
    volatile CAN_RXF0E_1_Type R1;
    uint8_t data[CAN0_ELEMENT_DATA_SIZE];
} __attribute__((__aligned__(4)));

struct can_standard_message_filter_element
{
    CAN_SIDFE_0_Type S0;
} __attribute__((__aligned__(4)));

struct can_extended_message_filter_element
{
    CAN_XIDFE_0_Type F0;
    CAN_XIDFE_1_Type F1;
} __attribute__((__aligned__(4)));

static struct can_tx_element can0_tx_buffer[CAN0_TX_BUFFER_NUM];
static struct can_standard_message_filter_element can0_standard_id_filter[CAN0_STANDARD_ID_FILTER_NUM];
static struct can_rx_fifo_element can0_rx_fifo[CAN0_RX_FIFO_NUM];
static struct can_extended_message_filter_element can0_extended_id_filter[CAN0_EXTENDED_ID_FILTER_NUM];

And then I have this in my setup function:

Code: [Select]

    if (can_channel == CAN0)
    {
        /* TX Buffer Configuration */
        can_channel->TXBC.reg = CAN_TXBC_TBSA((uint32_t) can0_tx_buffer) | CAN_TXBC_NDTB(CAN0_TX_BUFFER_NUM);

        /* RX FIFO Configuration */
        can_channel->RXF0C.reg = CAN_RXF0C_F0SA((uint32_t) can0_rx_fifo) | CAN_RXF0C_F0S(CAN0_RX_FIFO_NUM) | CAN_RXF0C_F0OM; // FIFO 0 overwrite mode

        /* ID filter buffer configuration */
        can_channel->SIDFC.reg = CAN_SIDFC_FLSSA((uint32_t) can0_standard_id_filter) | CAN_SIDFC_LSS(CAN0_STANDARD_ID_FILTER_NUM);

        /* ID filter buffer configuration */
        can_channel->XIDFC.reg = CAN_XIDFC_FLESA((uint32_t) can0_extended_id_filter) | CAN_XIDFC_LSE(CAN0_EXTENDED_ID_FILTER_NUM);
    }


So I am starting to look at writing my code, thank you for sharing this. I am confused with how you fill the registers. You are passing the address of the structure directly to the register? My understanding is that these registers want to know the address of the variables (structures) relative to the start of the RAM address, which I guess is kind of why only 16 bits of register are provided as the RAM does not cover the full 32 bit memory space.

Thinking about it a bit more, as the RAM starts at 0x00000000 in it's own "space" and never exceeding 32kB or 15 bits, allowing the first 16 bits to be truncated leaves the RAM start relative address from the actual address which takes out the human error.

So how is it guaranteed that the structures are all put within the limit of the 4352 consecutive words that the controller can address other than logically being declared one after each other they will be allocated one after the other. 4352 words is more than my 16kB RAM anyway.

[ataradov]

Elements in the array are guaranteed to be consecutive and you providing the pointers to the arrays. The arrays themselves can be located in any way, they  don't need to be consecutive.

CAN itself can use any addresses within 64 KB block. For devices with higher memory size or where SRAM does not start at 0, there is an additional register that specifies the higher 16 bits of the address. All arrays still must be located within any 64 KB block in the SRAM.

[Simon]

No it's any ~17kB block / 4352 words

[ataradov]

What is " any ~17kB block / 4352 words"?

[Simon]

https://www.bosch-semiconductors.com/media/ip_modules/pdf_2/m_can/mcan_users_manual_v331.pdf page 46 section 2.4

[ataradov]

So? It does not have to be continuous.  This is just an illustration. You specify the start of each section via TBSA, F0SA, FLESA and others. All those sections can be located in any random order. And they don't need to be maximum allowed size either, since you specify the number of elements in each array. If you don't have any extended filters, you don't have to reserve the RAM for them, just specify 0 elements.

All offsets are 16-bit in size, so all the buffers must be located in the same 64 KB section. If device has less than 64 KB, then this is automatically met. If device has more than 64 KB, then it depends on the way CAN IP was integrated. For example, SAM V7x have CCFG_CANx registers that contain 16 MSB of the address. And SAM E5x does not do anything, so CAN buffers must be manually placed in the low 64 KB of SRAM.

[Siwastaja]

Just use the spreadsheet I posted earlier, or make something similar on your own. Offsets can be calculated in 5 minutes on a napkin, but spreadsheet is handy as it can be iteratively modified.

[ataradov]

Why not just let compiler to calculate all that for you?

[Simon]

I see, well that's one thing less to worry about.

[Simon]

Well I do have CAN transmissions working now, took me a while to get around to testing my code between things.

As to the addressing I found a document on the Bosch website that stated that the memory should be continuous but not essential.

What worries me with doing it the "easy" way of letting the compiler handle where stuff is is that if I say move to the PIC32CXSG series these have up to 256kB or RAM so if the compiler were to place the variables beyond the first 64kB there would be a problem.

I guess that I'd have to create a single structure that is pinned to an address so that the same letting the compiler work out the addresses works.

[ataradov]

Yes, on parts with more than 64KB you would need to place those structures into a separate memory section and link those first.

SAM V7x have a separate register that configures upper half of the address, but I guess this was dropped because it is just extra hardware for something that is trivial to solve in the software.

[Simon]

so can I do somethiung like:

struct canvars
{
    fiforx
    fifotx
    filters
}

all of these are arrays of other structs

memory address of fiforx= (uint32_t) can0variables.fiforx

ie, can the address of an array that is part way down a struct be assigned like this with the casting to extract the address?

[ataradov]

Yes, sure. In-memory layout would  be the same as if they were all separate variables.

[Simon]

So I'm working on the message reception handling. The FIFO has a get index, so that is where the last unread data is at, how is this incremented? does the controller detect the data read from that location and increment it.

I don't think I am supposed to do anything but I have not found any explanation as to how it behaves.

[ataradov]

After you are done with the data, you write the index back into  MCAN_RXF0A or MCAN_RXF1A and it automatically frees the FIFO entry.

Note that you don't have to acknowledge each message if you are processing more than one. Just write the last index and it will discard all of the handled messages.

It is described in the section "FIFO Acknowledge Handling".

[Simon]

Ah right, thanks. Will give that a wirl tomorrow.