<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr">On Tue, Sep 18, 2018, 9:59 PM Mingyu Li <<a href="mailto:lmy2010lmy@gmail.com">lmy2010lmy@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Hi Catalin.</div><div dir="ltr"><br></div><div>I find the problem you encountered interesting. I hope to offer some hints that might be helpful to you:</div><div><br></div><div>1. use a user task to first rtems_event_send then rtems_event_receive, in order to make sure the internal IPC of RTEMS kernel you are using (4.11.2) works as expected.</div><div>2. ensure to disable/lock interrupts while operating the message_queue <span style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">inside USB ISR</span>. Try to check if clock ISR is still responded when USB ISR exits, so that the kernel task can be scheduled to obtain the message.</div></div></div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Is the isr handler installed using an RTEMS interrupt service or is it a raw hardware vector?</div><div dir="auto"><br></div><div dir="auto">--joel</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><br></div><div>Best regards,</div><div>Mingyu</div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">2018-09-18 20:20 GMT+08:00 Catalin Demergian <span dir="ltr"><<a href="mailto:demergian@gmail.com" target="_blank" rel="noreferrer">demergian@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hello,</div><div>I am using RTEMS 4.11.2 and I tried first to use RTEMS message queues in my USB FS driver.</div><div>I'm populating the queue from the ISR and then use rtems_message_queue_receive from a kernel task to</div><div>read the messages. After some debugging sessions I came to the conlusion that rtems_message_queue_receive function</div><div>hangs even if there are messages in the queue. (manpage says it should return immediately if there is at least one message</div><div>in the queue; in my case the queue gets full, but still the function hangs)</div><div><br></div><div>I tried then rtems_event_receive. I used my own queues and from ISR I only called rtems_event_send; the same issue</div><div>happened again, this time rtems_event_receive hangs even if I see the event was raised (with task command in the shell)</div><div><br></div><div>My question is: are there any known issues/bugs with these functions ? </div><div><br></div><div>thanks,</div><div>Catalin</div></div>
<br>_______________________________________________<br>
users mailing list<br>
<a href="mailto:users@rtems.org" target="_blank" rel="noreferrer">users@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/users" rel="noreferrer noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/users</a><br></blockquote></div><br></div>
_______________________________________________<br>
users mailing list<br>
<a href="mailto:users@rtems.org" target="_blank" rel="noreferrer">users@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/users" rel="noreferrer noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/users</a></blockquote></div></div></div>