6723 register level programming

[k_laszlo]

Dear all,

I want to use a PCI-6723 with a special RT operation system. Before that I want to check the card under WinXP. I have a DDK example (from NI) for the PCI-6723. I try to use it in a P4 computer with XP, and Labview 8.5 with new Device Drivers. When I use the example the program cannot read the FPGA version, and check, because the value is 0XFFFFFF... The example doesn't put 5V to the Analog output 0. If I set a value (like 5V) to A0 with the frontpanel in MAX the example reset this value, but doesn't put 5V to the output. I think there is a problem with changing the register MAP (Tell the MITE to enable BAR1). I need some information about the register level programming.

Have you got any idea, why the program doesn't work?

What is the problem?

Thank you.

Laszlo Kerpen

[k_laszlo]

Dear all,

Now my colleague solved the problem. The problem was: we open the MAX first, and the front panel of the card. After that we run the example. The Windows reserve the card and if we close MAX the example cannot communicate with the card. If we restart the computer, and run the example before open the MAX, the example run successful.

Now we want to adopt the example to OnTime RT operation system. It doesn’t work now, because the visa32.dll cannot compatible with it. We need a part of the source code to use the example under our system.

We need the source code of the following functions:

viOpenDefaultRM

viGetAttribute

viMapAddress

viOpen

viClose

viMapAddress

viUnmapAddress

If it possible, please send me the source code of the functions.

We think the problem is the mapping. We cannot read the FPGA check, and version, because we are in a wrong MAP. We think we cannot change between the BAR0, and BAR1. We need some information about the MAP to use this card under OnTime.

Have you got any information about the mapping?

Thank you,

Laszlo Kerpen

[Tom_W_[DE]]

Hi Laszlo-

Those functions are provided by NI VISA for which the source is neither available nor particularly helpful for porting the MHDDK OS interface to a new operating system or environment.

My suggestion would instead be to check out the Linux /dev/mem Interface for an example that shows native O/S implementations (for Linux, but still a good example nonetheless) of the core MHDDK functions required (acquireBoard(), releaseBoard(), etc).  You will need to implement the functions at that level in order to port the existing support to OnTime; I would not recommend attempting to re-implement the functions at the level of NI VISA.

We (NI) don't currently have any existing documention or expertise in-house to help with the OnTime port of the MHDDK, but I have heard of other users being successful in the past using the MHDDK with OnTime.  Please take a look at the existing MHDDK O/S interface implementations to help get started.  You may also consider contacting OnTime to see if they have any suggestions or documentation to help with your development.

Hopefully this helps- 

[k_laszlo]

Dear Tom W,

We try to understand and use the Linux example, but we don't solved the problem with this information. Now we think the problem is because the DMA. Under Windows the DMA was programmed with correct values (we don't know the real method). We can use the example under Windows because of the correct DMA register values. Under our On-Time system if we want to use the BAR1 we must know the method of the DMA programming. We can read, and write the BAR0 registers, and we can change the MAP, but we cannot read the whole values of the BAR1. This range is 2000h long. If we read the lower bits, we get 00000000h, if we read the upper bits we can get other constant values.  We try to find information about DMA, and MITE, but we cannot find the needed information on the internet. We think we are very close to the problem. We need some information about the DMA programming, and the MITE programming.

Thank you,

Laszlo Kerpen

[Tom_W_[DE]]

Hi Laszlo-

If you're able to read/write from BAR0 but not BAR1, it sounds like you may not have directed the MITE to enable BAR1.  This is shown in the MHDDK examples as initMite().  The most important line is:

//Tell the MITE to enable BAR1, where the rest of the board's registers are

Bar0.write32(0xC0, (physicalBar1 & 0xffffff00L) | 0x80);

...where physicalBar1 represents the mapped address of BAR1.

Are you performing this function?  How have you verified your communication with BAR0?

Message Edited by Tom W [DE] on 01-28-2008 03:17 PM

[k_laszlo]

Dear Tom W,

For the accessing of physical memory we have used a free software (TVicPort version 4), witch can be downloaded form the site: http://www.download3000.com/download_8050.html.

On the our test computer the BIOS has mapped the 6723 card’s memories to 0xfc006000UL (BAR0) and  0xfc004000UL (BAR1).

We have added to the \TVicPortPersonal\Examples\MSVC\Memory sample application two buttons “Regs On” and “Regs off”

In the first (“Regs On”) event handler the BAR0 was configured for accessing the registers from the BAR1:

void CMemDlg::OnBnClickedButton1()

{

      ULONG pBAR0, pBAR1;

      ULONG pMem0, pMem1;

      pBAR0 = 0xfc006000UL;

      pBAR1 = 0xfc004000UL;

      pMem0 = MapPhysToLinear(pBAR0, 0x1000);

      pMem1 = MapPhysToLinear(pBAR1, 0x2000);

      //Tell the MITE to enable pBAR1

      SetMemL(pMem0, 0xC0, ((DWORD(pBAR1) & 0xFFFFFF00) | 0x80) ); // Equivalent with Bar0.write32(0xC0, (physicalBar1 & 0xffffff00L) | 0x80)

      // Writing output to DAC 0 - setting 5 Volt

      SetMemW( pMem1, 0x24, 16 );     // AO Enable, set immediate mode

      SetMemW( pMem1, 0x80, 0x07DA ); // Direct data register 0 DAC<0>

      UnmapMemory(pBAR0, 0x1000);

      UnmapMemory(pBAR1, 0x2000);

}

The results (changes) can be seen on the next picture.

The problem was, the MITE has mapped not the right area (see the lower picture).

[k_laszlo]

Sorry for reply, but I cannot post the whole things because the forum cannot submit it.

The second opearation has (“Regs off) worked well, mapping off the mapped area by the MITE.

void CMemDlg::OnBnClickedButton2()

{

      ULONG pBAR0, pBAR1;

      ULONG pMem0, pMem1;

      pBAR0 = 0xfc006000UL;

      pBAR1 = 0xfc004000UL; 

      pMem0 = MapPhysToLinear(pBAR0, 0x1000);

      pMem1 = MapPhysToLinear(pBAR1, 0x2000);

      //Tell the MITE to disable pBAR1

      SetMemL(pMem0, 0xC0, 0 );

      UnmapMemory(pBAR0, 0x1000);

      UnmapMemory(pBAR1, 0x2000);

}

 

We tried some cases, but we cannot solved the problem.

If you have any idea, why this program doesn't works, please inform me.

Thank you,

Laszlo Kerpen

[Tom_W_[DE]]

Hi Laszlo-

I would like to verify that you are able to access BAR0 correctly.  Have you verified this somehow?  If so, can you please let me know how?  Can you please post the results of a read of the 32-bit register at offset 0x460 into BAR0?

Thanks-

[k_laszlo]

Dear Tom W,

If we read 32bit register at offset 0x460 the result is: 0x40113112 

We think we can read and write BAR0, because if we write values to it, we can read back well. And if we write BAR0 registers there is some effect, what we need.

I'm going to have a vacation, so please inform my colleague in his email about your ideas: attila.isoczki@knorr-bremse.com

Thank you,

Laszlo Kerpen