Introducing the new delivery for STM

The official STMicroelectronics Arduino core
User avatar
Slammer
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
GrumpyOldPizza
Posts: 173
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
RogerClark
Posts: 5564
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

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

mailhouse
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:
    Serial.begin(9600);
    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:
  Serial.println(TIM2->CNT);
  delay(50);
}


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

    __TIM2_CLK_ENABLE();
    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;
    HAL_TIM_Base_Init(&s_TimerInstance);
    HAL_NVIC_EnableIRQ(TIM2_IRQn);
    HAL_TIM_Base_Start_IT(&s_TimerInstance);   
   


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.

danieleff
Posts: 216
Joined: Thu Sep 01, 2016 8:52 pm
Location: Hungary
Contact:

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
RogerClark
Posts: 5564
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

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

Re:2

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

nikosx
Posts: 7
Joined: Sun May 07, 2017 4:33 pm

Re: Introducing the new delivery for STM

Postby nikosx » Tue May 09, 2017 6:19 am

Hello.
I am using STM32F1xx Cores 2017.1.20 with an STM32 VL Discovery STM32F100RB. Having problems with using integrated DAC channels.
I've used both dac_write_value & analogWrite but with no results (code stucks or does nothing), even when i did some changes in g_current_init_id of analog.c

However, ADC functions work OK !!!

Think the DAC code is incomplete. What's the situation ?

Thanks,
Nick

edogaldo
Posts: 243
Joined: Fri Jun 03, 2016 8:19 am

Re: Introducing the new delivery for STM

Postby edogaldo » Tue May 09, 2017 7:04 am

You sure STM32F100RB has DAC?!
Afaik only HD mcus (from xC on) have DAC..

nikosx
Posts: 7
Joined: Sun May 07, 2017 4:33 pm

Re: Introducing the new delivery for STM

Postby nikosx » Tue May 09, 2017 1:44 pm

YES !! it has 2 DAC outputs (dual DAC). It's both in the STM32VLDISCOVERY board manual Fig 6, block diagr. 12 bit DACs, table 4pinout, PA4 DAC1, PA5 DAC2, also same info in STM32F100xx ref. manual....
Also, there IS code inside analog.c .....

nikosx
Posts: 7
Joined: Sun May 07, 2017 4:33 pm

Re: Introducing the new delivery for STM

Postby nikosx » Tue May 09, 2017 1:46 pm

Sorry, didn;t understand the HD mcu .....


Return to “STM Core”

Who is online

Users browsing this forum: No registered users and 1 guest