Hi Josef,
minicom -o
will stop the AT commands being issued.
I would fix the linux driver to stop the race.
Phil
Wolf, Josef wrote:
Phil Wilshire wrote:
This is a guess but...
when the system hangs after a "restore flags" it is normally
due to some unserviced interrupt condition.
The UART is trying to send you an interrupt but you are not
servicing it correctly therefor the interrupt is immediately
reasserted. This will seem like a hang.
The fact that after you send a character the system continues means
that the arrival of the character caused you to detect an rx ready
interrupt and whatever you did to clear that interrupt allowed the
original interrupt that caused the interrupt hang to be cleared.
Thanks for the great explanation, Phil! With your help I was able to
debug some steps further.
If this is the case then you need to look at the status buts
read from the device and make sure that they are all handled
You have to cleat the flag but also clear the condition that
caused the flag to be set.
Now I see what caused the problem:
After flashing the target, I started minicom (from my Makefile) while
U-Boot was busy calculating checksum and uncompressing the kernel.
When started up, Minicom sends some AT commands since it is configured
to talk to a modem.
I can now trigger the hang by typing any character while U-Boot is busy
uncompressing the kernel.
I have enabled SERIAL_DEBUG_INTR (btw there's a typo in the driver,
see the end of this mail) and this is what actually happens:
rs_interrupt_single(6)...status = 60...IIR = cc
[ the "...status = 60...IIR = cc" repeats over and over again
until I press some key
]
status = 61...DR0d:61...IIR = c1...end.
status=60 means there is a rx error (but no data to read) in the fifo.
IIR=cc means that the CTI (Character Timeout Indication) interrupt
is asserted.
This error indication is set over and over and over again, thus the
hang. Since the original driver checks only UART_LSR_DR, it will
never try to read data to get the condition cleared.
The question now is whether this is a driver bug or a hardware bug.
I'd argue it is a hardware bug because CTI should be only asserted when
at least one character is in the fifo and UART_LSR_DR should be set in
this case.
Since there is little hope that NXP will fix the bug, the driver should
clear the error condition when bit LSR:7 is asserted by reading the rx
register.
Opinions? Suggestions?
Hope this will help lead you to a solution.
I still don't have a solution, but at least I am a great deal closer
to it now. ;-)
BTW: There's a typo in the serial driver. Maybe somebody can apply this
patch to the cvs:
diff -ruw linux-2.4.32.orig/drivers/char/serial.c
linux-2.4.32/drivers/char/serial.c
--- linux-2.4.32.orig/drivers/char/serial.c 2005-11-16
20:12:54.000000000 +0100
+++ linux-2.4.32/drivers/char/serial.c 2007-10-17 10:46:25.000000000
+0200
@@ -935,7 +935,7 @@
transmit_chars(info, 0);
#endif
if (pass_counter++ > RS_ISR_PASS_LIMIT) {
-#if SERIAL_DEBUG_INTR
+#ifdef SERIAL_DEBUG_INTR
printk("rs_single loop break.\n");
#endif
break;
_______________________________________________
uClinux-dev mailing list
[email protected]
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by [email protected]
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
_______________________________________________
uClinux-dev mailing list
[email protected]
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by [email protected]
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
