[En-Nut-Discussion] Serial Lockup [SOLVED, OS BUG FOUND]

Tim DeBaillie debaillie at ciholas.com
Thu May 8 23:06:47 CEST 2008


So I traced this one down.  There is a line in the AT91SAM7X data sheet 
that says you should NOT use edge sensitive interrupts for the USART 
devices.  Once you switch it to a low level sensitive interrupt you can 
operate at the true baud rate.

The interesting thing is that I was unable to execute the command 
"NutIrqSetMode(&sig_UART0, NUT_IRQMODE_LOWLEVEL);" and have it cause any 
affect.  I had to use "outr(AIC_SMR(US0_ID), 0x04);" to get it to take.

It should be known that the USART interrupt handles two interrupts (TX and 
RX) so it is VERY possible that a byte can come in while you are 
processing the a byte on the TX.  This means that when you exit the 
interrupt the interrupt is not cleared and therefore you never release 
your level (meaning you can't catch the next edge).  So you never 
interrupt again.

So the OS should by default set the sig_UART0 and sig_UART1 interrupts to 
be level sensitive.  Someone with higher power than I should implement 
this into the OS.

Thanks,
Tim

On Thu, 8 May 2008, Harald Kipp wrote:

> Tim DeBaillie wrote:
>> Has anyone had any issues with a serial port file descriptor closing due
>> to lots of data at the baud rate being received.
> ...
>> Some things we have considered are changing the fgetc into an fgets or
>> fread.  However it shouldn't matter because the OS serial port interrupt
>> should handle this even if we don't read quick enough right?
>
> Only a vague comment: The AT91 USART drivers may not have been tested
> extensively on the SAM7X, just quickly ported and found working. I'd
> assume a problem in the lowest driver level.
>
> Looking to the higher level: How do you know, that fgetc returns EOF
> because of a closed handle and not because of a USART error? See feof()
> and ferror().
>
> You're assumption about interrupt handling is correct. The application
> doesn't need to be fast.
>
> Harald
>
> _______________________________________________
> http://lists.egnite.de/mailman/listinfo/en-nut-discussion
>




More information about the En-Nut-Discussion mailing list