Hi, 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 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. 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? regards, Catalin On Wed, Oct 3, 2018 at 2:42 PM Catalin Demergian <demerg...@gmail.com> wrote: > ok, I understand. The code in _Event_Is_blocking_on_event is correct, it > just verifies if the thread is in wait state or not. > The only thing that varies is what _Thread_Wait_flags_get returns. In my > case, it returned 0x102 for 5401 times, > but 5402th time it returned 0x104; because of that, ( wait_flags & > wait_mask ) == wait_class didn't hold true anymore. > 0x104 means the thread is ready .. why is marked as ready instead of > blocked is another problem. could it be a memory > corruption, possibly, but I doubt it, a memory corruption would set it > most likely to a value without meaning, but in my case it's > exactly 0x104. > I think one of the functions > _Thread_Wait_flags_set/_Thread_Wait_flags_try_change may set this value. > I will check this theory. > > regards, > Catalin > > >
_______________________________________________ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users