systick timer on SAMC

[Simon]

I'm trying to implement the systick timer on a samc for general program timing. I don't see a specific interrupt line for it in the ARM interrupt controller, is it always active anyway? I see there is a dummy handler for it in the header files and it has a bit in the register to enable an "exception request".

[Rudolph Riedel]

There is SysTick_Config() in the CMSIS headers.
https://github.com/RudolphRiedel/FT800-FT813/blob/5.x/examples/EVE_Test_SAMC21_EVE2-50G/main.c

[Simon]

right, in there "somewhere". I see some code that sets the tick interval but that is all.

[Rudolph Riedel]

As I wrote, this is part of CMSIS: https://developer.arm.com/documentation/dui0646/b/BABIDIGI

[wek]

SysTick interrupt is permanently enabled, see ARMv7-M Architecture Reference Manual, chapter B1.5 Armv7-M exception model. [EDIT] See ataradov's post below [/EDIT]

You can enable/disable SysTick counter, though, effectively enabling/disabling the related interrupt.

[EDIT] The same applies to ARMv6-M (Cortex-M0/M0+)[/EDIT]


JW

[ataradov]

SysTick interrupt can be enabled independently from the timer. CSR.TICKINT enables the interrupt and CSR.ENABLE  enables the timer itself.

The SysTick interrupt handler is in the first "core" group of the interrupts. You don't need to define it (have it be dummy) if CSR.TICKINT=0. And I assume your "exception request" is TICKINT.

[westfw]

I don't see a specific interrupt line for [SysTick] in the ARM interrupt controller

Systick is part of the ARM "core", so it doesn't go through the NVIC.  Also it frequently won't show up in vendor documentation that only documents what the "core" considers "external interrupts."  SysTick on an CM0 is always exception number 15 (and #16 is the first external interrupt.)
I guess that makes it "permanently enabled" in the sense that you don't have to turn it on (and you can't change it's priority) in the NVIC.  You just have to turn on the interrupt bit in SysTick itself.

[ataradov]

You can change SysTick priority though SCB.SHPR3 register.

[Simon]

Uh, yes I'm not done yet, the interrupt fires but then never again, naturally ARM documentation does not point you around, found this collection of registers: https://developer.arm.com/documentation/dui0497/a/cortex-m0-peripherals/system-control-block?lang=en with a Interrupt Control and State Register. I'm still confused though as this is the old manual clearing of the interrupt to stop it constantly firing logic that I am going down but I actually have the opposite, it fire once and never again.

Is there a place where I can see some of the code that the automatic code generator uses? I don't want to have to actually dable with the horrible mess that the configurator in mplabx is and I am using studio as it's less distracting but it feels like looking at examples may be more informative than trying to read a self generated manual.

[voltsandjolts]

Are you sure you are writing the reload register SysTick->LOAD?
I've never used SAMC but setup can't be too different from STM32...

Code: [Select]

volatile uint32_t systicks10ms;

void SysTick_Handler(void) {
systicks10ms++;
}

static inline void SuspendTick(void) {
SysTick->CTRL &= ~SysTick_CTRL_TICKINT_Msk;
}

static inline void ResumeTick(void) {
SysTick->CTRL |= SysTick_CTRL_TICKINT_Msk;
}

void main(void) {

NVIC_SetPriority(SysTick_IRQn, TICK_INT_PRIORITY);
SysTick->LOAD = (SystemCoreClock / 100) - 1; /* set auto reload register for 10ms systick rate */
SysTick->VAL = 0UL;
SysTick->CTRL = SysTick_CTRL_CLKSOURCE_Msk | /* clock is HCLK, remove this for HCLK/8 */
SysTick_CTRL_TICKINT_Msk | SysTick_CTRL_ENABLE_Msk; /* Enable SysTick IRQ and SysTick Timer */

}


[ataradov]

naturally ARM documentation does not point you around

First of all, download the PDF version so you have everything at once and a meaningful search. Arm documentation for the core only briefly mentions the registers that are implemented in this core, the actual description of the operation is in the Architecture Reference Manual (DDI0419C_arm_architecture_v6m_reference_manual.pdf), which is referenced from the main core document.

The code above is correct. You don't need to do anything special, just configure LOAD value and set TICKINT and ENABLE. Interrupt handler would be called automatically and you just run the code you need there, no need for any other maintenance, interrupt clearing or anything like that.

[wek]

SysTick interrupt can be enabled independently from the timer. CSR.TICKINT enables the interrupt and CSR.ENABLE  enables the timer itself.

I stand corrected, thanks.

Wading through ARMv6M ARM (btw.this is telling, too), I stumbled upon an interesting fact: while in ARMv7M SysTick is integral part of processor, in ARMv6M it is optional.

JW

[Simon]

This is what I have, it transmits once rather than once every 350ms

Code: [Select]


#define systick_reset_value 0x00FFFFFF // 350ms value between 0x0 and 0x00FFFFFF (24 bits)


// https://developer.arm.com/documentation/dui0497/a/cortex-m0-peripherals/optional-system-timer--systick?lang=en

#define SYST_CSR ( *(uint32_t *) 0xE000E010 ) // SysTick Control and Status Register
#define SYST_RVR ( *(uint32_t *) 0xE000E014 ) // SysTick Reload Value Register
#define SYST_CVR ( *(uint32_t *) 0xE000E018 ) // SysTick Current Value Register
// #define SYST_CALIB ( *(uint32_t *) 0xE000E01C ) // SysTick Calibration Value Register (not implemented)

// https://developer.arm.com/documentation/dui0497/a/cortex-m0-peripherals/system-control-block?lang=en
#define ICSR ( *(uint32_t *) 0xE000ED04 ) // Interrupt Control and State Register

void systick_setup()
{
SYST_RVR = systick_reset_value ;
SYST_CVR = 0x0 ;
SYST_CSR = 0x1 << 2 | 0x1 << 1 | 0x1 << 0 ;
}

void SysTick_Handler()
{

sys_com_tx( 0 , 0) ;
}



[eutectique]

You are transmitting from the interrupt handler. Not seeing the implementation of sys_com_tx(), I would not say that it's wrong. But it's suspicious.

[ataradov]

The code is fine assuming vector table has SysTick_Handler in the corresponding entry.  Also, what is your core frequency? 350 ms is a strange value.

So yes, test it some other way. Toggle a pin or something.

[westfw]

#define SYST_CSR ( *(uint32_t *) 0xE000E010 ) // SysTick Control and Status Register

Why are you doing this instead of just #including the appropriate CMSIS include file?  (Not that setting up all the -I include paths to cover both vendor and ARM definitions isn't a pain, but if an IDE doesn't do it for you, you should only have to do it once, somewhere.)

350 ms is a strange value.

350ms is about what you get when you divide a 48MHz clock (SAMC max) by the ~16e6 maximum systick divisor.  It ought to show nicely on a LED, which I guess is nice.
I've never actually used sysTick with the maximum divisor, but I can't imagine that it would have a bug there.

in ARMv6M [sysTick] is optional.

I haven't ever seen an implementation without it...

[ataradov]

SysTick is clocked directly by the core clock, there is no configurable divisor. Misinterpreted your sentence about the divider.

But yes, I originally miscalculated. (1<<24) / 48e6 is 350 ms, so this makes sense.

It would work with the maximum value, I use that all the time to implement a full system time. Just let the timer overflow and in the interrupt increment remaining bits. When you need to take the time, combine the current value of the counter with the incrementing variable. This way you get very granular system time for cheap.

[wek]

in ARMv6M [sysTick] is optional.

I haven't ever seen an implementation without it...

FPU in CM4 is optional, too. I believe all initial implementations did include it, and only later appeared implementations which chose to omit it (I may be wrong and it may be only me not being aware of the early FPU-less implementations). At any case, it raised enough confusion so that ARM and some (most?) implementers rebadged the FPU-containing CM4 as CM4F.

OTOH, FPU is probably quite a chunk of silicon while SysTick is probably miniscule in size, so it probably doesn't make any sense to omit it. I don't see any reason for it to be optional, but then I am not a decision maker in ARM.

JW

[ataradov]

It is probably optional because the first core using ARMv6-M was Cortex-M1 targeting FPGAs. And there SysTick may be costly and not necessary. Plus it is far easier to have options in the FPGAs.

[Simon]

I'll set the pin up as a digital output tomorrow and toggle it.

[Simon]

OK that works, i have problems somewhere else.

[sslupsky]

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:
https://github.com/zephyrproject-rtos/zephyr/blob/main/drivers/timer/cortex_m_systick.c

[westfw]

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.)

[sslupsky]

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.)

Yes, Zephyr can be configured to use a tick or to be "tickless".

The clock API's are documented here:  https://docs.zephyrproject.org/latest/doxygen/html/group__clock__apis.html

Which provides a bit more explanation about what this driver is supposed to do.

Unfortunately, the Systick in the Cortex M0 is not very power efficient.  For SAMD you can achieve quite low power operation using the RTC to generate the system timer.

[cv007]

For SAMD you can achieve quite low power operation using the RTC to generate the system timer.

A low power timer (32k clock source) is a good alternative in any case as you can keep time moving through low power modes, plus you get a single clock speed running the time that doesn't change or depend on a 'ticks per second' define (as is used in the zephyr project which means your time is based on one cpu speed that cannot change).

For a sam with a rtc in 32bit count mode, you get ~36 hours to work with at highest resolution (~30us, plenty good for general use), and by also keeping track of overflows you get a system time that never rolls over.


//using a time stamp, manually checking time
led.on(); //on for 10 seconds
auto t = now() + 10_sec;
while( now() < t ){}
led.off();

//blocking wait in low power mode, default low power mode is standby, uses rtc compare to wake
while( true ){ wait(1_sec); led.toggle(); }

//wait random time between 100ms/2sec
while( true ){ wait(100_ms, 2_sec); led.toggle(); }

The above code works the same when using an avr0/1 series for example with its rtc peripheral (16bit). The details are a little different like available low power modes and the timer width, but the app code will look the same. There is usually a low power timer in the modern mcu that is typically unused.