rtems_message_queue_receive / rtems_event_receive issues
Mingyu Li
lmy2010lmy at gmail.com
Wed Sep 19 15:46:13 UTC 2018
Hi Catalin,
Please also make sure that the clock ISR is installed
via rtems_interrupt_handler_install().
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.
Best luck,
Mingyu
2018-09-19 20:46 GMT+08:00 Catalin Demergian <demergian at gmail.com>:
> 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 <lmy2010lmy at 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 <demergian at 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 at rtems.org
>>> http://lists.rtems.org/mailman/listinfo/users
>>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20180919/5db13b46/attachment.html>
More information about the users
mailing list