<div dir="ltr"><div dir="ltr">Hi Catalin,<div><br></div><div>Please also make sure that the clock ISR is installed via rtems_interrupt_handler_install().</div><div>Actually, in order to check whether scheduler works well, you can set a break point at clock ISR or keep track of 'tick' variable. I think that your USB ISR does not complete and further blocks normal tick ISR (or clock ISR). Please verify the hardware interrupt flag register to see if the corresponding bit is cleared.</div><div><br></div><div>Best luck,</div><div>Mingyu</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">2018-09-19 20:46 GMT+08:00 Catalin Demergian <span dir="ltr"><<a href="mailto:demergian@gmail.com" target="_blank">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 dir="ltr">Hi,<div>thank you for answering !</div><div><br></div><div>I am using my own queues and rtems_event_send to notify my kernel task from the USB ISR that a new packet arrived.</div><div>I found an interesting field in the TCB structure</div><div><div><br></div><div> /** This field is the amount of CPU time consumed by this thread</div><div> * since it was created.</div><div> */</div><div> Thread_CPU_usage_t cpu_time_used;</div></div><div><br></div><div>I added a new shell cmd to print this info after my kernel thread gets stuck and I don't see this field changing at all !</div><div><b>Could this mean that my task is not scheduled anymore ?</b> </div><div>by printing other values I can see that the task is in ready state and the USB event is set. Also, the shell confirms this also</div><div>in the output of <b>task </b>command. </div><div>If the task is in ready state, why doesn't it run ?</div><div><br></div><div><pre style="white-space:pre-wrap;color:rgb(0,0,0)">Is the isr handler installed using an RTEMS interrupt service or is it a
raw hardware vector?
</pre>I installed the ISR myself like this</div><div><p class="MsoNormal" style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><span lang="EN-US"> //
USB related initializations</span></p>
<p class="MsoNormal" style="margin:0cm 0cm 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><span lang="EN-US">
_ARMV7M_Set_exception_<wbr>priority_and_handler(ARMV7M_<wbr>VECTOR_IRQ(STM32F7_IRQ_OTG_FS)<wbr>,
BSP_ARMV7M_IRQ_PRIORITY_<wbr>DEFAULT, USB_OTG_Handler);</span></p></div><div>I am sure that the ISR is entered after the kernel task gets stuck.</div><div><br></div><div><br></div><div>regards,</div><div>Catalin</div></div><div><div class="h5"><br><div class="gmail_quote"><div dir="ltr">On Wed, Sep 19, 2018 at 5:58 AM Mingyu Li <<a href="mailto:lmy2010lmy@gmail.com" target="_blank">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><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">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>______________________________<wbr>_________________<br>
users mailing list<br>
<a href="mailto:users@rtems.org" target="_blank">users@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.rtems.org/<wbr>mailman/listinfo/users</a><br></blockquote></div><br></div>
</blockquote></div></div></div></div>
</blockquote></div><br></div>