16550 Over-run errors on 200 MHz Atmel AT91SAM9263 @ 115200 on Windows CE 6.0
- From: Bradley Remedios <bremedios@xxxxxxxxx>
- Date: Wed, 20 Feb 2008 17:18:29 -0800 (PST)
I have some questions that I hope that the list can answer for me.
I'm trying to get a serial driver for a Quad UART working at a high
speed (115200) and am having some problems with it where the hardware
fifo's are over-flowing.
My system is using a Quad UART from EXAR (shared interrupt). I have
used the Microsoft MDD (com_mdd2) and PDD (ser16550) along with a
little initialization code of my own to provide the the basic
initialization (grabbing the SysIntr, Mapping Virtual Memory, etc..)
In order to use Shared Interrupts I am using the isr16550 driver.
There are basically two configurations of the drivers that I am
working with.
Configuration 1:
- I have cloned isr16550 and made some modifications to use UART as
64-byte fifo instead of 16-byte fifo.
- I have cloned ser16550 and made some modifications to use UART as
64-byte fifo (FCR Rx Trigger levels are same as 16550)
- I have cloned com_mdd2 and added some additional debugging
information.
- I link my lower-level init code to my cloned ser16550 and cloned
com_mdd2.
- I have the Registry load in my cloned isr16550.
Configuration 2:
- I link my lower-level init code to the Microsoft ser16550 and
com_mdd2 that is already compiled within the Public tree.
- I have the Registry load in the Microsoft isr16550
My test runs only use one (1) of the four (4) serial ports using the
CF 2.0 System.Io.Ports.SerialPort class. All four (4) drivers are
loaded, however three (3) of them are never even opened.
Regardless of the configuration that is used (and regardless of which
ISR is used) the hardware fifo's overflow well before Flow-Control
kicks in in user-land. This could make sense, as my understanding of
how the ISR works is that when the interrupt goes off, all four (4)
ISR's (one for each port) does it's work to check and see if there is
any work that it needs to do.
To see if this is the case, I disabled three (3) of the four (4) ports
so that only one of the serial ports driver is loaded (but still using
the same configuration.) In this scenario, the driver seems to work
fine as the software buffer fills up and the RTS level goes low. If
the other side is obeying flow-control no over-flows are happening.
With three(3) of the ports disabled, I've also disabled the registry
entries IsrDll and IsrHandler so that it loads without the ISR (and
just uses the IST) and I also observe the same scenerio here with
regards to the hardware over-flow problem disappearing.
My Registry Entries:
[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\UARTB]
"Index"=dword:7
"Prefix"="COM"
"Order"=dword:7 ; COM7
"Dll"="brad_com16550.dll" ; Driver Dll
"DeviceArrayIndex"=dword:1 ; USART1 (B)
"MemBase"=dword:70000010 ; Memory Window Base
"MemLen"=dword:100 ; Memory Window Length
"PioInterrupt"=dword:84 ; Irq (If valid) (32 * channel + io#) PE4
"Friendly Name"="Modem"
; "IsrDll"="brad_isr16550.dll" ;
"IsrDll"="isr16550.dll"
"IsrHandler"="ISRHandler" ;
"Irq"=dword:0 ;
"Priority256"=dword:5
brad_com16550.dll fixes up the Irq as it determines the appropriate
Irq and SysIntr from the PioInterrupt Value during the initialization
of the driver.
Things I've tried:
- Changing Index into Rx Trigger so that FCR[7:6] gets a lower value
to trigger rx interrupt earlier.
- Treating UART like 16-byte and 64-byte fifo.
Has anyone had any problems with the Stock isr16550, com_mdd2 and
ser16550 driver that is present in Windows Embedded CE 6.0. I have
VS2005, VS2005 SP1, PB6, PB SP1, and all QFEs up until Sept 2007
installed.
brad_com16550.dll implements its own HWInit, HWDeinit, HWOpen,
HWClose, HWPowerOff, HWPowerOn, HWEnableIR, HWDisableIR,
HWGetCommProperties. All other vtable entries point directly to the
SL_XXX functions in ser16550 (a lot of the custom HWInit still call
SL_XXX from within our own version.)
All Threads are created at Initialization as well.
-- A side question? The IST gets ran after all ISRs for a particular
interrupt are completed right? So if two of the ISRs actually detect
an interrupt condition (and return their SysIntr values), the two
corresponding ISTs will release from WaitForSingleObject after all the
ISRs that share that interrupt complete correct?
I could understand it if maybe the software buffer was filling up
(causing the over-runs) but I don't think that I should have a problem
with using the shared interrupts.
Am I being overly-optimistic due to the use of shared interrupts?
Does anyone see any reason why I would not be able to do what I am
trying to do, or any ideas as to how to improve its performance more?
I've experimented with some different buffer sizes (i.e. how much to
copy out on each rx interrupt) without change.
NOTE: The driver seems to work fine at the lower baud rates with
shared interrupts, but we really want to have it work at 115200.
Regards,
Brad.
.
- Follow-Ups:
- Re: 16550 Over-run errors on 200 MHz Atmel AT91SAM9263 @ 115200 on Windows CE 6.0
- From: Luca Calligaris
- Re: 16550 Over-run errors on 200 MHz Atmel AT91SAM9263 @ 115200 on Windows CE 6.0
- Prev by Date: Re: Mixed debug/retail image
- Next by Date: Re: AutoFormat and AutoMount
- Previous by thread: Re: Bootstrap problem on WinCE 6.0 with MSVS2005 crashes...
- Next by thread: Re: 16550 Over-run errors on 200 MHz Atmel AT91SAM9263 @ 115200 on Windows CE 6.0
- Index(es):
Relevant Pages
|
