<div dir="ltr">Hi,<div>I'm using <span style="color:rgb(0,0,0);white-space:pre-wrap">rtems_interrupt_handler_install now, the issue is the same.</span></div><div><span style="color:rgb(0,0,0);white-space:pre-wrap">Let me provide some context.</span></div><div><span style="color:rgb(0,0,0);white-space:pre-wrap"><br></span></div><div><span style="color:rgb(0,0,0);white-space:pre-wrap">I use an IP layer (SLIP protocol) above the USB so datagrams can flow over USB.</span></div><div><span style="color:rgb(0,0,0);white-space:pre-wrap">I'm sending ping packets in loop in a </span><span style="color:rgb(0,0,0);white-space:pre-wrap">long duration test. After 1/2/3 hours (it varies),</span></div><div><span style="color:rgb(0,0,0);white-space:pre-wrap">I don't reply to ping anymore, but I already established that it isn't because of the USB code,</span></div><div><span style="color:rgb(0,0,0);white-space:pre-wrap">but the USB code is not called anymore because the kernel task that processes the packets</span></div><div><span style="color:rgb(0,0,0);white-space:pre-wrap">is not scheduled anymore by RTEMS.</span></div><div><span style="color:rgb(0,0,0);white-space:pre-wrap"><br></span></div><div><span style="color:rgb(0,0,0);white-space:pre-wrap">I looked at the tick variable, it's incremented after my USB kernel task hangs. Also, I have other</span></div><div><span style="color:rgb(0,0,0);white-space:pre-wrap">tasks in my system and they are scheduled well. The only task in READY state that is not scheduled is my task.</span></div><div><span style="color:rgb(0,0,0);white-space:pre-wrap">The USB ISR copies 64 bytes in a circular buffer and call rtems_event_send every time; it works for hours without</span></div><div><span style="color:rgb(0,0,0);white-space:pre-wrap">affecting the scheduler. If the scheduler was affected, the SHELL task couldn't be scheduled anymore and I couldn't</span></div><div><span style="color:rgb(0,0,0);white-space:pre-wrap">enter shell commands.</span></div><div><span style="color:rgb(0,0,0);white-space:pre-wrap"><br></span></div><div><span style="color:rgb(0,0,0);white-space:pre-wrap">Could it be possible that for some reason the scheduler starts considering my task soft real-time and treats it differently ?</span></div><div><span style="color:rgb(0,0,0);white-space:pre-wrap">let's say it decides to schedule it when it has time, but the other tasks remain hard real-time and schedules them, without</span></div><div><span style="color:rgb(0,0,0);white-space:pre-wrap">scheduling my own task anymore ?</span></div><div><span style="color:rgb(0,0,0);white-space:pre-wrap"><br></span></div><div><span style="color:rgb(0,0,0);white-space:pre-wrap">I'm asking because I'm no expert in RTEMS, I don't know how the scheduler works, I just did the USB integration in RTEMS 4.11.2</span></div><div><span style="color:rgb(0,0,0);white-space:pre-wrap">on a STM32F7. Can you provide some pointers like where to look in the code for this kind of stuff? I mean the scheduler logic.. and I'll continue from there</span></div><div><br></div><div>regards,</div><div>Catalin</div><div><br></div></div><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">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>_______________________________________________<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/mailman/listinfo/users</a><br></blockquote></div><br></div>
</blockquote></div>