Re: Strange problem with semFlush/semTake

Thanks for your help.
As I stated in one of my previous messages, the cmpTime task takes only
~600 us to run. The interrupt occurs every 52ms .The priority of the
Task was set to 3.
The only other tasks running at a higher priority are: tExcTask and
tLogTask (I am not calling the LogMsg library in my code).

As for the use of semGive instead of semFlush, I tried it and it
didn't correct the behavior.

The added idle task is a simple task that increments a counter and was
set at priority 255. No code was removed.

Thanks again,

Ben



Sperry Family wrote:
By using semFlush(), you demand that the task always arrives at the semTake
before the ISR executes. If the ISR fires, let's say, while your task is
doing this:

intTime = (double)day + tod;

the task will "miss" the semFlush. Perhaps some other task is preempting
cmpTime() and keeping it from running for a long time.

Using semGive() from within the ISR instead of semFlush() would fix such
a problem, as long as the task running cmpTime() is not being preempted
or otherwise delayed long enough to miss two interrupts.

When you add in that "idle" task, are you somehow removing some code
that might be interacting with the cmpTime() task to slow it down or starve
it for a long time?

hichembf@xxxxxxxxx wrote:

Thanks for everyone's input and help.

Bellow is the actuall code for the ISR and the Task. What is confusing
me is that the system behave as expected only when I add the dummy task
(priority 255).

This is the actuall ISR in full
void isrMonitorStart(int notUsed)
{
/* turn Top Left LED ON */
CIO_1_PORT_A |= 0x01;

/* enable DMA requests from UniDig & start DMA engine */
UNIDIG_IN_DMA_ON
DMA_IN_ENABLE(&monDmaBuf, (N_MON_WORD_SEGMENTS));

/* bump counters */
waveGuideCycleCount++;
monStartCount++;

/* signal the rest of the world */
semFlush(semMonitorStart);

/* setup to hit at end of mon cycle */
ENABLE_MONITOR_END_INTERRUPT;

/* turn Top Left LED OFF */
CIO_1_PORT_A &= ~0x01;

return;
}

and the here's the code for the task
void cmpTime()
{

double tod; /* time since 0h UTC today */
int day; /* integer MJD */

while(runSLC)
{
/* wait for the goahead from the start monitor ISR */
if (ERROR == semTake(semMonitorStart, WAIT_FOREVER))
{
perror("semTake");
continue;
}

/* increament our debug cnt */
TimeCnt++;

/* record the time of this call (interrupt) */
tick = sysTick();

/* no message yet */
if(0.0 == msgTick)
continue;

/* Now we calculate the time of day of this interrupt.
First we estimate the time (fraction of a day) under the
assumption that the timing message arrived in zero time
*/

day = (int)msgTime;
tod = msgDiff + tick - day;

intTime = (double)day + tod;

/* This taken from the defunct setTimeStamp task */
gtimeStamp = tick + msgDiff;

} /* end (FOREVER loop) */

return;

} /* cmpTime */

jeanwelly wrote:


I would to see you ISR and the task code snippet to dig out the root
cause.


hichembf@xxxxxxxxx wrote:


Hi,
I am working on a product being developed on MVME162, using VxWorks 5.4
on MC68040.
I am using binary semaphores to sync between interrupts and tasks and I
am seeing a strange behavior.
It is hard to explain but this is the symptom: the semFlush are not
seen and therefore the task doesn't run. I am 100% sure that the
interrupt did happen.
What makes it stranger is that when I added an Idle task (that just
increments a counter) at priority 255, I don't notice the missed
semFlush anymore and the number of executions of the task matches the
number of interrupts.
I keep thinking this can't be right. I tried different experiments
and this was the only conclusion.

I appreciate if someone has idea/input on the issue.

Thanks,

Ben







--------------030405060305060000010202
Content-Type: text/html
X-Google-AttachSize: 4031

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
By using semFlush(), you demand that the task always arrives at the
semTake<br>
before the ISR executes. If the ISR fires, let's say, while your task
is doing this:<br>
<pre wrap="">intTime = (double)day + tod;</pre>
the task will "miss" the semFlush. Perhaps some other task is preempting<br>
cmpTime() and keeping it from running for a long time.<br>
<br>
Using semGive() from within the ISR instead of semFlush() would fix such<br>
a problem, as long as the task running cmpTime() is not being preempted<br>
or otherwise delayed long enough to miss two interrupts.<br>
<br>
When you add in that "idle" task, are you somehow removing some code<br>
that might be interacting with the cmpTime() task to slow it down or
starve<br>
it for a long time?<br>
<br>
<a class="moz-txt-link-abbreviated" href="mailto:hichembf@xxxxxxxxx";>hichembf@xxxxxxxxx</a> wrote:
<blockquote
cite="mid1153245345.293443.128760@xxxxxxxxxxxxxxxxxxxxxxxxxxx"
type="cite">
<pre wrap="">Thanks for everyone's input and help.

Bellow is the actuall code for the ISR and the Task. What is confusing
me is that the system behave as expected only when I add the dummy task
(priority 255).

This is the actuall ISR in full
void isrMonitorStart(int notUsed)
{
/* turn Top Left LED ON */
CIO_1_PORT_A |= 0x01;

/* enable DMA requests from UniDig &amp; start DMA engine */
UNIDIG_IN_DMA_ON
DMA_IN_ENABLE(&amp;monDmaBuf, (N_MON_WORD_SEGMENTS));

/* bump counters */
waveGuideCycleCount++;
monStartCount++;

/* signal the rest of the world */
semFlush(semMonitorStart);

/* setup to hit at end of mon cycle */
ENABLE_MONITOR_END_INTERRUPT;

/* turn Top Left LED OFF */
CIO_1_PORT_A &amp;= ~0x01;

return;
}

and the here's the code for the task
void cmpTime()
{

double tod; /* time since 0h UTC today */
int day; /* integer MJD */

while(runSLC)
{
/* wait for the goahead from the start monitor ISR */
if (ERROR == semTake(semMonitorStart, WAIT_FOREVER))
{
perror("semTake");
continue;
}

/* increament our debug cnt */
TimeCnt++;

/* record the time of this call (interrupt) */
tick = sysTick();

/* no message yet */
if(0.0 == msgTick)
continue;

/* Now we calculate the time of day of this interrupt.
First we estimate the time (fraction of a day) under the
assumption that the timing message arrived in zero time
*/

day = (int)msgTime;
tod = msgDiff + tick - day;

intTime = (double)day + tod;

/* This taken from the defunct setTimeStamp task */
gtimeStamp = tick + msgDiff;

} /* end (FOREVER loop) */

return;

} /* cmpTime */

jeanwelly wrote:
</pre>
<blockquote type="cite">
<pre wrap="">I would to see you ISR and the task code snippet to dig out the root
cause.


<a class="moz-txt-link-abbreviated" href="mailto:hichembf@xxxxxxxxx";>hichembf@xxxxxxxxx</a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi,
I am working on a product being developed on MVME162, using VxWorks 5.4
on MC68040.
I am using binary semaphores to sync between interrupts and tasks and I
am seeing a strange behavior.
It is hard to explain but this is the symptom: the semFlush are not
seen and therefore the task doesn't run. I am 100% sure that the
interrupt did happen.
What makes it stranger is that when I added an Idle task (that just
increments a counter) at priority 255, I don't notice the missed
semFlush anymore and the number of executions of the task matches the
number of interrupts.
I keep thinking this can't be right. I tried different experiments
and this was the only conclusion.

I appreciate if someone has idea/input on the issue.

Thanks,

Ben
</pre>
</blockquote>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
<br>
</body>
</html>

--------------030405060305060000010202--

.

Relevant Pages

  • Re: how to minimize interrupt latency using interrupt affinity in
    ... it would be VERY useful if the CPU or ISR ... one can see nested interrupts etc). ... my ISR runs on a processor core which is not ever used by other ISRs: ... even though I set affinity to 0x3 for all drivers ...
    (microsoft.public.development.device.drivers)
  • Re: how to minimize interrupt latency using interrupt affinity in
    ... it would be VERY useful if the CPU or ISR usage ... one can see nested interrupts etc). ... used by other drivers' interrupts and that only core 3 is used by my ISR. ...
    (microsoft.public.development.device.drivers)
  • Re: arm-elf-gcc building erroneous code for ISR (long posting)
    ... > example from Keil which should demonstrate the use of interrupts and of ... > essentially an empty loop now) and simply let the timer ISR toggle a LED ... > suspect a bug in gcc. ... this include the correct subs pc,lr,#4 that performs a return from interrupt ...
    (comp.arch.embedded)
  • Re: semtake function in ISR
    ... ISR, but upon closer inspection, it is being called from task-level. ... including whether interrupts are enabled or disabled. ... TaskA gets the semaphore and continues chugging along, ... If you are a newbie to VxWorks, here are the reasons why semTake ...
    (comp.os.vxworks)
  • Nested interrupts & semFlush
    ... During my debugging, I noticed that whenever there is nested ... the semaphore given by semFlush is not seen by the blocking ... Is it possible to tell what interrupts are happening? ...
    (comp.os.vxworks)