Hi, thank you for answering ! I am using my own queues and rtems_event_send to notify my kernel task from the USB ISR that a new packet arrived. I found an interesting field in the TCB structure
/** This field is the amount of CPU time consumed by this thread * since it was created. */ Thread_CPU_usage_t cpu_time_used; 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 ! *Could this mean that my task is not scheduled anymore ?* 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 in the output of *task *command. If the task is in ready state, why doesn't it run ? Is the isr handler installed using an RTEMS interrupt service or is it a raw hardware vector? I installed the ISR myself like this // USB related initializations _ARMV7M_Set_exception_priority_and_handler(ARMV7M_VECTOR_IRQ(STM32F7_IRQ_OTG_FS), BSP_ARMV7M_IRQ_PRIORITY_DEFAULT, USB_OTG_Handler); I am sure that the ISR is entered after the kernel task gets stuck. 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
