Strange problem with semFlush/semTake

[hich...@gmail.com]

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

[manimuthukumar]

hi
can U explain this line "semFlush are not seen and therefore the task
doesn't run ".

have U checked the interrupt duration if ISR able to run a dummy task
and not running the task means check the duration of the TASK and
occurence of the interrupt.
i think
muthu

[hich...@gmail.com]

Thanks for your input.

I meant to say that although the semaphore is given inside the ISR, the
task some times it does not run or somehow the scheduler does not
recognize that the task is ready to run waiting in the semphore.

The ISR last 50 us and the task takes about 600 us. The ISR is invoked
every 52 ms. I logged the interrupt times and it is very stable at 52ms
period. I tried a dummy task but the behavior is identical!

This probem is so weird it is shaking my trust in VxWorks

Thanks,

Ben

[ranga....@gmail.com]

Should not be the case what you are talking. Most of the ethernet
device drivers depend on same concept. Then you would never able to
ping the device if what you are saying is correct. Checkout the task
priorities and what other tasks are existing and what their priorities
are ? Checkout scheduling method ? is that FIFO or RR ? May be WindView
is good tool to identify any starvation issues for your task

Ranga

[jeanwelly]

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

[jeanwelly]

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

[hich...@gmail.com]

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 */

[Michael R. Kesti]

hich...@gmail.com wrote:

Do you really need the semFlush() functionality or would a semGive() do?
Have you tried semGive()?

I see that you don't check the return value of semFlush(). Are you
certain that it isn't returning an error.

I know that neither of these would explain the better behaviour when you
include the dummy task, but they are things to consider and try, none the
less.

--
========================================================================
Michael Kesti | "And like, one and one don't make
| two, one and one make one."
mrkesti at hotmail dot com | - The Who, Bargain

[Sperry Family]

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?

[hich...@gmail.com]

Thanks for your help.
The reason I am using semFlush is because down the road 2 tasks, with
different priorities, will be waiting on this semaphore. I did a test
where I used semGive but no difference.
I had code to check the return of semFlush and there was not a singal
error. I removed it when I was certain that wasn't the cause.

Thanks again,

Ben

[hich...@gmail.com]

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

> --------------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:hich...@gmail.com">hich...@gmail.com</a> wrote:
> <blockquote
> cite="mid1153245345...@75g2000cwc.googlegroups.com"
> 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;

> </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:hich...@gmail.com">hich...@gmail.com</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--