[En-Nut-Discussion] Re: [btnode-development] Re: Nut errors!?

[Matthias Ringwald]

HI Lukas,

I did already suspect that the main thread did not show 'signaled'  
only because of the usart driver.

The question is now, how did the thread get signaled but not moved to  
the ready-to-run queue.

I guess it is signaled from the USART driver by means of  
NutPostEventFromIrq.
checking the event.c code, I see, that if the thread is waiting in  
the queue, it will
be put to the readyQueue (and should be woken) up. The  
NutThreadResume code looks solid.

So the more likely option would be that the queue is signaled before  
NutEventPostFromIrq is called.
Hm. this sounds weird, I do agree.

Could you somehow check, if NutEventWait, NutEventPostFromIrq and  
NutThreadResume work on this specific
queue?

I'll have a deeper look on this later.
Did you use timeouts for the uarts ?

matthias



On 11.07.2005, at 14:30, Lukas Winterhalter wrote:

> Hi all,
>
> I tried the crash_termthread example with the uart driver instead  
> of the usart driver. The main thread gets blocked again quickly,  
> but the output was slightly different:
>
> Hndl Name     Prio Sta QUE  Timr StkP FreeMem
> 2E59 status     64 RUN 0453 0000 2E03   938 OK 2E59 061E
> ..
> 093B main       64 SLP 0238 0000 087F   580 OKSIGNALED
> 061E idle      254 RDY 0453 0000 0602   356 OK 2E59 061E
> ..
>
> Note that the main threads wait queue is marked 'SIGNALED' while  
> still being not in ready queue. As far as I understand it this  
> _should_ not be possible??
>
>