rtems_message_queue_receive / rtems_event_receive issues

[Catalin Demergian]

Hi,
I'm using
#define BSP_ARMV7M_IRQ_PRIORITY_DEFAULT (13 << 4)
13*16=208 > 0x80=128, so I should be on the safe side.

what do you mean by operating system services ? like rtems_event_send in
ISR ?
is there other way to handle USB data other than copy data in a buffer in
ISR and signal a kernel
task (that is doing rtems_event_receive) with a rtems_event_send call ?

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/20180920/a99c6c87/attachment.html>