ChibiOS Free Embedded RTOS

Not sure if this is a bug or a constraint.

ChibiOs 19.1.2
Using 32L071, so 16-bit SYSTICK at 1kHz.
CH_CFG_INTERVALS_SIZE 32
CH_CFG_TIME_TYPES_SIZE 32
All diagnostics enabled

I have a virtual timer started for a 5-minute interval (so multiple cycles of SYSTICK).
It appears that this can be handled as long as there are other virtual timers active - the outstanding tick count is clearly being reduced progressively.
Occasionally this 5-minute timer is the only one active; I then get a halt triggered by overflow in chTimeAddX() in line 134 of chvt.c.

Hi,

Interesting corner case, I need to verify. It is possible that flashing leds in the various demos hid this.

Giovanni

Confirmed, there is a problem under those conditions, will be fixed over weekend.

Giovanni

Hi,

The fix is to replace line 453 in chvt.h:



with this:



which calculates the delta in the "intervals domain" instead of "absolute time domain" like the previous expression. The two things are not equivalent because the different type size.

Opening a ticket about this, thanks for finding.

Giovanni

Will a test case be added to test for this?

Probably but it will be "conditional", executed only when the kernel is configured in the right mode: tickless and (sizeof(interval) > sizeof(time)) and no other timers active and systick frequency high enough to not take ages to complete.

So you will not see it executed in default demos, it requires a special run.

Giovanni

Giovanni wrote:Probably but it will be "conditional", executed only when the kernel is configured in the right mode: tickless and (sizeof(interval) > sizeof(time)) and no other timers active and systick frequency high enough to not take ages to complete.

So you will not see it executed in default demos, it requires a special run.

Giovanni

That works. Just as long as it's part of the standard regression test of the kernel. I'm interested in the bug being fixed, and also that the process doesn't allow it to happen again in the future.

Not sure that the fix covers all situations; I saw the problem elsewhere.There are two cases to consider:
a) No virtual timers active; start one with a long delay
b) Multiple virtual timers active; shorter ones expire, until the long delay timer is the only one left.

I think the fix just covers the second case.
The first case brings you to line 134 of chvt.c:
, which is where I noticed the problem.

This must be a different issue with the same root cause, I will inspect all chTimeAddX() call instances.

Note that I tested your case A, it fixes it.

Giovanni

Hi,

Are you sure it happens in the above code?

Because:



the "if" part seems to make the assertion in chTimeAddX() impossible. Could you make a stack trace after the assertion is triggered?

The only problem I found was in function chVTGetTimersStateI():



has been changed in:



All other calls to chTimeAddX() have similar "if" guards.

Giovanni