rtems_message_queue_receive / rtems_event_receive issues

[Catalin Demergian]

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 <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/bbf8f8be/attachment-0002.html>