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.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
users mailing list
users@rtems.org
http://lists.rtems.org/mailman/listinfo/users
