PCI interrupts again

Hey guys,

I noticed that when I access the PCI card from within the interrupt handler
( when I clear the interrupt) like I’m supposed to the system crashes. It
displays the message “Interrupt Handler faulted” and then displays the
system registers and crashes. Any help would be appreiciated.

“Brad Stocking” <bstocking@NXTenergy.com> wrote in message
news:9aa1un$ff9$1@inn.qnx.com

Hey guys,

I noticed that when I access the PCI card from within the interrupt
handler
( when I clear the interrupt) like I’m supposed to the system crashes.

how do you access your PCI card within interrupt handler ?

It displays the message “Interrupt Handler faulted” and then displays the
system registers and crashes. Any help would be appreiciated.

// wbr

Thanks Ian,

I had to map two portions of memory, for different register groups, then
access the registers through the memory location mapped for the desired
register.

It still didn’t work though…



Brad Stocking <bstocking@NXTenergy.com> wrote in message
news:9aa485$grj$1@inn.qnx.com

Thanks Ian,

I had to map two portions of memory, for different register groups, then
access the registers through the memory location mapped for the desired
register.

Previously, Brad Stocking wrote in qdn.public.qnx4.photon:

  1. don’t call any ISR non-safety routines from interrupt handler…

I don’t use printf() or any other non-safe routines that I know of…
I simple put data into the mapped memory with a pointer

( *(win_address+(Address/2)) = data; )

  • win_address is the base address and address is the offset
    […]
  1. pass correct ds value in qnx_hint_attach() and your handler is a far
    function

I pass a ds value of a variable I don’t even use in the handler… that
could be the problem. I’m not sure what ds to use.

Can you try passing the DS of win_address? You need to pass the DS of
the variables that you are going to access from within the interrupt
handler. You might want to put win_address and Address into a
structure, allocate an instance of the structure, and pass the DS of
the allocated structure instance.

I think, in reality, that you only have two DS values in a typical
program - one for initialized static data, and one for heap, though
there could be a third for uninitialized static data. Somebody from
the compiler group will probably correct me on this.

Cheers,
Andrew

“Brad Stocking” <bstocking@NXTenergy.com> wrote in message
news:9aa485$grj$1@inn.qnx.com

Thanks Ian,

I had to map two portions of memory, for different register groups, then
access the registers through the memory location mapped for the desired
register.

for sure you

  1. compile your interrupt handler code with stack checking disabled
  2. link executable with -T1 cc option and runs it with root priveleges
  3. don’t call any ISR non-safety routines from interrupt handler…
  4. …and also map your memory with mmap() outside interrupt handler code
  5. can access mapped memory outside interrupt handler ok without SIGSEGV
  6. pass correct ds value in qnx_hint_attach() and your handler is a far
    function
  7. has really reasonable arguments to do that exactly withing interrupt
    handler.

well, if all above is “yes” then for this stage i give up :slight_smile: but anyway we
can see
what we can try to do with this problem.

// wbr

  1. compile your interrupt handler code with stack checking disabled

Yes. I used #pragma off(check_stack) and #pragma on(check_stack)

  1. link executable with -T1 cc option and runs it with root priveleges

I do link it with -T1… I also run it from the root directory

  1. don’t call any ISR non-safety routines from interrupt handler…

I don’t use printf() or any other non-safe routines that I know of…
I simple put data into the mapped memory with a pointer

( *(win_address+(Address/2)) = data; )

  • win_address is the base address and address is the offset
  1. …and also map your memory with mmap() outside interrupt handler code

Yes.

  1. can access mapped memory outside interrupt handler ok without SIGSEGV

Polling Mode works alright and the interrupt driver works when not
in photon

  1. pass correct ds value in qnx_hint_attach() and your handler is a far
    function

I pass a ds value of a variable I don’t even use in the handler… that
could be the problem. I’m not sure what ds to use.

  1. has really reasonable arguments to do that exactly withing interrupt
    handler.

The arguements are reasonable


Thanks for the reply

Previously, Brad Stocking wrote in qdn.public.qnx4.photon:

I’m acknowledging the interrupt in the handler now, but there seems to be a
problem with the order. Does the order that I acknowledge the interrupt and
trigger the proxy matter?

You should never call Trigger() from within an interrupt handler.
Instead you can return a value from the interrupt handler which is a
proxy_id. If you don’t want to trigger, then return(0).

\

Mitchell Schoenbrun --------- maschoen@pobox.com

I’m acknowledging the interrupt in the handler now, but there seems to be a
problem with the order. Does the order that I acknowledge the interrupt and
trigger the proxy matter?