low-level TIM conflict with Chibio?

ChibiOS public support forum for topics related to the STMicroelectronics STM32 family of micro-controllers.

Moderator: RoccoMarco

User avatar
russian
Posts: 368
Joined: Mon Oct 29, 2012 3:17 am
Has thanked: 16 times
Been thanked: 14 times

low-level TIM conflict with Chibio?

Post by russian »

I have some code which works with a TIMer directly but it looks like it is somehow hurting ChibiOS. I believe I have to work with a timer directly for my use-case - I need to schedule events with a smaller than 1 sec / CH_FREQUENCY granularity.

The code starts 1MHz 32bit timer and I hope it is only generating an event then ARR is zero, so that's 100ms - I hope there is no event every microsecond. The LED is blinking as expecting, ChibiOS code is not touching the same LED and it is not touching the same timer.

Code: Select all

static TIM_TypeDef *TIM = TIM5;

static void setTimer(int arr) {
   TIM->ARR = arr - 1;
   TIM->EGR |= TIM_EGR_UG; // generate an update event to reload timer's counter value
   TIM->CR1 |= TIM_CR1_CEN; // restart timer
}

static void callback(void) {
   GPIOD->ODR ^= (1 << 13);   // Toggle D13
   setTimer(100000); // 100ms
}

CH_FAST_IRQ_HANDLER(STM32_TIM5_HANDLER) {
   if (((TIM->SR & 0x0001) != 0) && ((TIM->DIER & 0x0001) != 0)) {
      callback();
   }
   TIM->SR = (int) ~STM32_TIM_SR_UIF;   // Interrupt has been handled
}

void TIM_Init(void) {
   RCC->APB1ENR |= RCC_APB1ENR_TIM5EN;   // Enable TIM5 clock
   NVIC_EnableIRQ(TIM5_IRQn);   // Enable TIM5 IRQ
   TIM->DIER |= TIM_DIER_UIE;   // Enable interrupt on update event
   TIM->CR1 |= TIM_CR1_OPM; // one pulse mode: count down ARR and stop
   TIM->CR1 &= ~TIM_CR1_ARPE; /* ARR register is NOT buffered, allows to update timer's period on-fly. */

   TIM->PSC = 84 - 1;   // 168MHz / 2 / 84 = 1MHz, each tick is a microsecond

   setTimer(100000); // 100ms
}


The symptoms: looks like the threads under Chibi control stop at some random point (some seconds after the start), the TIMer is blinking happily. To make this more fun, this seems to work better under debugger.

What do I do wrong?
User avatar
Giovanni
Site Admin
Posts: 14892
Joined: Wed May 27, 2009 8:48 am
Has thanked: 1202 times
Been thanked: 996 times

Re: low-level TIM conflict with Chibio?

Post by Giovanni »

It this timer used by tickless mode (in case you are using 3.0)?

Giovanni
User avatar
russian
Posts: 368
Joined: Mon Oct 29, 2012 3:17 am
Has thanked: 16 times
Been thanked: 14 times

Re: low-level TIM conflict with Chibio?

Post by russian »

Interesting, are you saying that what I am trying to implement is close to 3.0 tickless timing? viewtopic.php?f=3&t=1316 says 20-50uS. I should definitely check that.

In the meantime, I am still on 2.6.1 and AFAIK TIM5 is not used by Chibios. So, where are they hitting each other?
User avatar
russian
Posts: 368
Joined: Mon Oct 29, 2012 3:17 am
Has thanked: 16 times
Been thanked: 14 times

Re: low-level TIM conflict with Chibio?

Post by russian »

I've upgraded to 2.6.3 but I still have the issue.

I have a thread which blinks the blue LED, and the TIMer thread is blinking the orange LED. After ~11 seconds the chibiOs thread stops blinking while the TIMer is still blinking

Here is the message I get while trying to see the status via the ChibiOS Eclipse plugin:

Image

On the other hand, I've tried one of the demo projects and added my hardware TIMer into them and they seem fine. I will try turning subsystems one by one and see which one makes the difference between the non-failing demo project and my failing code.
User avatar
russian
Posts: 368
Joined: Mon Oct 29, 2012 3:17 am
Has thanked: 16 times
Been thanked: 14 times

Re: low-level TIM conflict with Chibio?

Post by russian »

Some additional information: while I cannot get anything in the debugger, I have my HD44780 LCD panic handler. It says the panic is a stack overflow in the system 'idle' thread.
I guess this and the message from the plugin are both pointing to some state constant violation, but I have no idea how I am causing it :(
User avatar
Giovanni
Site Admin
Posts: 14892
Joined: Wed May 27, 2009 8:48 am
Has thanked: 1202 times
Been thanked: 996 times

Re: low-level TIM conflict with Chibio?

Post by Giovanni »

Are you compiling using -O0? it increases the stack usage and can cause such problems. Try -O2.
You can also increase the stack assigned to the idle thread by adding the setting in chconf.h.

Giovanni
User avatar
russian
Posts: 368
Joined: Mon Oct 29, 2012 3:17 am
Has thanked: 16 times
Been thanked: 14 times

Re: low-level TIM conflict with Chibio?

Post by russian »

Giovanni wrote:You can also increase the stack assigned to the idle thread by adding the setting in chconf.h

Looks like

Code: Select all

#define PORT_IDLE_THREAD_STACK_SIZE     768

has helped, but why? Why would the TIMer affect idle thread stack usage?
User avatar
Giovanni
Site Admin
Posts: 14892
Joined: Wed May 27, 2009 8:48 am
Has thanked: 1202 times
Been thanked: 996 times

Re: low-level TIM conflict with Chibio?

Post by Giovanni »

It is not the timer affecting is, are you compiling with optimizations disabled?

Anyway, probably you just need to increase it to 32 or 64 bytes.

Giovanni
User avatar
russian
Posts: 368
Joined: Mon Oct 29, 2012 3:17 am
Has thanked: 16 times
Been thanked: 14 times

Re: low-level TIM conflict with Chibio?

Post by russian »

I am compiling with -O0 for a while already to simplify debugging, this has not changed - and it works unless I enable TIM5. Looks like it is hanging up only when I enabled the TIMer.

Will try PORT_IDLE_THREAD_STACK_SIZE 64
User avatar
russian
Posts: 368
Joined: Mon Oct 29, 2012 3:17 am
Has thanked: 16 times
Been thanked: 14 times

Re: low-level TIM conflict with Chibio?

Post by russian »

I am sorry I am returning to this.

May I suggest increasing the default value of PORT_IDLE_THREAD_STACK_SIZE to 16 and the default value of PORT_INT_REQUIRED_STACK to maybe 128 or 256? My point is that while this is nothing on the scale of stm32 RAM sizes, that would save a lot of time and nerves to all the regular Joe's like me. The less system stuff needs to be changed to start writing 'business logic' the better, is not it?
Post Reply