<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Hi,<div>I still think it would be worth to try the latest RTEMS master just to <br>make sure we don't search a bug which is already fixed. Also RTEMS 5 has <br>more assertions in the debug configuration. </div><div>-> is RTEMS 5 stable branch or development ? </div><div>-> what is the link for RTEMS master (where to do a git clone from) ?</div><div><br></div><div>I have a theory of what may be going on, please let me know if you think it's valid.</div><div>1. let's say Wait.flags = THREAD_WAIT_CLASS_EVENT | THREAD_WAIT_STATE_INTEND_TO_BLOCK</div><div> and state = STATES_WAITING_FOR_EVENT because they are set this way in _Event_Seize</div><div>2. USB ISR arrives, so we go in _Event_Surrender where</div><div><div> success = _Thread_Wait_flags_try_change_critical(</div><div> the_thread,</div><div> wait_class | THREAD_WAIT_STATE_INTEND_TO_BLOCK,</div><div> ready_again</div><div> );</div></div><div> will return TRUE, because the expected flags was intend to block, so Wait.flags will become THREAD_WAIT_CLASS_EVENT | THREAD_WAIT_STATE_READY_AGAIN</div><div>3. _Event_Seize continues execution with</div><div> success = _Thread_Wait_flags_try_change(</div><div> executing,</div><div> intend_to_block,</div><div> wait_class | THREAD_WAIT_STATE_BLOCKED</div><div> );</div><div> and success will be FALSE because Wait.flags is not THREAD_WAIT_STATE_INTEND_TO_BLOCK anymore, so _Thread_Unblock will get called</div><div> and eventually _States_Clear will put state = STATES_READY.</div><div>4. _Thread_Dispatch_enable will be called in _Event_Seize, but another task is selected to run (I have 4 tasks with the same priority, my task doesn't have a smaller</div><div> priority, it's not necessarily made the heir task)</div><div>5. Another USB ISR arrives; this time we enter _Event_Surrender with</div><div> state = STATES_READY and Wait.flags = THREAD_WAIT_CLASS_EVENT | THREAD_WAIT_STATE_READY_AGAIN,</div><div> so we go on the else branch, setting unblock = FALSE, not calling _Thread_Unblock from _Event_Surrender.</div><div>6. basically no matter how many USB ISRs will arrive, the same scenario from step 5 repeats ... no one will call _Thread_Unblock for SCrx again !</div><div> Also, when entering task command in the shell it shows the task as ready (because it is) and the USB event set.</div><div><br></div><div>regards,</div><div>Catalin</div><div> <br></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Oct 12, 2018 at 12:13 AM Sebastian Huber <<a href="mailto:sebastian.huber@embedded-brains.de">sebastian.huber@embedded-brains.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 11/10/2018 15:37, Catalin Demergian wrote:<br>
> Hi,<br>
> Yes, there is a call to rtems_task_wake_after in the code; but in that <br>
> case state should have been STATES_DELAYING, right ?<br>
<br>
The<br>
<br>
state = 0x0 = STATES_READY<br>
Wait.flags = 0x02 = THREAD_WAIT_STATE_BLOCKED<br>
<br>
looks suspicious. It should be<br>
<br>
state = 0x0 = STATES_READY<br>
Wait.flags = 0x04 = THREAD_WAIT_STATE_READY_AGAIN<br>
<br>
after a call to _Thread_Timeout(),<br>
<br>
> At another run, I got<br>
> state = 0x0 = STATES_READY<br>
> Wait.flags = 0x104 = THREAD_WAIT_CLASS_EVENT | <br>
> THREAD_WAIT_STATE_READY_AGAIN<br>
> Why would the state be ready in _Event_Seize ? could that value be <br>
> corrupt ?<br>
><br>
> I tried with the stack checker as well, but I didn't see any out of <br>
> band values.<br>
<br>
Ok, good.<br>
<br>
I still think it would be worth to try the latest RTEMS master just to <br>
make sure we don't search a bug which is already fixed. Also RTEMS 5 as <br>
more assertions in the debug configuration.<br>
<br>
-- <br>
Sebastian Huber, embedded brains GmbH<br>
<br>
Address : Dornierstr. 4, D-82178 Puchheim, Germany<br>
Phone : +49 89 189 47 41-16<br>
Fax : +49 89 189 47 41-09<br>
E-Mail : <a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a><br>
PGP : Public key available on request.<br>
<br>
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.<br>
<br>
</blockquote></div>