Exceeding Delta Assert

ChibiOS public support forum for all topics not covered by a specific support forum.

Moderators: RoccoMarco, lbednarz, utzig, tfAteba, barthess

jtomada
Posts: 1
Joined: Wed Apr 18, 2018 10:10 pm

Exceeding Delta Assert

Postby jtomada » Wed Apr 18, 2018 10:21 pm

Hi,

I'm getting an assert at chVTDoTickI() after running my program a while.

This is the assert

Code: Select all

chDbgAssert(chTimeDiffX(ch.vtlist.lasttime, chVTGetSystemTimeX()) <=
              chTimeDiffX(ch.vtlist.lasttime, chTimeAddX(now, delta)),
              "exceeding delta");


The backtrace looks like this

Code: Select all

#0  0x08005256 in chSysHalt (reason=0x800a450 <__func__.7580.lto_priv.336> "chVTDoTickI") at ../../ChibiOS_18.2.0/os/rt/src/chsys.c:206
#1  0x080071d4 in chVTDoTickI.lto_priv.333 () at ../../ChibiOS_18.2.0/os/rt/include/chvt.h:465
#2  0x0800526a in chSysTimerHandlerI () at ../../ChibiOS_18.2.0/os/rt/src/chsys.c:355
#3  0x080077d6 in osalOsTimerHandlerI () at ../..l/ChibiOS_18.2.0/os/hal/osal/rt/osal.h:603
#4  0x0800780e in VectorB0 () at ../../ChibiOS_18.2.0/os/hal/ports/STM32/LLD/TIMv1/hal_st_lld.c:264
#5  <signal handler called>
#6  0x55555554 in ?? ()


System time configuration

Code: Select all

#define CH_CFG_ST_RESOLUTION                32

#define CH_CFG_ST_FREQUENCY                 1000000

#define CH_CFG_INTERVALS_SIZE               32

#define CH_CFG_TIME_TYPES_SIZE              32

#define CH_CFG_ST_TIMEDELTA                 2


I don't quite understand this assert. Any ideas on what may be causing this? Appreciate the help.

User avatar
Giovanni
Site Admin
Posts: 14444
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 1074 times
Been thanked: 921 times
Contact:

Re: Exceeding Delta Assert

Postby Giovanni » Thu Apr 19, 2018 7:46 am

Hi,

It means that the combined execution time of you callbacks (and all ISRs) exceeds the timer systick interval causing a loss of sync in the tick-less mechanism. This error can be very random and it is a good idea to stress test systems with assertions enabled when using high tick rates.

You can:
1) Reduce systick frequency (skip this).
2) Optimize your callbacks/ISRs to reduce the total time (good thing anyway).
3) Increase the CH_CFG_ST_TIMEDELTA until the problem disappears, this parameter makes the system more tolerant at expense of jitter (the value is in systick cycles). It represents the minimum interval that the system can handle, smaller intervals are aligned to this minimum.

Giovanni

faisal
Posts: 374
Joined: Wed Jul 19, 2017 12:44 am
Has thanked: 44 times
Been thanked: 60 times

Re: Exceeding Delta Assert

Postby faisal » Thu Apr 19, 2018 5:12 pm

Giovanni wrote:It means that the combined execution time of you callbacks (and all ISRs) exceeds the timer systick interval causing a loss of sync in the tick-less mechanism. This error can be very random and it is a good idea to stress test systems with assertions enabled when using high tick rates.


I don't think I quite understand this. So, when an interrupt occurs (ISRs, and VT callbacks), are you saying that if the execution time of the interrupt exceeds the interval when the next systick interrupt is scheduled for - then this error can occur? By systick interval do you literally mean one sys tick? In my case that is 1us (1MHz sys tick). So if any timer callback or ISR takes more than 1us this error would occur? I made a little test program to test it, and that doesn't seem to be the case. As you can see below, I made several virtual timers and set them to be 100us apart. In the callback of each virtual timer, I do a polled delay of 80000 cycles, which is 1000us (80MHz sys clock). It works fine, and does not trigger the assertion.

I think the only way the system should 'lose sync' is if the combined execution time is more than the time it would take for the systick timer to wrap around completely. If an individual callback or isr takes more than a systick interval - the future ones should be pending and be executed in order until the system catches up ... sort of what happens with a nested interrupts at various priorities. The example below demonstrates that a callback that exceeds the systick interval, and even delays future timer events work just fine.

Please help me understand.

Code: Select all

#define NUM_VTS (3)
virtual_timer_t vt_array[NUM_VTS];

static void vt_cb (void *p)
{
  chSysPolledDelayX((int32_t)p);
}

int main (void)
{

  halInit();
  chSysInit();

  while (true)
  {
    for (int i = 0; i < NUM_VTS; i++)
    {
      chVTSet(&vt_array[i], 100 * i + 100, &vt_cb, 80000);
    }
    chThdSleepMilliseconds(500);
  }
  return 0;
}

User avatar
Giovanni
Site Admin
Posts: 14444
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 1074 times
Been thanked: 921 times
Contact:

Re: Exceeding Delta Assert

Postby Giovanni » Thu Apr 19, 2018 5:41 pm

Hi,

In is not exactly that way even if it is a factor.

The main difference between the ticked and tick-less mode is that in ticked mode system time does not increase while in a critical zone, in tick-less mode it continues to advance because it is an HW counter.

This can cause the virtual timers to miss the next deadline if it too close (below delta) to the "now" being processed, the delta parameter makes so the next deadline (while inserting a timer in the list) is never too close to "now". It could happen that by the time the timer is in the list and the comparator set to the next deadline the counter has always went past the deadline, the deadline would be then processed after the counter made a full wrap.

Increase the delta until you don't get the assertion anymore, I cannot just make some kind of table because the duration of VT callbacks is a factor.

Delta cannot be 1 because quantization, 1 would mean anything between 0 and 1.

Giovanni

faisal
Posts: 374
Joined: Wed Jul 19, 2017 12:44 am
Has thanked: 44 times
Been thanked: 60 times

Re: Exceeding Delta Assert

Postby faisal » Thu Apr 19, 2018 6:04 pm

Would it be correct to say that timedelta should be greater than the time it takes to add a new timer to the vtlist (including any interrupts and the such that could occur while it is *being added*? Is it this insertion of a new timer operation and potentially reprogramming the tick comparator that is critical? Interrupts and the such shouldn't be a problem however, as the chVTDoTickI() and chVTDoSetI() are executed in a locked state (well, fast interrupts which bypass everything could be a problem, but I'm not using those..).

The critical region seems to be from when 'now' is calculated: systime_t now = chVTGetSystemTimeX(); , to when port_timer_start_alarm or port_timer_set_alarm is called, correct?

User avatar
Giovanni
Site Admin
Posts: 14444
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 1074 times
Been thanked: 921 times
Contact:

Re: Exceeding Delta Assert

Postby Giovanni » Thu Apr 19, 2018 6:29 pm

Consider the case where a timer callback inserts a timer in the list, multiple callbacks could be processed in the same tick BTW. During the callbacks execution the counter continues to advance.

I considered adding a suspend/resume functionality for the counter but there is not a real problem and it would make everything much heavier, also, the counter is also useful because it is accurate (polled delays).

I tested up to 16MHz raising the delta without visible problems, probably it could go even higher but resolution would not benefit virtual timers because ISR jitter would be an order of magnitude higher.

IMHO 1MHz is perfect for 32bits counters, a round number and in the same time scale of usual system jitter for an ARM device.

Giovanni


Return to “General Support”

Who is online

Users browsing this forum: No registered users and 15 guests