SV#4 problem in ISR callback

[Rick Burnett]

I have an ISR that watches for a pulse on one of my input ports. When that ISR gets triggered, I try and stop an internal timer with:

Code: Select all

gptStop(&GPTD2);

However, that causes a halt, here is the back trace:

Code: Select all

(gdb) backtrace
#0  0x08005fc8 in port_halt () at main.c:295
#1  0x08001978 in chDbgPanic (msg=0x800c6b8 "SV#4")
    at /Users/grimepoch/mac-build/ChibiOS/os/kernel/src/chdebug.c:274
#2  dbg_check_lock () at /Users/grimepoch/mac-build/ChibiOS/os/kernel/src/chdebug.c:117
#3  0x0800256e in gptStop (gptp=0x20001e30 <GPTD2>)
    at /Users/grimepoch/mac-build/ChibiOS/os/hal/src/gpt.c:118
#4  0x08008744 in extcb4 (extp=<optimized out>, channel=<optimized out>) at main.c:658
#5  0x08003976 in Vector68 ()
    at /Users/grimepoch/mac-build/ChibiOS/os/hal/platforms/STM32F4xx/ext_lld_isr.c:122
#6  0xffffffec in ?? ()
#7  0xffffffec in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

This code worked before I added in the chconf options to check for using code improperly. I am trying to stop the timer, because I don't want that to process while I change a bunch of things, then I restart and resent the StartContinuos again.

Clearly I am not understanding something properly with this. The priority of this timer is set to 2 because it really needs priority almost all the time. The ext priority is 6. I am wondering if I should just make the ext priority higher, maybe lower the timer to 3, and then the timer cannot interrupt it. Although this is not really what I want. The ext does not always need to interrupt the timer, only occasionally, so in those instances I do want the timer to take priority.

Thoughts?

[Rick Burnett]

It appears the code now gets through these sections with:

Code: Select all

         chSysLockFromIsr();
         gptStopTimerI(&GPTD2);
         chSysUnlockFromIsr();

And then I do:

Code: Select all

gpt2cfg.frequency = (32*16*1000*CH_FREQUENCY)/currentAverage;

And finally I do this:

Code: Select all

         chSysLockFromIsr();
         //gptStart(&GPTD2, &gpt2cfg);
         gptStartContinuousI(&GPTD2, 100);
         chSysUnlockFromIsr();

Where you can see I could not use gptStart anymore. It seems this runs with no problem, but the timer frequency is not changed after I call continuous again. When I was not running properly, gptStart would change the frequency.

I'm continuing to look through the code. I guess one thing I could do is go see how gptStart is changing the frequency.

[Rick Burnett]

So I brute forced the update of the frequency with adding this before calling StartContinuous:

Code: Select all

         uint16_t psc = (uint16_t)((GPTD2.clock / GPTD2.config->frequency) - 1);

         /* Timer configuration.*/
         GPTD2.tim->CR1  = 0;                          /* Initially stopped.       */
         GPTD2.tim->CR2  = STM32_TIM_CR2_CCDS;         /* DMA on UE (if any).      */
         GPTD2.tim->PSC  = psc;                        /* Prescaler value.         */
         GPTD2.tim->DIER = GPTD2.config->dier &        /* DMA-related DIER bits.   */
                    STM32_TIM_DIER_IRQ_MASK;
         GPTD2.tim->SR   = 0;                          /* Clear pending IRQs.      */

And the code works properly now. Of course, not sure what I could be breaking by doing this, but so far all the testing is positive.

[Giovanni]

Hi,

gptStart() is not an I-class function and cannot be called from ISRs or callbacks. You should not need to call it from ISR anyway, what is the reason?

Giovanni

[Rick Burnett]

I have an EXT trigger that when it's activated, sometimes I want it to change the frequency of the timer and to restart the timer. I want this to happen in the ISR for the trigger.

[Giovanni]

There are other functions meant for that:

gptStartOneShotI()
gptStartContinuousI()
gptStopTimerI()
gptChangeIntervalI()

You can reprogram the timer on the fly without having to restart it.

Giovanni

[Rick Burnett]

There are two time values associated with a timer, there is the frequency setting and then the polling interval. What you've shown allows me to change the polling interval, but I don't want to change that, I want to change the frequency. I guess technically I could change my code to affect the polling interval (or whatever that is called) instead

Right now, what I do is set a frequency based on some BPM (beats per minute) that I want and interval is set to a fraction of that (in my case 100).

When the BPM changes, I change the frequency of the timer and leave the interval the same, 100.

In this use mode, the functions you give do not allow me to change that value. But, it would allow me to change the interval.

I'm trying to understand why I wouldn't want to change the frequency of the timer? Because this is really what I want. It makes sense to me mathmatically because the interval is always a count of cycles that I want to call the ext int at.

Rick

[Giovanni]

You could generate an event from your callback and do gptStart() from thread level.

Giovanni

[Rick Burnett]

I could do that, but, my main thread is pretty low priority in comparison, so there would be a delay to when the timer was started which is pretty high priority. The reason being is the interrupt is actually trying to sync the timer to something else.

Is there a problem with me setting it like I have, just pulling out that part of the Start code? I guess I am curious why that is bad. Currently, it is working, but I want to understand the risks. I guess I'll need to go read the data sheet some more on timers.

[Giovanni]

Absolutely no problems with that. Just me trying to understand the driver limitations.

Giovanni