Instrument Control (GPIB, Serial, VISA, IVI)

cancel
Showing results for 
Search instead for 
Did you mean: 

PMC-GPIB board using Vxworks on a PowerPC VME SBC

Good afternoon, 
 
We are trying to use the x86/intel based NI-488DDK code for vxworks and to port it to the Force Powercore 6750 (PowerPC) based CPU Single board computer.  I had seen the previous post regarding the MVME2432 board and about the byte swapping with the MITE code.  this did help, but we're now stuck in the second set of initialization after the MITE stuff in the ib_init sample code.
 
 
We did find that once the device was found, we configured had some registers prior to the normal startup code in ib.c (I don't have it in front of me right now,unfortunately).
 
Has anyone else had success with this configuration, or similar that would be willing to share any hints, hopes, or source code on using this board in this environment, including memory mapping?
 
thanks for everyone's time
jim
 
 
 
0 Kudos
Message 1 of 8
(4,998 Views)

I forgot to mention.

Development environment: Tornado 2.0.2

Target environment:  Vxworks 5.4

thanks again

jim

0 Kudos
Message 2 of 8
(4,993 Views)
Jim,

What things have you already changed in the DDK to get this working?  I know that you will have to change the interrupt vector mapping for both intConnect() and pciIntConnect().  The x86 BSP defines sysIntEnablePIC() as intEnable(), you may need to do the same for your BSP, or alternatively modify the DDK code to directly call intEnable(). 

What issues are you specifically running into?

Hope this gives you a start.

Craig A.
National Instruments Engineer
0 Kudos
Message 3 of 8
(4,977 Views)
thanks Craig.
I have an NI request number of 7108937.  the contents are something like this...
Problem: Porting PMC-GPIB from X86 VxWorks to PowerPC VxWorks
Product Information:  National Instruments PMC-GPIB – GPIB Interface for PCI Mezzanine Bus
                      NI-488.2 Driver Software
Target Platform Information
        HW: PCORE 750 PowerPC Board
        OS: VxWorks 5.4
        Compiler:  Tornado 2.0.2
Changes made to NI PMC-GPIB software:
        We can see the card when frcPciBusShow() is called from Tornado
        PCIxxx based commands have been overloaded with the equivalent frcPcixxx commands.
        ib_init() function was modified. After the frcPciFindDevice finds the PMC-GPIB card
        the following code was added for ib_init() to continue execution:
                Set Base Address Register 0 to Memory Space Addrs
                Set Base Address Register 1 to I/O Space Addrs
                Set Base Address Register 2 to Memory Space Addrs
                Set Bit in Command Register to I/O Space Control,
                Memory Space Control, Bus Master Ctrl and Memory Write Invalidate Command
        Byte swapping was added for read/write commands
        Modified the vendor’s device ID since it does not match what was seen on the PCI bus probe.
        Execution of ib_init() stops at the end of it’s ib_probe() call declaring “initialization failed for all buses”.
        * the nitn_presence_check() function fails on test 1 because adr1 at 0x0 fails its test
        * I examined some of the addresses printed on the console. The memory dump shows  no data at all.
0 Kudos
Message 4 of 8
(4,970 Views)
Jim,

If "Execution of ib_init() stops at the end of it’s ib_probe() call declaring “initialization failed for all buses”.", then there are two possible reasons for the failure. 

1. pciFindDevice is failing.  I think that you've solved this problem by changing the PCI_NI_DEVICE_ID to match the PMC-GPIB. 
2. intConnect is failing.  Given that x86 and PPC interrupt mapping is vastly different, I'm guessing that this is a strong possibility for the source of your failure.  You'll also have to fix pciIntConnect in ib_dataInit().

On PPC I also had to modify the SCROMin32, MITEin32, and MITEout32 macros to behave better for endianness issues.  I redefined those macros in terms of newly created ib_memIn32/ib_memOut32 functions.
e.g. 
#define MITEin32(addr)   (ib_memIn32(addr))
I then created ib_memIn32 and ib_memOut32 as follows:

uint32 ib_memIn32(uint32 *addr)
{
#if (_BYTE_ORDER == _BIG_ENDIAN)
   uint32 l_registerValue = *addr;
   l_registerValue = LONGSWAP(l_registerValue);
   return l_registerValue;
#else
   return *addr;
#endif
}

void
ib_memOut32(uint32 *addr, uint32 value)
{
#if (_BYTE_ORDER == _BIG_ENDIAN)
   value = LONGSWAP(value);
#endif
   *addr = value;
}

You may also need to add a couple of entries to sysPhysMemDesc[ ] in sysLib.c in your BSP.  You may need the following entries:
<BAR0 address> should be the value returned by pciConfigInLong(busNo, deviceNo, funcNo, PCI_CFG_BASE_ADDRESS_0, (UINT32 *)&base0); in base0
<BAR1 address> should be the value returned by pciConfigInLong(busNo, deviceNo, funcNo, PCI_CFG_BASE_ADDRESS_1, (UINT32 *)&base1); in base1


    /* PCI-GPIB - PBAR0 */
    {
    (void *) <BAR0 address>,
    (void *)
<BAR0 address>,
    0x1000,
    VM_STATE_MASK_VALID | VM_STATE_MASK_WRITABLE | VM_STATE_MASK_CACHEABLE | VM_STATE_MASK_GUARDED,
     VM_STATE_VALID      | VM_STATE_WRITABLE      | VM_STATE_CACHEABLE_NOT  | VM_STATE_GUARDED
    },

    /* PCI-GPIB - PBAR1 */
    {
    (void *)
<BAR1 address>,
    (void *)
<BAR1 address>,
    0x4000,
    VM_STATE_MASK_VALID | VM_STATE_MASK_WRITABLE | VM_STATE_MASK_CACHEABLE | VM_STATE_MASK_GUARDED,
     VM_STATE_VALID      | VM_STATE_WRITABLE      | VM_STATE_CACHEABLE_NOT  | VM_STATE_GUARDED
    }


I don't think that you'll need to do the following if you do all of the previously recommended things.
                Set Base Address Register 0 to Memory Space Addrs
                Set Base Address Register 1 to I/O Space Addrs
                Set Base Address Register 2 to Memory Space Addrs
                Set Bit in Command Register to I/O Space Control,
                Memory Space Control, Bus Master Ctrl and Memory Write Invalidate Command

Craig A.
National Instruments Engineer

0 Kudos
Message 5 of 8
(4,965 Views)

Mark,

thanks for the information.

We did some of the byte swapping but not all of it.  We're going to try that.

As for the initial setting of the memory stuff, it is required, otherwise the test program breaks a lot earlier.

the calls also isolate the values in sysLib.c away from the actual implentation..

 

We'll check in later.

Jim

0 Kudos
Message 6 of 8
(4,929 Views)

to

National Instruments Engineer

 

You said "need to add a couple of entries to sysPhysMemDesc[ ] in sysLib.c":

 

/* PCI-GPIB - PBAR0 */
    {
    (void *) <BAR0 address>,
    (void *)
<BAR0 address>,
    0x1000,
    VM_STATE_MASK_VALID | VM_STATE_MASK_WRITABLE | VM_STATE_MASK_CACHEABLE | VM_STATE_MASK_GUARDED,
     VM_STATE_VALID      | VM_STATE_WRITABLE      | VM_STATE_CACHEABLE_NOT  | VM_STATE_GUARDED
    },

    /* PCI-GPIB - PBAR1 */
    {
    (void *)
<BAR1 address>,
    (void *)
<BAR1 address>,
    0x4000,
    VM_STATE_MASK_VALID | VM_STATE_MASK_WRITABLE | VM_STATE_MASK_CACHEABLE | VM_STATE_MASK_GUARDED,
     VM_STATE_VALID      | VM_STATE_WRITABLE      | VM_STATE_CACHEABLE_NOT  | VM_STATE_GUARDED
    }

 

If there is something defined as follow:

 

#ifdef INCLUDE_PCI
    ,
    {
    (void *) PCI_MEM_ADRS,
    (void *) PCI_MEM_ADRS,
    PCI_MEM_SIZE,
    VM_STATE_MASK_VALID | VM_STATE_MASK_WRITABLE | VM_STATE_MASK_CACHEABLE | \
    VM_STATE_MASK_GUARDED | VM_STATE_MASK_MEM_COHERENCY,
    VM_STATE_VALID      | VM_STATE_WRITABLE      | VM_STATE_CACHEABLE_NOT | \
    VM_STATE_GUARDED      | VM_STATE_MEM_COHERENCY
    }
    ,
    {
    (void *) PCI_MEMIO_ADRS,
    (void *) PCI_MEMIO_ADRS,
    PCI_MEMIO_SIZE,
    VM_STATE_MASK_VALID | VM_STATE_MASK_WRITABLE | VM_STATE_MASK_CACHEABLE | \
    VM_STATE_MASK_GUARDED | VM_STATE_MASK_MEM_COHERENCY,
    VM_STATE_VALID      | VM_STATE_WRITABLE      | VM_STATE_CACHEABLE_NOT | \
    VM_STATE_GUARDED      | VM_STATE_MEM_COHERENCY
    }
    ,
    {
    (void *) PCI_IO_ADRS,
    (void *) PCI_IO_ADRS,
    PCI_IO_SIZE,
    VM_STATE_MASK_VALID | VM_STATE_MASK_WRITABLE | VM_STATE_MASK_CACHEABLE | \
    VM_STATE_MASK_GUARDED | VM_STATE_MASK_MEM_COHERENCY,
    VM_STATE_VALID      | VM_STATE_WRITABLE      | VM_STATE_CACHEABLE_NOT | \
    VM_STATE_GUARDED      | VM_STATE_MEM_COHERENCY
    }

 

 

Whether is needed your suggestion?

0 Kudos
Message 7 of 8
(4,019 Views)

The problem is ok!

0 Kudos
Message 8 of 8
(4,001 Views)