vtimer: vtimer_msg test crashes after ~49'20"

[OlegHahm]

This behavior can be observed on several ARM based platforms (IoT-Lab_M3 and MSB-A2) - maybe 32 bit overflow?

[jnohlgard]

I think the timer is running at 1 MHz on those platforms, correct?
Then the sign change on a signed 32 bit int would happen after some 35 minutes, and the overflow would occur after 71 minutes. It seems like there is something else going on here, but it may still be some other overflow occurring..

[x3ro]

So I gave debugging this issue a try on the iot-lab_M3 board, but my results are kind of odd.

In order to not have to wait for 50 minutes, I tried setting the hardware timer to a value near to the time that's supposed to cause the issue. For lack of a better way, I added a function timer_simulate to cpu/stm32f1/periph/timer.c:

void timer_simulate(unsigned long value) {
    timer_stop(TIMER_0);
    TIMER_0_DEV_0->CNT = value & 0xffff;
    TIMER_0_DEV_1->CNT = (value >> 16) & 0xffff;
    timer_start(TIMER_0);
}

(I have no idea what problems not setting the TIMER_1 to the same value might cause, but I got the same results setting only TIMER_0 and setting both timers.)

So this appears to work, e.g. if I call it in /tests/vtimer_msg/main.c before the main function enters the while-loop, then the timer seems to start from the time I've specificed. E.g.

timer_simulate(2940000000);

Will make it start from 49 minutes, or

timer_simulate(4290000000);

starts from 71 minutes 30 seconds, i.e. very close to the point of 32-bit unsigned int overflow. The overflow does not seem to be the problem though, since the timer continues counting properly after the hardware timer has overflowed. The only odd thing in that regard is that at the pointer of overflow there are a lot of timer events fired in quick succession.

I also could not reproduce the issue at the 49 minute + something mark.

What is confusing to me is that, if I set the timer to certain values (I have not figured out a pattern yet), it will just never start counting properly. Some examples:

timer_simulate(0xffff0000); # freezes
timer_simulate(0xFFFF0FFF); # freezes
timer_simulate(0xFFF0FFFF); # works

I honestly have no idea why this happens, but I am assuming that I'm just setting the timer to bogus values and thus brake some well-documented mechanism of the CPU that I don't understand.

Hopefully this will be at least somewhat helpful in finding the cause of this issue :)

[LudwigKnuepfer]

I just remembered this, someone should test if this has to do anything with it:
#374 (comment)

[phiros]

@OlegHahm: I won't be able to properly investigate this before next week.
So I guess this bug won't be fixed before the release.

[OlegHahm]

I prefer to leave the milestone until the release notes are written (for the "known issues" section).

[LudwigKnuepfer]

Doesn't make much sense because you still need to sift through all open issues for other milestones...

[LudwigKnuepfer]

... unless this is "featured" issue of course ;)

[OlegHahm]

I need to sift...?

[LudwigKnuepfer]

Well, whoever creates the list of open issues. But that is besides the point, isn't it?

[OlegHahm]

Partly. The point is: so far I was the one mostly writing the release notes and having issues tagged to go into the known issues sections was helpful for me.

[OlegHahm]

vtimer is history