rtems_message_queue_receive / rtems_event_receive issues

[Catalin Demergian]

Hi,
This assert may not be directly related to my issue because I reproduced it
a few times (with RTEMS_DEBUG enabled in the build)
without seeing the assert being hit. What I discovered is that after a
while _Scheduler_priotity_Unblock is not called for my task anymore.
And since _Scheduler_priotity_Unblock calls _Scheduler_Update_heir, my task
will not be set as the heir and no context switch will be made for it.

My question is why would _Scheduler_priority_Unblock not beeing called ?
rtems_event_send called from my USB ISR calls _Event_Surrender and that
calls _Thread_Unblock
Is there a conceptual problem calling rtems_event_send from an ISR ?
I saw there is a rtems_event_system_send function. should I call this one
instead ? what is the difference?

regards,
Catalin


On Mon, Oct 1, 2018 at 10:16 AM Sebastian Huber <
sebastian.huber at embedded-brains.de> wrote:

> On 01/10/2018 08:55, Catalin Demergian wrote:
> > Hello,
> > After enabling RTEMS_DEBUG like you told me, I found the test I left
> > running over the weekend like this
> >
> > [/] #
> >
> > [/] #
> >
> > [/] # assertion "first != _Chain_Tail( &ready_queues[ index ] )"
> > failed: file
> >
> "../../cpukit/../../../stm32f7/lib/include/rtems/score/schedulerpriorityimpl.h",
>
> > line 166, function: _Scheduler_priority_Ready_queue_first
> >
>
> This means that the scheduler tries to use the first thread of an empty
> ready queue. Someone corrupted the scheduler data structures. This could
> be a general scheduler bug, a heap corruption, a stack overflow, some
> arbitrary memory corruption.
>
> Which RTEMS 4.11 release do you use exactly?
>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax     : +49 89 189 47 41-09
> E-Mail  : sebastian.huber at embedded-brains.de
> PGP     : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20181002/58343529/attachment-0002.html>