vxWorks Message queue send fails?
Bill Pringlemeir
Host: NT4.0, sp6, Tornado 2.0.1
Target : ARMARCH3, vxWorks 5.4
I have searched the Usenet archives for posts on message queues. One
issue I have is that WindView always shows the same data for a message
queue.
priority=""
timeout=""
bufSize=""
buffer=""
msgQId=0xdecd80
All msgQSend have this type of information, but the messages queues
definitely have data if I print them out. This is just a side issue.
My main problem is that the "msgQReceive" seems to wake up and
immediately go back to waiting. It doesn't appear to come back to the
waiting task as break points aren't hit. There was an interrupt that
occurred and this is code that unconditionally send to the message
queue.
// Message queue constants.
typedef unsigned char msgq_type;
static const unsigned int msgq_size = 10;
static const msgq_type msgq_receive_tmo = 'r';
static const msgq_type msgq_receive = 'R';
static void cnsReadWdog(CNS_CHAN * pChan)
{
msgQSend (pChan->msgQ, (char *)&msgq_receive_tmo, sizeof(msgq_receive_tmo),
NO_WAIT, MSG_PRI_NORMAL);
}
This is a watchdog routine and I also see that the routine is executed
at the given timeout. However, WindView doesn't show a msgQSend event
and a break point in the task is not hit (even an error). I am also
seeing strange behavior in another message with a completely
different task and interrupt handler.
I did see one post that seemed to indicate that the posix message
queue's have some sort of problem with taskDelay. The WindSurf SPR
list seems to be full of SPRs for the Posix message queue's, but these
are the WindRiver message queues. I did mix the priority values for
the message queue. Ie, some other msgQSend use "MSG_PRI_URGENT".
This one always seems to work.
static void cnsInt(CNS_CHAN * pChan)
{
msgQSend (pChan->msgQ, (char *)&msgq_receive, sizeof(msgq_receive),
NO_WAIT, MSG_PRI_URGENT);
}
The message queue's are not full. The interrupts are low frequency
and the task has a while loop which reads from the message queue. I
have only ever seen a single read and then it pends. Also, the tw on
the object doesn't indicate anything odd.
-> show 0xdecd80
Message Queue Id : 0xdecd80
Task Queueing : FIFO
Message Byte Len : 1
Messages Max : 10
Messages Queued : 0
Receivers Blocked : 1
Send Timeouts : 0
Receive Timeouts : 0
The system is put in a power down / sleep mode. All interrupts are
turned off (including the system timer). The only thing that can wake
the device is a key press. That particular logic has been in the
application for a long time. The message queue stuff is new.
thanks for any help or suggestions,
Bill Pringlemeir.
--
Two wrongs don't make a right, but three lefts do.
FAQ - "http://www.xs4all.nl/~borkhuis/vxworks/vxworks.html"
Wiki - "http://www.bluedonkey.org/cgi-bin/twiki/bin/view/Books/VxWorksCookBook"
John
> My main problem is that the "msgQReceive" seems to wake up and
> immediately go back to waiting. It doesn't appear to come back to the
> waiting task as break points aren't hit. There was an interrupt that
> occurred and this is code that unconditionally send to the message
> queue.
>
> // Message queue constants.
> typedef unsigned char msgq_type;
> static const unsigned int msgq_size = 10;
> static const msgq_type msgq_receive_tmo = 'r';
> static const msgq_type msgq_receive = 'R';
>
> static void cnsReadWdog(CNS_CHAN * pChan)
> {
> msgQSend (pChan->msgQ, (char *)&msgq_receive_tmo, sizeof(msgq_receive_tmo),
> NO_WAIT, MSG_PRI_NORMAL);
> }
Two ideas here:
1) Have you checked for errors returned by msgQSend()?
2) Have you tried sending messages that are multiples of a word in
size (e.g. one integer instead a single character)?
> I did see one post that seemed to indicate that the posix message
> queue's have some sort of problem with taskDelay. The WindSurf SPR
> list seems to be full of SPRs for the Posix message queue's, but these
> are the WindRiver message queues. I did mix the priority values for
> the message queue. Ie, some other msgQSend use "MSG_PRI_URGENT".
> This one always seems to work.
>
> static void cnsInt(CNS_CHAN * pChan)
> {
> msgQSend (pChan->msgQ, (char *)&msgq_receive, sizeof(msgq_receive),
> NO_WAIT, MSG_PRI_URGENT);
> }
The difference is that it gets pushed on the other end of the queue.
Sounds like there might be an issue with the pointer management. Given
that this is an ARM, and unaligned accesses are a little funky on ARM,
I would make sure that you send multiples of 32 bit words. Shouldn't
be any slower, and it might even be faster.
> The message queue's are not full. The interrupts are low frequency
> and the task has a while loop which reads from the message queue. I
> have only ever seen a single read and then it pends. Also, the tw on
> the object doesn't indicate anything odd.
>
> -> show 0xdecd80
>
> Message Queue Id : 0xdecd80
> Task Queueing : FIFO
> Message Byte Len : 1
> Messages Max : 10
> Messages Queued : 0
> Receivers Blocked : 1
> Send Timeouts : 0
> Receive Timeouts : 0
Sounds like there is something preventing msgQSend() from sending. I
would certainly check for an ERROR return (and if so, cache the errno
value somewhere you can look at it).
HTH,
John...
=====
Contribute to the VxWorks Cookbook at:
http://www.bluedonkey.org/cgi-bin/twiki/bin/view/Books/WebHome
Michael Lawnick
"Bill Pringlemeir" <spam_a...@sympatico.ca> schrieb im Newsbeitrag
news:m2d6hjm...@sympatico.ca...
>
> Host: NT4.0, sp6, Tornado 2.0.1
> Target : ARMARCH3, vxWorks 5.4
>
> I have searched the Usenet archives for posts on message queues. One
> issue I have is that WindView always shows the same data for a message
> queue.
exemplary !
I know, you aren't a newbie, but you are searching for an error/bug. So:
> static void cnsReadWdog(CNS_CHAN * pChan)
> {
> msgQSend (pChan->msgQ, (char *)&msgq_receive_tmo,
sizeof(msgq_receive_tmo),
> NO_WAIT, MSG_PRI_NORMAL);
> }
You don't check for error return (logMsg)
>
> This is a watchdog routine and I also see that the routine is executed
> at the given timeout. However, WindView doesn't show a msgQSend event
> and a break point in the task is not hit (even an error).
What's about using wvEvent for tracing if debugger's breakpoints aren't hit?
I don't know for ARM, but my expierence for x86 and PPC is that almost every
time WV shows the truth - except some system tick interrupt timing issues.
So if the msgQSend is not shown, you should assume it has not happend (see
above: error return).
Regards,
Michael
--
21 is only half the truth.
Bill Pringlemeir
"Bill Pringlemeir" <spam_a...@sympatico.ca> schrieb...
> Host: NT4.0, sp6, Tornado 2.0.1
> Target : ARMARCH3, vxWorks 5.4
>
> This is a watchdog routine and I also see that the routine is
> executed at the given timeout. However, WindView doesn't show a
> msgQSend event and a break point in the task is not hit (even an
> error).
On Fri, 13 Jun 2003, michael.lawnick@no_spam_pls.kontron.com wrote:
> What's about using wvEvent for tracing if debugger's breakpoints
> aren't hit? I don't know for ARM, but my expierence for x86 and PPC
> is that almost every time WV shows the truth - except some system
> tick interrupt timing issues. So if the msgQSend is not shown, you
> should assume it has not happend (see above: error return).
There are other occasions where I see the msgQSend and the task wakes
up, but a break point is not hit. I think I will follow Johns advice.
It is probably weird to use a "char". I just wanted a "semaphore"
from multiple source (also called an event) to wake up the task.
There is no information to be communicated from the interrupts (and
timer). Just the fact that they happened.
For Tornado 2.0.1 on the ARM, WindView seems to have numerous bugs.
For instance, configuring the kernel for non-preemptable interrupts
will cause the parser to crash. I am quite sure that the events
aren't shown in some cases (my target uses WDB over TCP/IP with PPP).
Tasks are rescheduled and the only thing to cause this would be a
semaphore, msgQ, etc.
I will get a return from the msgQSend first. Then I will try an
'int'. It will only take a little more memory. Anyways, I will get
back in any case.
Thanks,
Bill Pringlemeir.
--
Keep an open mind. But not so open your brains fall out.
- Kallis' Law