Q\A about VME bus for Vxworks 2

Aditya Amar wrote:
> 1.The VMEbus has 7  levels of prioritized interrupts (IRQ1...IRQ7) . If
> I am generating IRQ4 from our custom designed h/w board then what
> should be the argument in the call to sysIntEnable from within vmeMain

IRQ4 => sysIntEnable(4)

> When I generated an IRQ4 interrupt from our custom board , over the 
> VMEbus and called sysIntEnable(4) to enable the specified bus interrupt
> level, I got a scrolling display of error messages on my debug monitor
> indicating that a wrong VMEbus interrupt :0 was recieved ?????????

That implies the interrupt vector number being returned by the hardware 
was read as a 0.

> 2. Assuming that during the IACK ( interrupt acknowledge) cycle, the 
> interrupting board would send 0x60 as the Interrupt Number/Interrupt 
> Vector  to the the SBC over the VME bus my call to intConnect should be
> 
> intConnect (INUM_TO_IVEC (0x60), myVMEinterruptHandler, 0);   or 
> intConnect (0x60, myVMEinterruptHandler, 0);

The first one, INUM_TO_IVEC(0x60)

> 3. I was under the impression that the intArchLib ( which is the 
> architecture-dependent interrupt library ) will provide the definition 
> of  INUM_TO_IVEC. But from the code snippet above it looks like I have 
> to define it myself. So the question is who provides the definition of 
> INUM_TO_IVEC ? If I have to define it how do I do it ?

Ignore the code snippet (which is for some unknown CPU), it's defined by 
your architecture, you just need to #include <iv.h> to get it (this is 
stated on the Reference Manual page for intArchLib).

> I am NOT using sysBusIntGen()  to simulate the generation of 
> interrupts, rather I am using our custom H/W boards to actually 
> generate interrupts across the VMEbus. We have verified that these 
> interrupts are actually getting generated and being transferred across 
> the VMEbus using probes, but are not able to connect an ISR which will 
> handle this interrupt on the SBC.

Check the cycle timing on the VME interface of the slave boards - even if 
they are known to work with a 680x0-based CPU board they still might not 
work with the Tundra, which meets the VMEbus spec but doesn't produce the 
same typical timings as earlier interface chips used to.  In particular 
check for address rot, as the Tundra can remove the Address Strobe earlier 
than the 68K designs used to, but there can be other similar kinds of 
timing issues leading to the wrong data being seen by the Tundra.

- Andrew
-- 
There are 10 types of people in the world:
Those who understand binary, and those who don't.