I/O ports read access of the PCI6509 board

[auster1805]

Hello,

we use the PCI6509 I/O board in a PC (x86 processor). The Operating System is VxWorks 5.5. So we manage the board by programming directly the registers of the board (for help, we have downloaded the following documentation http://www.ni.com/pdf/manuals/371580a.pdf).

In order to validate the board for the required functions of the PC, we performed a few tests (read/write I/O ports, interrupt management). We have noticed a strange behavior. We will describe hereafter this problem, may be it is a known problem by National Instruments, so you could confirm us the problem or tell us which mistake we did.

Description of the test and problem:

1°) PCI configuration: BAR1 address set to 0xFE908000

2°) the ID and revision register are correctly read by our software

3°) we program the port number 0 in output direction and the byte 0xA5 is sent to this port (address offset 0x40)

4°) we connect the SCB-100 board from National Instruments to the PCI6509 board, we check with a measurement equipment that the TTL output correspond to the byte "A5" previously sent

5°) then, with the SCB-100 board, we connect the port number 0 to the port number 1 by using wires

6°) by managing the registers, we configure the port number 1 in input direction (byte 0x01 to the address offset 0x51)

7°) we write the bytes 0x59 and 0x58 to the following address offsets: 0x52, 0x53 (port number 1)

8°) we read the bytes to the following address offsets: 0x50, 0x51, 0x52, 0x53 (port number 1)

9°) we expect to get in this order the following bytes: 0xA5, 0x01, 0x59 et 0x58, but we get 0x58, 0x59, 0x01 et 0xA5, it is very strange, the order is different

How is it possible? We perform bytes read access (no problem of little/big endian)

It seems that the access to the registers of the I/O ports is different between read operation and write operation.

For write access, the address offsets are the ones described in the NI documentation, but for read access, a permutation of the address offsets have to be applied in a 4 contiguous bytes group.

Is it a real problem known by National Intruments ?

Thanks to confirm before we carry on our software development.

[Steven_T]

Hello Auster,

We have not noticed this behavior at all on a windows system. I did the same setup as you and got the expected values at the expected offsets. There is something about your particular system that is doing this. Reads to PCI registers should be done one at a time and should flush any PCI writes that may be cached.

Does this happen with other ports besides port1?

Is the behavior on your system predictable enough to work around?

Do you need to understand this issue further to proceed?

Thanks,

Steven T.

[auster1805]

Hello Steven,

First, thanks a lot for your answer.
But i don't understand how this strange behaviour can happen.
Because we have added another kind of PCI board on the PCI bus of the PC (it is a specific board for HDLC dialog with other equipment).
And we performed the same write/access operations for this new board : for 4 contiguous bytes adresses (0xFE900060 to 0xFE900063), we write the following bytes in this order 0x41, 0x42, 0x43 and 0x44.
Then we read the bytes at these adresses and we get : 0x41, 0x42, 0x43 and 0x44, no problem in this case, that was completely expected.

It means that identical write/read access lead to different results between the PCI6509 board from NI and another board.
We did not check for the I/O ports beyond port1, but the results are always the same for port1 (completely predictable).
I can't explain this behaviour and i don't know which other test to realize in order to understand better the problem .
If you have any idea, it will be very useful for us, please.
I couldn't do other tests on our system before end of the year, but your answers will be wellcome.

Best regards
Christophe D.
THALES

[Steven_T]

Hello Christophe,

This problem does not happen here at all. Since other cards and some offsets (ID and signature) function correctly, I would like a little more information.

1. Please provide a log of all register accesses in your test that shows the problem. In our DDK examples, we have chip objects that funnel all register writes/reads into functions based on the size of the register. With this setup it is really easy to save all information about data, register offsets being written to/read from, and size information while running your test program.

2. You've mentioned several times that you are reading/writing the registers one byte at a time. What VxWorks system functions are you using?

Thanks,

Steven T.

[auster1805]

Hello Steven,

to help you to understand, you will find attached a Word document which contains the instructions in C language

we wrote in order to manage and check the PCI6509 board in our system (VxWorks 5.5, x86 processor) .

Highlighted in red at the end, the specific read access to the registers .

Thanks

Christophe D.

[Steven_T]

All of the configuration performed by your test system is done by Windows without me needing to do it. I started doing register accesses with the "mapping the PCI MITE, IO Window initialisation" comment. Again I did not see any issues or misordered data.

I'm noticing there that you are attempting to read data from each port in a loop.

IOPortData[numero_port]=*((int*)(valeur_bar1 + 0x40 + 0x10*numero_port+3));

This is wrong because offset bar1 + 0x43 is not aligned to perform a 32-bit read operation. I actually get errors when I try to do this.

I also noticed that you read all of port 0 and port 1 in your example. I know you are not able to try it now, but I am curious to see if other ports behave the same way. I am unable to reproduce this problem. Again, it does not happen on windows using VISA to perform register reads and writes.

Steven T.