Hi, I'm using rtems_interrupt_handler_install now, the issue is the same. Let me provide some context.
I use an IP layer (SLIP protocol) above the USB so datagrams can flow over USB. I'm sending ping packets in loop in a long duration test. After 1/2/3 hours (it varies), I don't reply to ping anymore, but I already established that it isn't because of the USB code, but the USB code is not called anymore because the kernel task that processes the packets is not scheduled anymore by RTEMS. I looked at the tick variable, it's incremented after my USB kernel task hangs. Also, I have other tasks in my system and they are scheduled well. The only task in READY state that is not scheduled is my task. The USB ISR copies 64 bytes in a circular buffer and call rtems_event_send every time; it works for hours without affecting the scheduler. If the scheduler was affected, the SHELL task couldn't be scheduled anymore and I couldn't enter shell commands. Could it be possible that for some reason the scheduler starts considering my task soft real-time and treats it differently ? let's say it decides to schedule it when it has time, but the other tasks remain hard real-time and schedules them, without scheduling my own task anymore ? 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 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 regards, Catalin On Wed, Sep 19, 2018 at 5:58 AM Mingyu Li <lmy2010...@gmail.com> wrote: > Hi Catalin. > > I find the problem you encountered interesting. I hope to offer some hints > that might be helpful to you: > > 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. > 2. ensure to disable/lock interrupts while operating the message_queue inside > USB ISR. 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. > > Best regards, > Mingyu > > 2018-09-18 20:20 GMT+08:00 Catalin Demergian <demerg...@gmail.com>: > >> Hello, >> I am using RTEMS 4.11.2 and I tried first to use RTEMS message queues in >> my USB FS driver. >> I'm populating the queue from the ISR and then use >> rtems_message_queue_receive from a kernel task to >> read the messages. After some debugging sessions I came to the conlusion >> that rtems_message_queue_receive function >> hangs even if there are messages in the queue. (manpage says it should >> return immediately if there is at least one message >> in the queue; in my case the queue gets full, but still the function >> hangs) >> >> I tried then rtems_event_receive. I used my own queues and from ISR I >> only called rtems_event_send; the same issue >> happened again, this time rtems_event_receive hangs even if I see the >> event was raised (with task command in the shell) >> >> My question is: are there any known issues/bugs with these functions ? >> >> thanks, >> Catalin >> >> _______________________________________________ >> users mailing list >> users@rtems.org >> http://lists.rtems.org/mailman/listinfo/users >> > >
_______________________________________________ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
