RE: [ECOS] generating interrupts in ARM-PID (SID simulator)

RE: [ECOS] generating interrupts in ARM-PID (SID simulator)

[Robert Cragie]

> > I am trying to generate external interrupts and handle
> > it on a ARM-PID configuration. I am using SID as the
> > simulator for ARM PID.Ofcourse, eCos is my RTOS.
> >
> > >From the SID configuration file, I understand that
> > there is a interrupt controller which can be
> > associated with 32 interrupts.One of the output pins
> > of the interrupt controler is connected to the "nirq"
> > pin of the processor.
> > I use one the the interrutpt sources numbered "16" to
> > associate with an event whose occurance I want to
> > count.

Only interrupts up to 15 can be handled by the interrupt controller (well,
according to the PID manual anyway). Try connecting to interrupt number 11.
This corresponds to the ASB0 interrupt, which seems to be unconnected in
SID.

So in configrun-sid:

connect-pin sensor-sched 1-event -> intrctrl source-11

However, note that the inputs to the ARM interrupt controller are level
interrupts. If the scheduler generates a pulse, it could either get missed
(short pulse) or cause continuous interruption problems (long pulse). So
ideally in either case you'd want to latch the rising edge of the scheduler
output and have some mechanism to clear the it in the DSR somehow. I'm not
sure how you'd do this is SID, though.

> > Now, the problem is that I am unable to catch the
> > interrupt and process it using an ISR. Specifically, I
> > register my own ISR at the the vector 16. However, it
> > seems that I am unable to catch the interrupt.
> >
> > Could anyone kindly advise where I am making the
> > mistake? Also, I m unable to figure out that if and
> > how eCos can be configured to use the 32 interrupts.
> > Afterall, there is only one nirq line. How are the 32
> > interrupts mapped? When, I check the hal_intr.h file,
> > I find that at max there can be 8 interrupts.

Try something like the following to add a handler for interrupt number 11
(ASB0):

#include <cyg/kernel/kapi.h>
#include <cyg/hal/hal_intr.h>

/* IRQ handler object */

typedef struct tagIRQ_s
{
    CYG_WORD       tNum;
    cyg_interrupt  sIRQrsrc;
    cyg_handle_t   hIRQ;
} IRQ_s;

static IRQ_s s_sMyIRQ;

/* snip */

cyg_uint32 myISR(cyg_vector_t tVector, cyg_addrword_t tData)
{
    /* Nothing to do in ISR apart from the mandatory procedures */

    /* Stop any further interrupts until handled */
    cyg_interrupt_mask(tVector);

    /* Acknowledge to system (this MUST be done) */
    cyg_interrupt_acknowledge(tVector);

    /* Cause DSR to be run */
    return CYG_ISR_CALL_DSR;
}

cyg_uint32 myDSR(cyg_vector_t tVector, cyg_ucount32 u32Count, cyg_addrword_t
tData)
{
    /* DO YOUR INTERRUPT PROCESSING HERE */

    /* Finally reenable interrupts */
    cyg_interrupt_unmask(tVector);
}

/* snip - somewhere in your initialisation .... */

    s_sMyIRQ.tNum = CYGNUM_HAL_INTERRUPT_ASB0; /* 11 */

    /* First, create and attach the Interrupt handlers */
    cyg_interrupt_create(s_sMyIRQ.tNum,                 /* Interrupt number
*/
                         99,                            /* Priority - what
goes here? */
                         (cyg_addrword_t)&s_sMyIRQ,     /* Data item passed
to interrupt handler - whatever you want */
                         myISR,                         /* ISR */
                         myDSR,                         /* DSR */
                         &s_sMyIRQ.hIRQ,                /* (ptr. to)
Handle - filled in */
                         &s_sMyIRQ.sIRQrsrc);           /* (ptr. to)
Resource reqd. by interrupt */

    cyg_interrupt_attach(s_sMyIRQ.hIRQ);

    /* Finally, enable the interrupt */
    cyg_interrupt_unmask(s_sMyIRQ.tNum);

-----------------------
Hope this helps

Robert Cragie, Design Engineer
_______________________________________________________________
Jennic Ltd, Furnival Street, Sheffield, S1 4QT,  UK
http://www.jennic.com  Tel: +44 (0) 114 281 2655
_______________________________________________________________

RE: [ECOS] generating interrupts in ARM-PID (SID simulator)

[Partha Palit]

Hello,

I am back again with questions on generating
interrupt. 

As recommened by Robert, I tried using the interrupt
11.It seemed to work, but it showed up as spurious
interrupt which is not handled by the ARM Hal. I guess
this is becuase ARM recognizes level triggered
interrupts as pointed out by Robert.
-->Q: Could anyone kindly tell how to generate pulses
of definite time period using sid-sched? I guess a
timer can be used, but in the SID configuration file I
see that the timers have inputs from the cpu itself.
Is there anything simpler?

Also I had to manually generate the interrupt in the
SID tksm GUI. Otherwise it was not working.  
-->Q: What am I doing wrong ? Can the duration of the
pulse be controlled in the GUI? Presently, I am just
changing the value in the sched-event field..and I get
a spurious interrupt.

Thanks a lot.

-Partha


--- Robert Cragie <rcc@jennic.com> wrote:
> > > I am trying to generate external interrupts and
> handle
> > > it on a ARM-PID configuration. I am using SID as
> the
> > > simulator for ARM PID.Ofcourse, eCos is my RTOS.
> > >
> > > >From the SID configuration file, I understand
> that
> > > there is a interrupt controller which can be
> > > associated with 32 interrupts.One of the output
> pins
> > > of the interrupt controler is connected to the
> "nirq"
> > > pin of the processor.
> > > I use one the the interrutpt sources numbered
> "16" to
> > > associate with an event whose occurance I want
> to
> > > count.
> 
> Only interrupts up to 15 can be handled by the
> interrupt controller (well,
> according to the PID manual anyway). Try connecting
> to interrupt number 11.
> This corresponds to the ASB0 interrupt, which seems
> to be unconnected in
> SID.
> 
> So in configrun-sid:
> 
> connect-pin sensor-sched 1-event -> intrctrl
> source-11
> 
> However, note that the inputs to the ARM interrupt
> controller are level
> interrupts. If the scheduler generates a pulse, it
> could either get missed
> (short pulse) or cause continuous interruption
> problems (long pulse). So
> ideally in either case you'd want to latch the
> rising edge of the scheduler
> output and have some mechanism to clear the it in
> the DSR somehow. I'm not
> sure how you'd do this is SID, though.
> 
> > > Now, the problem is that I am unable to catch
> the
> > > interrupt and process it using an ISR.
> Specifically, I
> > > register my own ISR at the the vector 16.
> However, it
> > > seems that I am unable to catch the interrupt.
> > >
> > > Could anyone kindly advise where I am making the
> > > mistake? Also, I m unable to figure out that if
> and
> > > how eCos can be configured to use the 32
> interrupts.
> > > Afterall, there is only one nirq line. How are
> the 32
> > > interrupts mapped? When, I check the hal_intr.h
> file,
> > > I find that at max there can be 8 interrupts.
> 
> Try something like the following to add a handler
> for interrupt number 11
> (ASB0):
> 
> #include <cyg/kernel/kapi.h>
> #include <cyg/hal/hal_intr.h>
> 
> /* IRQ handler object */
> 
> typedef struct tagIRQ_s
> {
>     CYG_WORD       tNum;
>     cyg_interrupt  sIRQrsrc;
>     cyg_handle_t   hIRQ;
> } IRQ_s;
> 
> static IRQ_s s_sMyIRQ;
> 
> /* snip */
> 
> cyg_uint32 myISR(cyg_vector_t tVector,
> cyg_addrword_t tData)
> {
>     /* Nothing to do in ISR apart from the mandatory
> procedures */
> 
>     /* Stop any further interrupts until handled */
>     cyg_interrupt_mask(tVector);
> 
>     /* Acknowledge to system (this MUST be done) */
>     cyg_interrupt_acknowledge(tVector);
> 
>     /* Cause DSR to be run */
>     return CYG_ISR_CALL_DSR;
> }
> 
> cyg_uint32 myDSR(cyg_vector_t tVector, cyg_ucount32
> u32Count, cyg_addrword_t
> tData)
> {
>     /* DO YOUR INTERRUPT PROCESSING HERE */
> 
>     /* Finally reenable interrupts */
>     cyg_interrupt_unmask(tVector);
> }
> 
> /* snip - somewhere in your initialisation .... */
> 
>     s_sMyIRQ.tNum = CYGNUM_HAL_INTERRUPT_ASB0; /* 11
> */
> 
>     /* First, create and attach the Interrupt
> handlers */
>     cyg_interrupt_create(s_sMyIRQ.tNum,             
>    /* Interrupt number
> */
>                          99,                        
>    /* Priority - what
> goes here? */
>                          (cyg_addrword_t)&s_sMyIRQ, 
>    /* Data item passed
> to interrupt handler - whatever you want */
>                          myISR,                     
>    /* ISR */
>                          myDSR,                     
>    /* DSR */
>                          &s_sMyIRQ.hIRQ,            
>    /* (ptr. to)
> Handle - filled in */
>                          &s_sMyIRQ.sIRQrsrc);       
>    /* (ptr. to)
> Resource reqd. by interrupt */
> 
>     cyg_interrupt_attach(s_sMyIRQ.hIRQ);
> 
>     /* Finally, enable the interrupt */
>     cyg_interrupt_unmask(s_sMyIRQ.tNum);
> 
> -----------------------
> Hope this helps
> 
> Robert Cragie, Design Engineer
>
_______________________________________________________________
> Jennic Ltd, Furnival Street, Sheffield, S1 4QT,  UK
> http://www.jennic.com  Tel: +44 (0) 114 281 2655
>
_______________________________________________________________
> 


__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

Re: [ECOS] generating interrupts in ARM-PID (SID simulator)

[Frank Ch. Eigler]

Hi -


On Tue, Jul 01, 2003 at 01:50:14PM -0700, Partha Palit wrote:
> [...]
> As recommened by Robert, I tried using the interrupt
> 11.It seemed to work, but it showed up as spurious
> interrupt which is not handled by the ARM Hal. I guess
> this is becuase ARM recognizes level triggered
> interrupts as pointed out by Robert.

I would be surprised if that were the case.  At the time
that the interrupt is first asserted, the OS has no way
of knowing whether it was an edge or level type interrupt.
If it never even dispatches to your handler, on account of
spuriousity, then there is a software problem.  I would
expect an edge- vs level-triggering problem would show
itself by having an interrupt refusing to be masked off.


> -->Q: Could anyone kindly tell how to generate pulses
> of definite time period using sid-sched? [...]

First thing, one must be aware of how sid models signals
like this.  The basic signalling primitive takes a 32-bit
value, and can be interpreted as a pulse, an edge, or an
abstract event - the interpretation depends on the sender
and receiver.  Modules that want to model level-sensitive
phenomena sometimes use a 1-valued signal for the leading edge
and a 0-valued one for the trailing edge of the entire pulse.

It turns out that the scheduler sends a 0-valued abstract
signal when an event fires.  This does not seem appropriate
after all for direct connection to the hw-interrupt-arm/ref
inputs, which appears to prefer 1-/0- type signal pairs to
delimit pulses.

I suspect a reasonable way to go is to extend the scheduler
to allow the driven event signal to have a configurable value.
Then, one can send a proper 1-valued leading edge of a pulse
from the scheduler.  (This would require some very minor
code extensions to sid/component/sched.)

The trailing edge is normally caused by target software action
(the interrupt handler acknowledging it), so this could be
modelled by use of the hw-glue-probe-bus component.  This
little widget can be memory-mapped anywhere, and transmits on
pins the parameters of an incoming memory access.  It could
map a "write 0x0 to 0xA8000040" to a single pin event of value
0x0, suitable to connect to the same interrupt controller input.
It needs a dummy downstream memory object too:

  new hw-glue-probe-bus uninterruptor
  new hw-memory-ram/rom-basic dummy
  connect-bus cpu-mapper unint:[0xA800040,0xA8000043] uninterruptor upstream
  connect-pin uninterruptor data-low -> intctrl interrupt-signal-11
  set dummy size 4
  connect-bus uninterruptor downstream dummy read-write-port
  connect-pin target-sched 888-event -> intctrl interrupt-signal-11
  set target-sched 888-value 1 # not yet implemented
  set target-sched 888-time 8888


> Also I had to manually generate the interrupt in the
> SID tksm GUI. Otherwise it was not working.  [...]

I'm glad you found your way around the GUI.


- FCHE

RE: [ECOS] generating interrupts in ARM-PID (SID simulator)

[Robert Cragie]

> As recommened by Robert, I tried using the interrupt
> 11.It seemed to work, but it showed up as spurious
> interrupt which is not handled by the ARM Hal. I guess
> this is becuase ARM recognizes level triggered
> interrupts as pointed out by Robert.

A spurious interrupt is simply one which is not handled by the software
interrupt handling mechanism. It is nothing to do with level or
edge-triggered interrupts. All processors essentially work on
level-triggered interrupts. An edge-triggered interrupt is where an edge is
simply latched to assert a level, and then cleared in a defined way to
negate a level, usually by writing to some register.

So if you are getting a spurious interrupt, you are at least seeing the
interrupt, which is progress. Put a breakpoint on hal_IRQ_handler and see
what it's doing. I would guess you are not installing the interrupt handler
properly or the numbers are not corresponding or something - did you try the
sample source code I included?

You could also look at the Interrupt Controller registers on the PID
simulator to give you a clue as to what's going on, e.g. reading IRQStatus
will tell you active interrupts (i.e. where there is an interrupt and it is
also enabled) and reading IRQRawStatus will tell you actual interrupts (i.e.
where there is an interrupt even if it is disabled) (note I am assuming the
SID model matches this exactly):

Address    Read         Write

0x0A000000 IRQStatus    Reserved
0x0A000004 IRQRawStatus Reserved
0x0A000008 IRQEnable    IRQEnableSet
0x0A00000C Reserved     IRQEnableClear

0x0A000010 Reserved     IRQSoft(Programmed IRQ Interrupt)

0x0A000100 FIQStatus    Reserved
0x0A000104 FIQRawStatus Reserved
0x0A000108 FIQEnable    FIQEnableSet
0x0A00010C Reserved     FIQEnableClear

0x0A000110 Reserved     Reserved

0x0A000114 FIQSource    FIQSource

Note that these will normally be manipulated by the HAL when interrupts are
enabled/disabled/handled etc. and should not be tampered with unless you are
specifically trying to debug something.

> -->Q: Could anyone kindly tell how to generate pulses
> of definite time period using sid-sched? I guess a
> timer can be used, but in the SID configuration file I
> see that the timers have inputs from the cpu itself.
> Is there anything simpler?

Over to Frank and the SID guys, where you seem to have got a comprehensive
answer.

Robert Cragie, Design Engineer
_______________________________________________________________
Jennic Ltd, Furnival Street, Sheffield, S1 4QT,  UK
http://www.jennic.com  Tel: +44 (0) 114 281 2655
_______________________________________________________________