[En-Nut-Discussion] UART Ethernut3 stop receiveing bytes after a while

[Alain M.]

Hi Martin,

There is a test that can help: send a predictable sequence, like 
sequential bytes. As you receive them, just check and discard, display 
only the result. It could be that you are really loosing something...

Alain

ml escreveu:
> Hi Alain,
> 
> thank you for the hint. i test it only with 19200 Bauds so it´s rather slow
> for such a fast cpu.
> the problem isn´t completely solved when i disable debugging feature - it
> only appears much later.
> maybe it´s an reentry problem. It doesn´t matter if i send the char back to
> the same uart or
> to another device like my lcd display. for now i can ignore the problem
> because i really not 
> need the echo, but i think that points to a problem in (nut/gcc or ?) and
> such kind of problems 
> will reapear later whe you never need them. I will try to find out the
> reason for this to avoid later 
> problems. 
> 
> Martin
> 
> 
> Alain M. wrote:
>> Hi Martin,
>>
>> even being new to Nut/OS, I am in the RS232 thing for a loooong time. I 
>> would bet that you are having re-entry problems. Let's say that because 
>> of the debug option, the next char gets delayed up to a point that the 
>> next will renter the last one or that the sending char overrides the 
>> last. This could lead to one interrupt accurring while the last is 
>> running and if not properly coded this can cause problems.
>>
>> You can try 2 things:
>> 1) run the same test at much lower speeds so that you can discard some 
>> bug related to the debug part, then repeat it at very high speed with no 
>> debug just to see if it happens too
>> 2) send a known sequence and test it at the receiver side, you can then 
>> split the problem between receiving/sending/debugging.
>>
>> Alain
>>
>> ml escreveu:
>>> Solved a bit :( 
>>>
>>> if i build nutos without debug infos all work´s well. for now it´s a
>>> solution, but i wonder how this happens.
>>> in debugger i can see that the irq is never called again but the
>>> register´s
>>> are set correctly. i test with 
>>> the UART-loop in a thread. The main thread is still running after the
>>> mistake. The debugger sometimes tries to reach a breakpoint but want´s to
>>> examine a memory-adress far behind the physical memory - seems to be
>>> random. 
>>>
>>> Martin
>>>
>>>
>>>
>>> ml wrote:
>>>> Hi,
>>>>
>>>> i run into a problem with uart. the small loop in the example produce an
>>>> echo at the 
>>>> uart. Uart is initialized in normal Mode without handshake and so on.
>>>> If i type in some characters in the terminalwindow all is ok. But if i
>>>> transmit short
>>>> strings from pc with full speed after a while the receiver isn´t working
>>>> anymore.
>>>> In debugger i can see that the sig_UART Interrupt is never called again.  
>>>>
>>>> when i put in the nutsleep instruction  it works for hours. 
>>>>
>>>>    NutRegisterDevice(&DEV_UART0, 0, 0); 
>>>>    com1 = fopen(DEV_UART_NAME, "r+b");
>>>>
>>>>    for(;;) {
>>>>   //   NutSleep(20);
>>>>      if ((c=fgetc(com1)) != EOF) {
>>>>        fputc(c,com1);
>>>>        fflush(com1);
>>>>      }
>>>>    }
>>>>
>>>> any help for this strange problem ?
>>>> ENUT 4.4.0  with Eclipse and openocd
>>>> Martin
>>>>
>> _______________________________________________
>> http://lists.egnite.de/mailman/listinfo/en-nut-discussion
>>
>>
>