CAN on ATSAMC21J18A

[ataradov]

so a lot of these numbers are still based on simulation rather than qualified measurements and so a lot of these Maximum frequency numbers for the various peripheral units look way too conservative.

It just seems they are conservative. When things are specified based on simulation, there is a great level of confidence that real characterization would not improve them by a lot.

And in this context I wonder why the same CAN-FD module supposedly can only do 48MHz in the ATSAMC21, 100MHz in the ATSAME51 and whatever the limit is for ATSAMx7x as it looks like this information is not given in the datasheet.

48 MHz is the maximum frequency for C21. 100 MHz is the typical maximum value for a lot of peripherals that don't need higher clock for D5x/E5x. Having lower value (less than 120 MHz) means that it is easier to meet timing requirements for routing. This is the same reason for introduction of I/O Sets. Too many pin multiplexing options make it very hard to meet timing requirements.

For V7x there are recommended frequencies: "It is recommended to use the CAN clock at frequencies of 20, 40 or 80 MHz." Those are easy to derive from standard PLLs and there is no need for CAN to have a higher clock for real applications.

[Rudolph Riedel]

It just seems they are conservative. When things are specified based on simulation, there is a great level of confidence that real characterization would not improve them by a lot.

Well, the C21 has only one PLL and the x5x only has two PLLs and the GCLK only allow even dividers.
So with the given values you are severly limited.
That would change a little if in the x51 SERCOM, CAN, TC4...TC7, AC, ADC and DAC at least had a maximum input frequency of 120MHz.
And if the CAN-FD in the C21 would allow 80MHz it would work with more than 2Mbit/s, the "10 Mb/s for CAN-FD mode" as stated in the datasheet are not possible with only 48MHz, at least not reliable.
8Mbit/s would be 6tq at 48MHz and 5tq at 40MHz, 10tq at 80MHz and 15tq at 120MHz.

This alone should be a valid reason to actually qualify what the controllers really can do.

And in this context I wonder why the same CAN-FD module supposedly can only do 48MHz in the ATSAMC21, 100MHz in the ATSAME51 and whatever the limit is for ATSAMx7x as it looks like this information is not given in the datasheet.

48 MHz is the maximum frequency for C21. 100 MHz is the typical maximum value for a lot of peripherals that don't need higher clock for D5x/E5x. Having lower value (less than 120 MHz) means that it is easier to meet timing requirements for routing. This is the same reason for introduction of I/O Sets. Too many pin multiplexing options make it very hard to meet timing requirements.

For V7x there are recommended frequencies: "It is recommended to use the CAN clock at frequencies of 20, 40 or 80 MHz." Those are easy to derive from standard PLLs and there is no need for CAN to have a higher clock for real applications.

Well, how do you get 40MHz clock for the CAN in a C21 and 48MHz for the core? You can't.
Likewise you need two PLLs to use 80MHz for the CAN in an E51 while running the core with 120MHz since the PLL and the GCLK can "only" do 200MHz and not 240MHz.

And then you have OEM requirements that CAN-FD controllers must use a clock with multiples of 40MHz.

So you either violate that requirement for the C21 or clock the core at 40MHz as well.
And for E51 you practically have to use both PLLs to run the CAN-FD at 80MHz and the core at 120MHz which means that every other peripheral is locked into that base frequencies as well. Running either the CAN-FD at 120MHz or the core at 80MHz or 160MHz would free the second PLL.
Do I need to use 80MHz or 120MHz for the CAN-FD? Yes, 40MHz only works up to 2Mbit/s.

[ataradov]

Well, how do you get 40MHz clock for the CAN in a C21 and 48MHz for the core? You can't.

Use PLL for 40 MHz and RC oscillator for the rest of the system. 48 MHz RC oscillator is plenty accurate to run the code, and you can derive the clock for other peripherals from the same PLL.

Likewise you need two PLLs to use 80MHz for the CAN in an E51 while running the core with 120MHz since the PLL and the GCLK can "only" do 200MHz and not 240MHz.

That's why you have 2 PLLs.

That 100 vs 120 MHz will not characterize. I've seen those devices fail when overclocked like this. So there is not a whole lot of margin there.

[matti.salo]

Again i jumped to a weird thing. I have been able to configure the CAN controller to work with 500kbit/s and i can successfully read it wit PCan cable and also with picoscope oscilloscope. I have MCP2551tranciever. But.... when i'm connecting it to my other board that has sam3x8e/SN65HVD230 it cannot get the data. after disconnecting/connecting the can cable several times ( 5-30) times it just some time starts to work.  With oscilloscope i have checked that one bit is just the 2uS long as it should be with the 500kbps speed if i have understood right. Any idea what is going wrong? what to look in next step? canbus resistors have been tried few different sizes.

the other 3x8e board we have been using to read can data from other 500kbps devices so there should not be a problems.

[ataradov]

You need to be more specific. A common thing to forget is ground connection, for example. You may have incorrectly configured the sampling points, for example. What is your configuration? Have you tried to change it?

Connecting/disconnecting the cables does nothing without actual data transfer. So, do you actively transfer frames while doing this?

To verify the baudrate setting, it is much better to transmit the data from the device.

Attach scope traces of what you see on the bus.

[matti.salo]

The devices are sharing a common ground since they are powered from same power supply, so that should not be a problem.

at sending device samc21g18 i have following sampling configuration with 16MHz clock:

Code: [Select]

CONF_CAN0_BTP_BRP 2
CONF_CAN0_BTP_TSEG1 13
CONF_CAN0_BTP_TSEG2 2
CONF_CAN0_BTP_SJW 2
CONF_CAN0_DBTP_TDC 0
CONF_CAN0_DBTP_DBRP 2
CONF_CAN0_DBTP_DTSEG1 10
CONF_CAN0_DBTP_DTSEG2 3
CONF_CAN0_DBTP_DSJW 3

At the sam3x8e i have used asf3 and command to initialize canbus:

Code: [Select]

can_init(CAN0, ul_sysclk, CAN_BPS_500K);
The code at the sending c21 has a 40ms timer that acively sends a can packet and that i can verify with scope:


I have tried to change a bit timing settings but i cannot make a difference. but i have to admit that i'm not a pro to calculate them

[eutectique]

1. If the bit time is indeed 1.92 μs, then your baud rate is about 521 kbps, or 4.17% off. This is way too much.

2. The offset of ACK bit and floating level of EOF looks suspicious.

3. Some time ago I evaluated CAN on SAMC21 xplained board and, afair, it worked OK. The other side was TI's TCAN4550. Cable length was about 30 cm with 120 ohm termination on TCAN.

I don't have the SAMC21 board handy, but here is my configuration of CAN0:

Code: [Select]

#define CONF_CAN0_CCCR_FDOE 1
#define CONF_CAN0_CCCR_BRSE 1
#define CONF_CAN0_MRCFG_RUNSTANDBY 0
#define CONF_CAN0_MRCFG_DQOS 2
#define CONF_CAN0_BTP_BRP 1
#define CONF_CAN0_BTP_TSEG1 71
#define CONF_CAN0_BTP_TSEG2 24
#define CONF_CAN0_BTP_SJW 20
#define CONF_CAN0_DBTP_TDC 0
#define CONF_CAN0_DBTP_DBRP 1
#define CONF_CAN0_DBTP_DTSEG1 17
#define CONF_CAN0_DBTP_DTSEG2 6
#define CONF_CAN0_DBTP_DSJW 3


[ataradov]

The settings look fine, but the baudrate indeed looks off. Zoom in on a bit and measure it carefully. Don't just assume the number because it is close enough.

What is the source of the 16 MHz clock?

[matti.salo]

Mckl is running at 48MHz and i have gclk with divider 3 providing the 16MHz clock source for CAN. As far as i have understood that the internal 48MHz should be accurate enough? I also have 32khz external crystal, but i don't know if i need it anywhere.

I checked the clock configuration and also the other board. Now the  can communication started to work, but i'm unsure in the end what i had wrong.

[ataradov]

Internal 48 MHz is a simple RC oscillator that is not accurate enough for this.

You need to use DPLL with 32 kHz oscillator as a reference.

[matti.salo]

Thanks for the advice. These clock configs are quite new to me. I've now configured the FDPLL and it shows me 47.999MHz. Should i use that clock as source for everything and just disable the internal oscillator OSC48M? What would be the best practice for this?

[ataradov]

You don't need to disable the internal one unless you have a very tight power budget. But do use DPLL for everything, especially stuff that needs stability over time and temperature.

[Rasmo]

Here is a simple bare-metal CAN bootloader that shows basic use of that peripheral.

Hi ataradov,

I am trying to implement a CAN bootloader and came across your code example. I was wondering if you have any details on the protocol / format of the messages being sent to the C21, or even better an example programming application! I think I have worked out most of it although there were still a few little things that I was a little unsure of.

What are these lines checking in the bootloader request check? Is this something written to memory prior to a software reset to launch the bootloader?

Code: [Select]

if (BL_REQUEST == ram[0] && BL_REQUEST == ram[1] &&
      BL_REQUEST == ram[2] && BL_REQUEST == ram[3])
  {
    ram[0] = 0;
    return true;
  }

Thanks again for your example.

[ataradov]

I was wondering if you have any details on the protocol / format of the messages being sent to the C21

The document is attached.

What are these lines checking in the bootloader request check?

This is a software bootloader request. Application may put those values into the first 4 locations in SRAM and reset the MCU. Bootloader would check them and stay in the bootloader mode. This is also described in the document.

[Rasmo]

I was wondering if you have any details on the protocol / format of the messages being sent to the C21

The document is attached.

What are these lines checking in the bootloader request check?

This is a software bootloader request. Application may put those values into the first 4 locations in SRAM and reset the MCU. Bootloader would check them and stay in the bootloader mode. This is also described in the document.

Thank you, that is exactly the kind of thing I was looking for!

[Rasmo]

One more quick question. In sys_init() I can't see bits NVMCTRL or DSU in the APBCMASK register.

Code: [Select]

MCLK->APBCMASK.reg |= MCLK_AHBMASK_NVMCTRL | MCLK_AHBMASK_DSU;
If I understand correctly this is actually enabling SERCOM4 & SERCOM2, is this intended or was it supposed to be AHBMASK instead of APBCMASK? It looks like the NVMCTRL & DSU bits in AHBMASK are default to set on reset anyway though so it probably isn't needed?

[ataradov]

This is a mistake. I fixed it later, but the published code has it. It needs to be MCLK->AHBMASK.reg = ... and the same in the sys_deinit()

AHBMASK actually has those things enabled by default, so it does not really matter. It was put there for clarity and because I had a lot of size to spare for a 2K bootloader.

[Rasmo]

Thanks ataradov,

Is the project that you uploaded tested? I have put this onto a board and I haven't had any luck getting it to work. I have moved the can_init() and added a send_response() method to try and send a message prior to running the application to test (see code below). However I don't get any activity on the CAN bus. I have started running through the code but I can't seem to get debug working with it properly to breakpoint. I can see that the registers are being set but I think the code is being optimised in a way that I can't breakpoint. I know the hardware I am using is good as I can put my original program on and that has CAN comms fine.

Thanks again.

Code: [Select]

int main(void)
{
  sys_init();

  can_init();
  send_response(BL_RESP_INVALID);

  if (!bl_request())
    run_application();

  while (1)
  {
    can_task();
  }

  return 0;
}


[ataradov]

Of course it was tested, I did not just type it out of the blue.

Breakpoints will not work properly because the project loads itself into the SRAM to enable bootloader update, and Cortex-M0+ does not support breakpoints in SRAM.

I think all you need to do to make it run from flash is move this section

Code: [Select]

    *(.ram_vectors)
    *(.text*)
    *(.rodata)
    *(.rodata.*)
from .data to .text in the linker script.

There are two CAN controllers on this device., Are you sure you are using correct pins?

[Rasmo]

Breakpoints will not work properly because the project loads itself into the SRAM to enable bootloader update, and Cortex-M0+ does not support breakpoints in SRAM.

Ahh right, that would explain why.

There are two CAN controllers on this device., Are you sure you are using correct pins?

Yes, I am using PA25 / PA24, which it looks like is the same as your project.

I have just tried it on my Xplained board and it does work as expected. This however has a C21J18A, whereas the original board has a C21J15A. Is there something I need to change beyond selecting the different device?

I do also have a 16MHz crystal on the original board that I am using with the original program that works but that shouldn't effect the internal clock should it? I will continue to see if I can work out what is different.

[ataradov]

Yes, you need to edit the SRAM size in the linker script. The stack is placed at the end of SRAM and right now it is in the non-existent memory.

Although I just looked and it is already set for 4K of SRAM, so it should be fine.

Are you checking that there is no communication with a scope or with another device? It is possible there is some baudrate mismatch, so I'd use a scope or a logic analyzer.

My code uses internal 48 MHz RC oscillator. This is not ideal for interoperability, but should be good enough to see something being sent.

And about selecting a different device - Atmel Studio used to add its own linker script and startup files when you do that. Check that this did not happen. I usually change the device by editing the project file in a text editor, this way AS trying to be smart does not get in a way.

[Rasmo]

I have figured it out. It was my bad so sorry for mucking you around a bit. I have the STBY pin of the CAN transceiver connected to PA19, which I had forgotten about, and then it is also the same as what you were using for the bootloader detect as luck would have it, which meant it wasn't doing what I thought also! All running now though thank you. Now I will just work on sorting the PC side of the transmission.

In terms of setting up an existing project for use with a bootloader, do you have any recommendations for documentation on the best / common practices? There seems to be a lot out there and before I start sifting through it all I thought I would see if you had some pointers on where to look. I think I will need to add the .text memory location in the linker memory settings with ".text=0x800", is this all? It would also be nice if there was a way to link the bootloader into the application project so it can all be downloaded at once. The same with debugging the application, can I still do that with the bootloader present or do I need to have a different configuration for that?

[ataradov]

All you need to do to make existing project work with a bootloader is correct the offset int the linker script. Normally your linker script will begin something like this:

Code: [Select]

MEMORY
{
  flash (rx) : ORIGIN = 0x00000000, LENGTH = 16K
  ram  (rwx) : ORIGIN = 0x20000000, LENGTH = 4K
}
Change it to:

Code: [Select]

MEMORY
{
  flash (rx) : ORIGIN = 0x00000800, LENGTH = 14K
  ram  (rwx) : ORIGIN = 0x20000000, LENGTH = 4K
}

I would strongly advice against trying to add the code from the bootloader to the main project. But it is fine to just include a pre-built binary file. You can do it though the linker as well.

For debugging you generally want to have a separate build where application is linked at the beginning. I sometimes include a "dummy" bootloader right in the project. This dummy bootloader would just jump to the application. This way application is linked at the same address, but when you prepare the final image, you need to replace the first 2K instead of just merging two images.

Generally it does not matter which way you go, it is all about the same.

[Rasmo]

I think I am just using the default linker scripts in Atmel Studio, do you know where these are kept? I can't find any ld files in the project directory. I assume it is the file called -Tsamc21j15a_flash.ld?

[ataradov]

It all depends on how the project was created. I guess it uses the file form a device pack if you can't find it in the project. This is pretty horrible, since your project is not self sufficient.

Yes, the file should be named samc21j15a_flash.ld.

There is also a way to specify the offset of the .text section without changing the linker script, but I personally would copy that linker script to the project and modify it. The linker script is as much part of the source code as any other C files.