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

[Lukas Winterhalter]

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
2A3C sleeper8   64 SLP 0000 2EB2 2A1C   992 OK
261F sleeper7   64 SLP 0000 2E9E 25FF   992 OK
2202 sleeper6   64 SLP 0000 2F02 21E2   992 OK
1DE5 sleeper5   64 SLP 0000 2EDA 1DC5   992 OK
19C8 sleeper4   64 SLP 0000 2E8A 19A8   992 OK
15AB sleeper3   64 SLP 0000 2E76 158B   992 OK
118E sleeper2   64 SLP 0000 2EC6 116E   992 OK
0D71 sleeper1   64 SLP 0000 2F16 0D51   992 OK
093B main       64 SLP 0238 0000 087F   580 OKSIGNALED
061E idle      254 RDY 0453 0000 0602   356 OK 2E59 061E
Addr Ticks  Left Callback
2EC6     0    22 NutThreadWake(118E)
2EEE     0     1 NutThreadWake(1DE5)
2F16     0     1 NutThreadWake(0D71)
2F02     0     3 NutThreadWake(2202)
2E76     0     3 NutThreadWake(15AB)
2E8A     0     2 NutThreadWake(19C8)
2E9E     0     1 NutThreadWake(261F)
2EB2     0     2 NutThreadWake(2A3C)

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

Cheers
Lukas

Lukas Winterhalter wrote:
> Hi,
> 
> I posted about these problems in the BTnut list already. Now I've 
> removed all BTnut specific code from the two attached test apps. They 
> are plain Nut/OS now and produce still the same errors. (Running on 
> Atmega128L CPU (BTnode3))
> 
> crash_timers: ########################
> 
> - two worker threads that synhronize each other with
> NutEventPost/NutEventWait
> 
> - a sleeper thread that sleeps all the time
> - terminal thread
> 
> PROBLEM:
> NutDumpTimerList() prints out garbage.
> 
> REPRODUCE:
> 1. just start the crash_timers app
> 
> crash_termthread: ########################
> - sleeper threads
> - terminal thread
> 
> PROBLEM:
> main thread (terminal) enters sleep mode and never wakes up. Argh!
> 
> REPRODUCE:
> send a text file (20-100KB) over your terminal program. This
> generates output of the form:
> 
> LINE 178
> LINE 179
> LINE 180
> LINE 181
> 
> After a short time (some seconds) this output gets interrupted suddenly 
> while still receiving text data. The status thread will still print the 
> thread table every 5 seconds. it will now
> print something like this:
> 
> Hndl Name     Prio Sta QUE  Timr StkP FreeMem
> 2DDE status     64 RUN 0294 0000 2DBE   992 OK 2DDE 0457
> 29C1 sleeper8   64 SLP 0000 2E5F 29A1   992 OK
> 25A4 sleeper7   64 SLP 0000 2E0F 2584   992 OK
> 2187 sleeper6   64 SLP 0000 2E87 2167   992 OK
> 1D6A sleeper5   64 SLP 0000 2E73 1D4A   992 OK
> 194D sleeper4   64 SLP 0000 2E37 192D   992 OK
> 1530 sleeper3   64 SLP 0000 2DFB 1510   992 OK
> 1113 sleeper2   64 SLP 0000 2E5F 10F3   992 OK
> 0CF6 sleeper1   64 SLP 0000 2E23 0CD6   992 OK
> 0774 main       64 SLP 01F7 0000 06BC   584 OK
> 0457 idle      254 RDY 0294 0000 043B   356 OK 2DDE 0457
> Addr Ticks  Left Callback
> 2DFB     0    46 NutThreadWake(1530)
> 2E0F     0     2 NutThreadWake(25A4)
> 2E23     0     0 NutThreadWake(0CF6)
> 2E37     0     4 NutThreadWake(194D)
> 2E4B     0     1 NutThreadWake(1113)
> 2E5F     0     0 NutThreadWake(29C1)
> 2E73     0     1 NutThreadWake(1D6A)
> 2E87     0     2 NutThreadWake(2187)
> 
> Notice that colon 'QUE' (waiting queue) has a
> nonzero entry for thread 'main', however its contents are not shown on
> the right side after the 'FreeMem' colon???
> 
> ######################################
> 
> Perhaps these two bugs have the same origin. I suspect that something is 
> wrong with timers and/or events.
> 
> Regards,
> Lukas Winterhalter