Introducing the new delivery for STM

The official STMicroelectronics Arduino core
User avatar
Posts: 241
Joined: Tue Mar 01, 2016 10:35 pm
Location: Athens, Greece

Re: Introducing the new delivery for STM

Postby Slammer » Wed Oct 05, 2016 11:42 pm

SysTick is an optional part of Cortex design, but I think that all STM32's even the smallest members of F0x0 they have it.

User avatar
Posts: 166
Joined: Fri Apr 15, 2016 4:15 pm
Location: Denver, CO

Re: Introducing the new delivery for STM

Postby GrumpyOldPizza » Thu Oct 06, 2016 12:13 pm

RogerClark wrote:@slammer

Do the Cortex M0 also have it ?

I know the nRF51822 Cortex M0 does not have systick, but this is probably something to do with the nRF51 hardware and not that its a Cortex M0

Interesting question. For Cortex-M0 it's a configurable option, although it's defined as part of the core ARMV6M architecture, just like NVIC. For ARMV7M (Cortex-M3/M4/M7) Systick is always present. Cortex-M1 (the FPGA variant) there are more options to disable stuff.

In any case I have not seen any other Cortex-M0/M0+ in the microcontroller space that would have not implemented Systick, other than nRF51xxx.

Just a few more comments for systick. It's a countdown counter. Hence it's tricky to change the interval while counting down, if you want to implement a tickless scheme ala FreeRTOS. So perhaps in some instances it might be more attractive to use another timer for this purpose. However using another timers does cost more power. On L476 (using 64MHz) TIM5 does cost you 0.4mA (the core in sleep mode comes in at 2.4mA). So that is a sizable chunk ...

User avatar
Posts: 5467
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia

Re: Introducing the new delivery for STM

Postby RogerClark » Thu Oct 06, 2016 8:28 pm

Interesting point about the power to run the timer.

That is a considerable amount of current for a low power device.

I dont suppose there is any point changing this for the Nucleo L4 but on the other boards, If Wi6 decide to use a timer for millis, I think we will probably end up changing it back to using systick

Posts: 26
Joined: Tue Nov 01, 2016 12:19 am

Re: Introducing the new delivery for STM

Postby mailhouse » Sat Nov 05, 2016 12:50 am

Should this crash the board? nucleo-64 stm32f103rb and stm32l476rg show same behavior

Code: Select all

void TIM2_IRQHandler(void) {
  if (TIM2->SR & TIM_SR_UIF)
    Serial.println("TIM2 Interrupt");
  TIM2->SR = 0; // reset the status register

void setup() {
  // put your setup code here, to run once:
    delay(3000); // open your serial console already
    RCC->APB1ENR |= RCC_APB1ENR_TIM2EN; // enable TIM2 clock
    TIM2->PSC = 36000; // clock speed should be 72MHz, so 72MHz/36000 = 2KHz
    TIM2->ARR = 2000; // 2KHz clock/2000 = 1Hz so interrupt handler should run once a second
    TIM2->DIER |= TIM_DIER_UIE; // enable update interrupt
    NVIC_EnableIRQ(TIM2_IRQn); Serial.println("Interrupt set");
    TIM2->CR1 |= TIM_CR1_CEN; // counter enabled
    Serial.println("Timer 2 enabled");

void loop() {
  // put your main code here, to run repeatedly:

If I comment out the EnableIRQ, the counter runs like it should. Am I doing something wrong?

I get the same behavior when i use the HAL library calls

Code: Select all

    s_TimerInstance.Init.Prescaler = 36000;
    s_TimerInstance.Init.Period = 2000;
    s_TimerInstance.Init.CounterMode = TIM_COUNTERMODE_UP;
    s_TimerInstance.Init.RepetitionCounter = 0;
    s_TimerInstance.Init.ClockDivision = TIM_CLOCKDIVISION_DIV1;

so I'm either missing something about STM32 timer interrupts or my install is busted

my goal is two hardware timer interrupts for overflow and match/compare

also, i think this should be weak

Code: Select all

/Users/john/Documents/Arduino/hardware/STM32/STM32F1/variants/STM32F103RB-Nucleo/libstm32f1_nucleo-f103rb_gcc_rel.a(timer.o): In function `HAL_TIM_PeriodElapsedCallback':
timer.c:(.text.HAL_TIM_PeriodElapsedCallback+0x0): multiple definition of `HAL_TIM_PeriodElapsedCallback'

upon further reflection, it is entirely possible that when the interrupt fires right away for the first time, it is spinning in a handler and not actually crashed. as if my IRQHandler() is not being called.

and HAL_Delay() gives very different results between the two cores with the STM32L4 core being about 10x slower. HAL_Delay(1000); is closer to ten seconds on the STM32L476-Nucleo board when its closer to one second on the STM32F103-Nucleo board using the STM32F1 core.

Posts: 106
Joined: Thu Sep 01, 2016 8:52 pm
Location: Hungary

Re: Introducing the new delivery for STM

Postby danieleff » Thu Nov 24, 2016 11:46 am

@Wi6Labs what is the reason for

Code: Select all

uint32_t apin = ulPin&0x0000000F;
in wiring_analog.c in analogRead and analogWrite?

User avatar
Posts: 5467
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia

Re: Introducing the new delivery for STM

Postby RogerClark » Thu Nov 24, 2016 8:33 pm

sounds like several issues going on.

1. Crash when using timers.

2. Limiting analog pins to low pin numbers

3. HAL_Delay not workinb correctly on the L4


I guess this was put in for Nucleo boards. But i am not sure what purpose it performs, i.e it turns pin 16 into pin 0 etc

I am not sure what happens on an AVR Arduino board if you do an analogWrite on pin 16

Return to “STM Core”

Who is online

Users browsing this forum: No registered users and 1 guest