[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