I am using the stm32f373 virtual timers.
The strange stuff
On the bench with short sensors wires the code works correctly.
All timers are set, and all set timers expire and trigger their coresponding call back.
On the vehicile with long inductive sensor wires the code does not work correctly.
All timers are set, but only the first timer expires and triggers its coresponding call back.
The other timers are set, but do not expire and trigger their coresponding call back.
The timers are set in an ICU callback.
To me this looks like a race condition, caused by the ICU callback triggering too often because of noise on the long inductive sensor wires. How should I add locking to prevent timer race conditions? Assuming that is the problem, could the problem be something else?
virtual timer strangeness
Moderator: RoccoMarco
- Giovanni
- Site Admin
- Posts: 14892
- Joined: Wed May 27, 2009 8:48 am
- Has thanked: 1202 times
- Been thanked: 996 times
Re: virtual timer strangeness
Are you running with debug options enabled? if there is a race condition probably it is because a call protocol violation somewhere.
Also, using VTs in a wrong way can lead to a corruption of the delta list, for example you should not set a timer that is already running etc, you should look for problems of this kind too.
Giovanni
Also, using VTs in a wrong way can lead to a corruption of the delta list, for example you should not set a timer that is already running etc, you should look for problems of this kind too.
Giovanni
Re: virtual timer strangeness
Here is the VT usage.
I check or reset before setting the timer.
Does chVTSetIsr and chVTResetIsr used here need chVTIsArmedI checking?
I check or reset before setting the timer.
Does chVTSetIsr and chVTResetIsr used here need chVTIsArmedI checking?
Code: Select all
const ICUConfig HazardSensorConfig = {
.mode = ICU_INPUT_ACTIVE_HIGH,
.frequency = HAZARD_FREQUENCY,
.width_cb = NULL,
.period_cb = HazardPeriodCB,
.overflow_cb = NULL,
.channel = HAZ_TIM_CHANNEL
};
Code: Select all
static void HazardPeriodCB(ICUDriver *icup)
{
(void) icup;
chSysLockFromIsr();
if (chVTIsArmedI(&vtsample))
{
chSysUnlockFromIsr();
return;
}
chVTSetIsr(&vtsample, MS2ST(100), TimerFlashSample, NULL);
chVTResetIsr(&vtoff);
chVTSetIsr(&vtoff, S2ST(dbGetTimeoutHazOff()), TimerFlashOff, NULL);
chVTResetIsr(&vtcancel);
chVTSetIsr(&vtcancel, S2ST(dbGetTimeoutHazCancel()), TimerFlashCancel, NULL);
chSysUnlockFromIsr();
}- Giovanni
- Site Admin
- Posts: 14892
- Joined: Wed May 27, 2009 8:48 am
- Has thanked: 1202 times
- Been thanked: 996 times
Re: virtual timer strangeness
Hi,
Before calling chVTResetI() you need to verify if the timer is active: The timer MUST be active when this function is invoked.
Giovanni
Before calling chVTResetI() you need to verify if the timer is active: The timer MUST be active when this function is invoked.
Giovanni