Getting stuck with tickless mode

[kulve]

I don't know if this matters but I've changed the timer from 2 to 5 as I wanted to use TIM2 for PWM:

#define STM32_ST_IRQ_PRIORITY 8
#define STM32_ST_USE_TIMER 5

I don't know from where the priority is. Most likely cut'n'pasted from one of the F4 Discovery demos.

[Giovanni]

I committed the fix and some optimizations. The problem was exactly what I mentioned yesterday.

Right now I am running my demo with systick at 4MHz and delta=2... crazy, I have not hit the limit yet.

The test suite just fails one test (1.4) because US2ST() overflows internally because it uses 32bits arithmetic, 64 bits would be required with those extreme resolutions.

The problem I have is that this code is uncomfortably hard to test because the extreme realtime constraints.

Giovanni

[steved]

Looks like I may be creating a different problem, since no obvious change for me running the latest code. (Downloaded about 3 hours ago).

Still stStartAlarm after a random time of 3-45 minutes. I've tried with DELTA=2 and DELTA=5.

Will try and dig deeper over the next few days.

[Giovanni]

Well... this is disappointing. Could you provide a stack trace at assertion?

Giovanni

[kulve]

At least my code runs well on the latest ChibiOS version.

Thanks.

[steved]

Well... this is disappointing. Could you provide a stack trace at assertion?

Giovanni

I agree.
Have updated again from repository just to confirm there wasn't any time delay on that side.
I stopped the code while it was running normally, and identified that there are, at least some of the time, two timers running:

Good timer state

Timer_List_good.png (2.81 KiB) Viewed 5431 times

And three threads:

Thread list

Thread_List_Good.png (7.37 KiB) Viewed 5431 times

Stack trace for stStartAlarm halt is as follows:

Call_Stack_030415.png (12.52 KiB) Viewed 5431 times

Can't seem to post another attachment, but after the halt the only active timer was the one at 0x20000910. So something strange is going on.
I have two timers in use:
1. There is a simple idle timer in the main loop, which is always active.

Code: Select all

  while (TRUE)
  {
    chThdSleepMilliseconds(500);
  }


It looks like this idle loop timer is the one at 0x200005BC, which is within the process stack area (which ends at 0x20000600)

2. The other timer (at 0x20000910) is periodically started, retriggered or stopped as required. It is explicitly defined within a structure. In theory this timer will never time out, unless receive characters are missed.

So its not clear why chVTDoSetI() thinks the timer list is empty - as a minimum there should always be one in the list.

Looking at the stack trace in more detail, the timer called from rxRetriggerI() is at 0x20000910, and is being set to a timeout of 100msec - a count of 1000 (0x3e8) given the 10KHz systick.


It may be relevant that the halt always occurs when chVTDoSetI() is starting up a timer from reset, rather than updating a timer which is currently active.

It looks as if the 'idle timer' has gone missing from the list. Is this expected behaviour?

[Giovanni]

Thanks, it seems to be something different from what I already fixed, I will look into it. There seems to be a code path leading to an empty timers list with the alarm still set.

Giovanni

[Giovanni]

So its not clear why chVTDoSetI() thinks the timer list is empty - as a minimum there should always be one in the list.

It is not always there, once every half second it is not armed for few instructions, the UART interrupt could preempt right there, in that case we would have the empty list case in chVTDoSetI().

Is there anything strange in that UART callback? is the critical zone entered before calling chVTSetI() ?

Giovanni

[Giovanni]

I found a stupid error, probably the cause.

There was a path in chVTDoResetI() where the function pointer was not set to NULL, this would leave the timer marked as "armed" so there was the potential for removing it from the list twice.

Committed the fix.

I also removed a check in chVTDoResetI() in order to make it faster on average, it was a very corner case.

Giovanni

[steved]

Sorry, but still crashes, although different symptoms; did this after about an hour and a half with DELTA=2

Call stack

Call_Stack_040415.png (41.47 KiB) Viewed 5392 times

There are still two timers shown in the debug list, so looks like you've found and fixed the earlier problem.
I've set it running again

In answer to your previous question, the sequence on a receive character interrupt is:

Code: Select all

UART ISR executes callback
  chSysLockFromISR();
  Execute some code which usually does   chVTSetI(&target->channelTimer, MS2ST(100), rxTimeout, target); ('target' is my structure containing the timer)
  Every so often, instead of retriggering the timer, the code does     chVTResetI(&target->channelTimer);
  chSysUnlockFromISR();


The UART ISR code, although nominally mine, looks remarkably similar to the Serial driver ISR.

Edit: Crashed again in the same way after less than 10 minutes.
The update also included the modified time to system tick conversion macros

I've also noticed that the delta for both timers is >2000. Given that I'm setting my timer to 100msec and have a system tick of 10KHz, this presumably shouldn't happen!

Timer_List_040415.png (3.2 KiB) Viewed 5392 times

Is it possible that the system time is being incorrectly read?