The 162 is capable of generating a bus backplane interrupt. The interrupt can be generated via software running on the 162. Backplane interrupts are generated using the "vmeChip2." Generating a backplane interrupt involves writing to a register on the vmeChip2 called the VMEbus Interrupter Control Register. Its address as seen by the 162 is 0xFFF40048. See the "MVME162 Embedded Controller Programmer's Reference Guide."
An interrupt is generated when the interrupt level (1-7) and the interrupt vector (1-255) are written to the Interrupter Control Register. When the level and vector are written to this register, the vmeChip2 activates the appropriate backplane IRQ line. IRQ lines 1-7 correspond with the interrupt level 1-7 written to the register. The IRQ line will remain active until some board on the bus does an interrupt acknowledge (IACK) cycle. During the IACK cycle the vector that was written to the Interrupter Control Register will be read by the board that acknowledged the interrupt. The IRQ line has no time out associated with it, so it will remain active forever if no other board acknowledges it.
I have learned by experimentation that if an interrupt generated by the vmeChip2 is pending (one of the IRQ lines is being held active by the vmeChip2 and has not yet been acknowledged), and the software tries to generate another interrupt on another level, the vmeChip2 will ignore the request. It will not pull two IRQ lines active at the same time. This makes sense because it only has one vector register so how would it know what vector to use if it had several interrupts pending.
The vmeChip2 also handles interrupt acknowledgment for cases when the board is required to listen to backplane IRQs. When reading the "162 Programmer's Reference Guide" its important not to confuse the interrupt acknowledgment registers on the vmeChip2 with the interrupt generation register. The 162 can be configured to acknowledge backplane IRQs by setting certain interrupt enable bits on the vmeChip2. No interrupt enable bits are required for interrupt generation.
Its interesting to note that if the 162 VME interrupts are enabled so that the board listens to backplane IRQs, and the software generates a backplane interrupt via the vmeChip2, the 162 board will acknowledge itself. It will see the IRQ which was activated by the vmeChip2 and it will do an IACK cycle just as if the interrupt was generated by another board in the crate. If the 162 is used in a configuration where it is required to both generate and receive interrupts, they should be generated and received on 2 different IRQ lines. Interrupts should not be received on the same backplane IRQ line as they are being sent.
The GSCR is a group of several registers on the 162 board which are accessible from other CPU boards in the crate via A16 short I/O space. There are 4 bits in one of the GSCR registers which are called the signal bits SIG0 - SIG3. The signal bits can be configured so that they cause the 162 to be interrupted when another CPU in the crate sets one of the signal bits. So another CPU in the crate can interrupt the 162 by simply writing some data to a specific A16 Short I/O address on the 162 board.
VxWorks makes use of the GSCR interrupt method. Wind River calls it the Mailbox method. VxWorks provides 3 Mailbox functions in the file vmeChip2Vme.c. The functions are sysMailboxConnect(routine, arg), sysMailboxEnable(), and sysMailboxInt(). The sysMailboxConnect(routine, arg) function is used to connect a custom interrupt service routine to the Mailbox interrupt. After the routine is connected, sysMailboxEnable() should be called. The other function, sysMailboxInt() is not meant to be called by the user. It is used internally to clear the signal bit when the Mailbox interrupt occurs.
The custom Mailbox service routine which is written by the user should be treated as an ISR, which means that printf should not be used, semaphores can not be taken, and care must be taken when using floating point math. See the VxWorks documentation regarding interrupt service routines.
Now that it has been explained how VxWorks functions can be used to handle Mailbox interrupts, it must also be explained how the foreign CPU in the crate triggers a Mailbox interrupt. The GSCR registers can be mapped to different addresses in A16 space on the 162 board. In order to find out where VxWorks has placed the Mailbox, look at the file /usr/vw_51/config/mv162/config.h. The following will be found.
#define GSCR_GROUP_ADDR 0xC2.
#define SM_INT_TYPE SM_INT_MAILBOX_1
#define SM_INT_ARG1 VME_AM_SUP_SHORT_IO
#define SM_INT_ARG2 ((GCSR_GROUP_ADDR<<8)+(sysProcNumGet()<<4)+2)
#define SM_INT_ARG3 0x08
To decipher the meaning of all this stuff see the "VxWorks Programmer's Guide", page 268. What it all means is that in order for a foreign CPU in the crate to trigger a Mailbox interrupt on the 162, it must write the data 0x08 to A16 space at address 0xC202. If the 162 board is not processor number 0, and is instead say processor number 1, then the A16 address would be 0xC212. See also sysProcNumSet() in the file /usr/vw_51/config/mv162/sysLib.c.
"MVME162 Embedded Controller Programmer's Reference Guide", Motorola.
"VxWorks Programmer's Guide", Wind River.
On crusher:
/usr/vw_51/config/mv162/config.h
/usr/vw_51/config/mv162/mv162.h
/usr/vw_51/config/mv162/sysLib.c
/usr/vw_51/src/drv/vme/vmeChip2Vme.c
/usr/vw_51/h/drv/vme/vmeChip2.h