rtems_message_queue_receive / rtems_event_receive issues

[Sebastian Huber]

On 04/10/2018 15:33, Catalin Demergian wrote:
> I eliminated the theory of memory corruption. I debugged and found we 
> set Wait.flags = 0x104 with a function call.
> The USB interrupt can arrive at any time, so Wait.flags can be either 
> INTEND_TO_BLOCK, BLOCKED or READY_AGAIN.
>
> Following the logic in _Event_Surrender:
> If it arrives when Wait.flags = INTEND_TO_BLOCK

Are the flags == 0x101? In this case the thread is in the middle of 
_Event_Seize()

> then _Thread_Wait_flags_try_change_critical will return TRUE, 
> Wait.flags will be set to READY_AGAIN,
> unblock = FALSE so _Thread_Unblock will not be called.

The unblock is done in _Event_Seize() in this case:

   success = _Thread_Wait_flags_try_change_acquire(
     executing,
     intend_to_block,
     wait_class | THREAD_WAIT_STATE_BLOCKED
   );

The success == false in this case.

> Then all the other USB interrupts will catch Wait.flags = READY_AGAIN 
> and in this case_Event_Surrender doesn't do anything because unblock = 
> FALSE
>
> .. so the task never runs again, but state remains marked as READY.
> is this a bug ? or I'm not understanding correctly?

There could be a synchronization issue with the wait flag or the 
interrupt disable/enable sequence.

There was a severe bug on the ARMv7-M in this area, but it is fixed in 
the 4.11.2 release:

https://git.rtems.org/rtems/commit/?h=4.11&id=7e91901303219f10cf865906931c07c31d2e37f4

-- 
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.