Problems with ISR16550.dll

Our custom SH4 based hardware (CE.NET 4.2 OS) has an ST16C554 quad UART
connected. We have this working correctly using the standard
COM16550.dll driver supplied by MS (we have done some minor changes to
the PDD code in com16550.c to get it to work with our hardware, but
nothing major).
I am now attempting to use the ISR16550.dll "high speed" serial driver,
but am not having much success.
I have added the appropriate reg entries, and added the call to
NkCallIntChain() in the OAL ISR code (I basically copied the assembler
source code from Aspen that makes this call).
I have initially enabled (in the registry) only one of the four UART
ports to use the installable ISR (ISR16550.dll), in order to compare
performance with the other ports.
The test code I am using attempts to transmit 200 bytes from the port
with the IISR to one of the "normal" ports, via a loopback cable. There
is no hardware or software handshaking, and timeouts are all set to
zero.
This test works fine if I don't use the IISR, but not when I enable it.
What appears to happen (determined by stepping through the code with the
kernel debugger) is that the 200 bytes get loaded into the IISR tx fifo
correctly, and some of these (12 bytes) get received by the other serial
port. The IISR port then ends up waiting forever for the transmit
complete interrupt, but it never gets it, as shown in the following
debug output:

1236191 PID:8ffbebc2 TID:fd8d116 0x8fd14098: -GetBytes - rx'ed 12,
dropped 0.
1236191 PID:8ffbebc2 TID:fd8d116 0x8fd14098: After HWGetBytes, Fifo(R=
0,W=1,BA=1,L=2048) ByteRead=12
1236192 PID:8ffbebc2 TID:fd8d116 0x8fd14098: +SL_GetInterruptType IIR=c1
1236193 PID:8ffbebc2 TID:fd8d116 0x8fd14098: -SL_GetInterruptType
0x32820, 0x0
1236194 PID:8ffbebc2 TID:fd8d116 0x8fd14098: SerialEventHandler, No
Interrupt.
1236195 PID:8ffbebc2 TID:fd8d116 0x8fd14098: -SerialEventHandler, Fifo
(R=0,W=13,L=2048)
1236196 PID:8ffbebc2 TID:fd8d116 0x8fd14098: Event 8FF86E16, 24
1236203 PID:8ffbebc2 TID:afd24cd6 0x8fc9a978: SL_TxIntrEx: Enable
INTR_TX.
1236212 PID:8ffbebc2 TID:afd24cd6 0x8fc9a978: SL_TxIntrEx released
CritSec 31c30.
1236217 PID:8ffbebc2 TID:afd24cd6 0x8fc9a978: -SL_TxIntrEx - sent 200.
1236231 PID:8ffbebc2 TID:afd24cd6 0x8fc9a978: 200 bytes actually copied.
1236251 PID:8ffbebc2 TID:afd24cd6 0x8fc9a978: DoPutBytes released
CritSec: 31b34.
1236274 PID:8ffbebc2 TID:afd24cd6 0x8fc9a978: COM_Write wait for
transmission complete event cff865ae.

If I exit the test program, the wait returns and the port closes as
expected.

So it looks looks like I'm not getting interrupts routed back to the
ISR16550.dll correctly.
Any ideas what could be wrong here, or any suggestions as to what to try
to diagnose the problem?

Andrew

Andrew
Thu Dec 01 04:38:40 CST 2005

I think I may have an answer to my question, but won't know for sure
until I get back to work tomorrow to try it out.

Looking back through old posts (thanks again Steve Maillet!), I see lots
of discussion about installable ISRs having to use statically mapped
virtual memory addresses (via TransBusAddrToStatic()).
I think this is my problem, since my CEDDK implementation of
HalTranslateBusAddress() always (erroneously I suspect) sets the
AddressSpace parameter to 1, indicating the translated address is an IO
mapped address.
It looks like the Ser_InternalMapRegisterAddresses() function in
com16550.c won't end up calling TransBusAddToStatic() in this case,
since it (understandably) assumes an IO address is process independent,
so doesn't need to be statically mapped.
I see that the ppStaticAddress parameter returned by
Ser_InternalMapRegisterAddresses() is only used if an installable ISR
(ISR16550.dll) is used, which would explain why the driver works fine
until I use that ISR.

So, I think the fix for me is to return AddressSpace = 0 (memory mapped)
from my HalTranslateBusAddress() function (our SH4 CPU has no IO mapped
devices - the only reason I can think of that AddressSpace was being set
to 1 was for the benefit of PCI devices, since we ported our BSP from an
SH7751R BSP which had a PCI bus, but our SH7750R CPU doesn't have one
anyway).

Anyway, I guess if my theory doesn't work, I'll be back looking for
other suggestions!