systick timer on SAMC

[Simon]

There is some tricky stuff you need to take care of when the systick wraps.  There are some drivers in the zephyr project repo that might be helpful reference

Well, that's the most complex systick code I've ever seen.  And it wasn't helpful at all, because It doesn't explain why it's doing things the way it IS.

I *think* their idea is to run sysTick with varying counts, so as to enable sleeping between "ticks" or something.  That's not the USUAL way to use sysTick.  (although to be fair, having the system wake up every millisecond or so just to increment a tick counter is probably not a great way to achieve low-power devices.)

NOTHING anyone links to as the answer ever works. All code I look at just seems over complicated and reading it won't help explain something as it was written from the perspective of someone very knowledgeable in the hardware and coding. I'm not that experienced in coding and I just find myself tied in knots to the point it is easier to understand the hardware and write my own code. I don't know if this is my inexperience or if people just like to show off their skill unneccessarily. I have not read code yet that does not contain so much stuff that references other files that it's just impossible to peice it together. I need to learn this persons system before I can use the code to learn how something works.

[sslupsky]

Looks like Zephyr has added support for SAMC20 and SAMC21 if that is any help to you.  Here is the commit that did that:

soc: atmel: add base support for C2x SOC
Adds Atmel SAMC20 and SAMC21 soc. C series is based on Cortex-M0+.
C21 contains CAN interface.

The init routines are same for SAMC20 and SAMC21. They use one
clock OSC48M without configuration.

The code is inspirated from atmel_sam0/samd21.

You would have a learning curve to come up to speed on using Zephyr.  The wealth of drivers available in Zephyr might be worth it for you.  Zephyr also has stacks for networking, wireless, file systems and more. Zephyr's device driver model uses devicetree which is similar to Linux.

[Simon]

Zephyr is not what I need. They don't support IC's but "boards", err yuk, what is this crap? the list of supported hardware is very short and clearly it will not support the hardware fully. I really wish the world of "look what we can do in 5 seconds" would just go and jump off a damn cliff. So it supports the C21N development board, not sure what that means. So does that mean that I am forced to use this variant? C21E/G/J are all the same but for different pin counts, C21N is really not the same chip, it has extra's on some peripherals the other 3 don't and is much more expensive, but then if you are too cheap to invest time I guess you can throw away money while hoping you can buy the parts. The Atmel development boards are the most horrible crap to work with I have ever come across. So bad I just made my own!

the systick is a couple of lines of code, seriously I have written more text setting up my own definitions for the registers as they are not defined by Atmel than I have written to run the thing.

[Rudolph Riedel]

Follow the link in my post which is the first answer.

And to extract the relevant parts related to systick:

Code: [Select]

#include "sam.h"

volatile uint8_t system_tick = 0;

void SysTick_Handler(void)
{
system_tick = 42;
}

void init_clock(void)
{
...
}

int main(void)
{
uint8_t led_delay = 0;

init_clock();
SysTick_Config(48000000 / 200); // configure and Enable Systick for 5 ms ticks

while (1)
{
if(system_tick)
{
system_tick = 0;

led_delay++;
if(led_delay > 39)
{
led_delay = 0;
PORT->Group[0].OUTTGL.reg = PORT_PA27;
}
}
}
}

This is ATSAMC21 code for microchip studio, SysTick_Handler is declared with the attribute weak in the supplied startup_samc21.c.
And SysTick_Config() is from the CMSIS package which is referenced when including "sam.h".

This is doing what SysTick is supposed to do, provide a timebase for the scheduler.
And I chose to use the SysTick_Handler to set a flag and nothing else.
It works and there really is not anything else in regards to SysTick.

Why SysTick_Config(48000000 / 200) for 5ms ticks?
The parameter is the amount of ticks to the next interrupt.
And the timer runs with the SystemCoreClock.
48000000Hz * 0.005s == 48000000 / (1 / 0.005) == 48000000 / 200 -> 240000

What I left out is putting the controller to sleep at the end of the while(1) and use SysTick_Handler() to wake it up.
It really does not make any difference for my application since that example is for using a 5" TFT.

[ataradov]

If you are only using systick to set a flag, then you might as well disable the interrupt and read CSR.COUNTFLAG to get the same result. Saves context saver/restore and a variable.

[Rudolph Riedel]

If you are only using systick to set a flag, then you might as well disable the interrupt and read CSR.COUNTFLAG to get the same result. Saves context saver/restore and a variable.

I just tried that on an ATSAME51 and it saved a whopping 16 bytes of programm memory and zero bytes SRAM.

Code: [Select]

...
SysTick_Config(120000000 / 200); /* configure and enable Systick for 5ms ticks */
SysTick->CTRL  = SysTick_CTRL_CLKSOURCE_Msk | SysTick_CTRL_ENABLE_Msk; /* disable systick interrupt */
...
    while (1)
    {
        if(SysTick->CTRL & SysTick_CTRL_COUNTFLAG_Msk)
// if(system_tick)
{
// system_tick = 0;

I rather stick to more generic code that would also allow putting the controller to sleep.

[ataradov]

It also saves at least 24 clock cycles for each interrupt call.

And whether SysTick even runs in sleep modes depends on the system implementation. But with CLKSOURCE=1, it will be running on the processor clock, which would be disabled except in the most shallow sleep modes.

[Rudolph Riedel]

Well, 24 or more clock cycles do not concern me either.

But you are right, looks like not even IDLE is an option.
While looking around I found this:
https://microchipdeveloper.com/32arm:samd21-systick

I currently have the datasheets for SAM C2x, E5x and D21  open and these have close to no information about SysTick.
All three say that SysTick is clocked by CLK_CPU while the page above says it is clocked by AHBCLK for the SAM D21.
CLK_CPU makes more sense though since SysTick is part of the core.
And CLK_CPU is stopped in all modes except ACTIVE.
There is no indication in the datasheets what would happen if the clocksource bit is not set.

So I just changed my SAM E51 code to this:

Code: [Select]

void init_systick(uint32_t ticks)
{
    SysTick->CTRL = 0;
    SysTick->LOAD = ticks - 1U; /* set the reload register */
    SysTick->VAL = 0; /* clear current counter value */
    SysTick->CTRL  = SysTick_CTRL_CLKSOURCE_Msk | SysTick_CTRL_ENABLE_Msk; /* enable systick */
}

int main(void)
{
    uint8_t led_delay = 0;

    init_clock();
    init_io();
    init_systick(120000000 / 200); /* configure and enable Systick for 5ms ticks */

    CMCC->CTRL.bit.CEN = 1; /* enable Cache-Controller */

    while (1)
    {
        if(SysTick->CTRL & SysTick_CTRL_COUNTFLAG_Msk)
        {
// system_tick = 0;

            led_delay++;

It works and also replacing SysTick_Config() to not even enable the systick interrupt saves 32 bytes of program memory in total.

There really is no argument to make for saving 32 bytes out of 128 kiB, 256 kiB or even 512 kiB flash.
I am even compiling with -O2 now as my software runs faster while the binary is a little bigger.
A few clock cycles also do not make any difference for me now.

Well, my argument to be able to use sleep this way seems to be invalid.

Hmm, I got nothing to argue against this minor improvement so I might just keep it. :-)

Thanks for the tip and the oportunity to have a closer look at this!

[bson]

I *think* their idea is to run sysTick with varying counts, so as to enable sleeping between "ticks" or something.  That's not the USUAL way to use sysTick.  (although to be fair, having the system wake up every millisecond or so just to increment a tick counter is probably not a great way to achieve low-power devices.)

SysTick though is a core peripheral, so runs off the core clock, which means if it's used the core clock can't be shut down like with any of the typical peripheral bus timers.  In reality though I've compared them on STM32 and any difference was sub-µA territory so I just didn't care.  It just didn't matter.  So I use SysTick since it's universally available (in off-the-shelf processors) and requires less porting work just to get the basics going.  I don't use vendor libraries either, so it's typically compile and it just works stuff.