Re: 16550 Over-run errors on 200 MHz Atmel AT91SAM9263 @ 115200 on Windows CE 6.0

I took a look and it seems that it is not just the ISR Handler that is
causing the IST to release. In fact, if I do a return SYSINTR_CHAIN
in the ISRHandler entry point (as the first thing.) I still get the
IST releasing and calling into SL_GetInterruptType.

I was thinking that it may be possible that I have mucked up the
SysIntr and such configuration so I was hoping if someone could let me
know what I am doing wrong.

In the registry (that can be seen earlier.) I give a PioInterrupt that
should be used as the interrupt source. This PioInterrupt value will
be the same for all four (4) interrupts and there is a function in our
OAL that converts from the PIO Value into an IRQ value (its really
basically PIO_IRQ_BASE + PioValue.)

So from this PioInterrupt I can get the Irq value, and this Irq value
I assign as the Irq that the ISR will use. I also get the SysIntr
value by calling KernelIoControl with IOCTL_HAL_REQUEST_SYSINTR as
this is what I have always done when dealing with getting SysIntr
values and interrupts. This SysIntr value will eventually get used by
the MDD in its call to InterruptInitialize.

It has occurred to me though, that using that SysIntr value is
probably not correct as the system might still release the IST when
that SysIntr goes off meaning that the IST might get released for both
the ISR (when it return SysIntr) and from the interrupt mechanism.

Am I correct in thinking that I shouldn't have used the Irq to get the
SysIntr that the MDD will eventually use? If not, how do you normally
come up with which SysIntr value to use? Would you create 4 logical
interrupts to get the the SysIntr values by calling
KernelIoControl(IOCTL_HAL_REQUEST_SYSINTR,...)?

Once again, thank you for all your help,
Brad.

On Feb 21, 9:41 am, "Bruce Eitman [eMVP]"
<beitman.nos...@xxxxxxxxxxxxxxxxxxxxxx> wrote:
No confusion, I just wanted to point out that if the interrupt is more like
this:

<Interrupt>
ISR for SysIntr 1 runs (CHAIN)
ISR for SysIntr 2 runs (SysIntr 2)
<Interrupt>
System unblocks IST for SysIntr 2.
IST calls InterruptDone on SysIntr 2.

That the second interrupt which is really for a different UART (sysintr 4),
then be carefull that it doesn't return the sysintr 2 again.  That would
cause problems.

--
Bruce Eitman (eMVP)
Senior Engineer
beitman AT applieddata DOT net

Applied Data Systems
 www.applieddata.net
An ISO 9001:2000 Registered Company
Microsoft WEP Gold-level Member

"Bradley Remedios" <bremed...@xxxxxxxxx> wrote in message

news:26879a79-3911-416d-861e-0635d1b749c4@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx



On Feb 21, 7:55 am, "Bruce Eitman [eMVP]"
<beitman.nos...@xxxxxxxxxxxxxxxxxxxxxx> wrote:
other ISRs as more than one could have triggered.  Now I understand
that you have to have the shared interrupts level-sensitive so the ISR
will re-fire after the first one is handled and the chain is stopped.

Of course you need to make sure that the ISR doesn't continue seeing the
same shared interrupt, and returning the same SYSINTR value.

By re-fire I meant if more than one port caused the interrupt, not if
it was just one port / device, sorry for any confusion that wording
may have caused.  Just to be clear, my previous (incorrect)
understanding of how it all works was as follows:

4 SysIntr (1-4), using IRQ X

<Shared Interrupt>

ISR for SysIntr 1 runs (CHAIN)
ISR for SysIntr 2 runs (SysIntr 2)
ISR for SysIntr 3 runs (CHAIN)
ISR for SysIntr 4 runs (SysIntr 4)

System unblocks ISTs for SysIntr 2 and 4.
ISTs call InterruptDone on SysIntr 2 and 4.

However, based on comments from Luca I now understand the actual flow
to be as follows:
<Interrupt>
ISR for SysIntr 1 runs (CHAIN)
ISR for SysIntr 2 runs (SysIntr 2)
System unblocks IST for SysIntr 2.
IST calls InterruptDone on SysIntr 2.

<Interrupt>
ISR for SysIntr 1 runs (CHAIN)
ISR for SysIntr 2 runs (CHAIN)
ISR for SysIntr 3 runs (CHAIN)
ISR for SysIntr 4 runs (SysIntr 4)
System unblocks IST for SysIntr 4.
IST calls InterruptDone on SysIntr 4.

Thank you,
Brad.- Hide quoted text -

- Show quoted text -

.

Relevant Pages

  • Re: Dual UART with single interrupt line.
    ... is that when the Dual UART signals an interrupt (which ... You will need to do one of two things, the easiest being using an ISR ... Each IST has a different SYSINTR (which the ISR knows ... no other ISRs in the chain are executed (and no ISTs will run.) ...
    (microsoft.public.windowsce.platbuilder)
  • Re: 16550 Over-run errors on 200 MHz Atmel AT91SAM9263 @ 115200 on Windows CE 6.0
    ... will re-fire after the first one is handled and the chain is stopped. ... Of course you need to make sure that the ISR doesn't continue seeing the ... same shared interrupt, and returning the same SYSINTR value. ... SysIntr, using IRQ X ...
    (microsoft.public.windowsce.platbuilder)
  • Re: Interrupt jitter caused by mouse move
    ... your IST is not what gets called when the interrupt occurs. ... The ISR runs first, returns a SYSINTR value, and the kernel schedules the ... while your IST thread might be the highest priority thread in the system, ...
    (microsoft.public.windowsce.platbuilder)
  • Re: 16550 Over-run errors on 200 MHz Atmel AT91SAM9263 @ 115200 on Windows CE 6.0
    ... I just wanted to point out that if the interrupt is more like ... ISR for SysIntr 2 runs ... will re-fire after the first one is handled and the chain is stopped. ...
    (microsoft.public.windowsce.platbuilder)
  • Installable ISR problem.
    ... We are writing an installable isr for the Toradex colibri pxa270 board. ... the bit numbers of the PXA27x Interrupt resisters) ... // Link our Event with the SYSINTR ... //clear ostimer flag ...
    (microsoft.public.windowsce.platbuilder)