Driver Development Kit (DDK)

cancel
Showing results for 
Search instead for 
Did you mean: 

pcie-6509 register level programming: can't access slave ASIC

Solved!
Go to solution

I am running one of the RLP examples (boardBringUp.cpp) using the RTX OS.

 

The program is crashing when I try to access the 'slave' STC3 ASIC.  When I try to read the slave ASIC signature or when I try to access the DIO ports beginning at port 6 which is the first port on the slave STC3.

 

Any ideas on what to try ???

0 Kudos
Message 1 of 7
(10,545 Views)

Tim4software wrote:

 

The program is crashing when I try to access the 'slave' STC3 ASIC.  When I try to read the slave ASIC signature or when I try to access the DIO ports beginning at port 6 which is the first port on the slave STC3.


Hi Tim, this is a suprising problem.

 

First, I would confirm that the hardware is fully functional. When you place this card in a Windows PC with DAQmx installed, does it pass the self-test in the Measurement and Automation Explorer, and can you access the slave ports from the test panels [1]?

 

Second, what is the nature of the crash?

 

Third, if you remove the slave accesses from the boardBringup example, what output do you see?

 

[1] Using Test Panels in Measurement & Automation Explorer for Devices Supported by NI-DAQmx

http://www.ni.com/white-paper/4638/en

Joe Friedchicken
NI Configuration Based Software
Get with your fellow OS users
[ Linux ] [ macOS ]
Principal Software Engineer :: Configuration Based Software
Senior Software Engineer :: Multifunction Instruments Applications Group (until May 2018)
Software Engineer :: Measurements RLP Group (until Mar 2014)
Applications Engineer :: High Speed Product Group (until Sep 2008)
0 Kudos
Message 2 of 7
(10,500 Views)

Hi Joe, Thanks for getting back to me with a detailed test plan.

 

My 3 PCIe-6509s are running on an industrial PC (from Trenton) that is running Windows 7.

 

I "uninstalled" one of the cards from RTX and restarted the PC so that the card would come up as a windows device.

I then used DAQmx to self test the card and to manipulate some ports (both master ASIC ports and slave).

Self test passed and I was able to manipulate slave ports.

 

I was not able to build a debug version of the application under Visual Studio 10 due to linking errors between conflictinig RTX and microsoft libraries.

I was successfull (but it wasn't easy) building a release version of the rtss.  So I have not been able to debug the crash.  All I know is that it is an access violation.

 

Here is the output generated by boardBringUp with some extra prints added by me.

 

Device Information
  Device                : PCIe-6509
  Product ID            : 0x7326
  Number of Ports       : 12
  CHInCh signature      : 0xC0107AD0
  STC3 Lo signature     : 0x08050501
  STC3 revision         : B
  Serial number         : 0x0186791C
  Programmable Resistors: Yes
eeprom: got power up state for port = 0
eeprom: got power up state for port = 1
eeprom: got power up state for port = 2
eeprom: got power up state for port = 3
eeprom: got power up state for port = 4
eeprom: got power up state for port = 5
eeprom: got power up state for port = 6
eeprom: got power up state for port = 7
eeprom: got power up state for port = 8
eeprom: got power up state for port = 9
eeprom: got power up state for port = 10
eeprom: got power up state for port = 11
eeprom: got port resistor direction for port = 0
eeprom: got port resistor direction for port = 1
eeprom: got port resistor direction for port = 2
eeprom: got port resistor direction for port = 3
eeprom: got port resistor direction for port = 4
eeprom: got port resistor direction for port = 5
eeprom: got port resistor direction for port = 6
eeprom: got port resistor direction for port = 7
eeprom: got port resistor direction for port = 8
eeprom: got port resistor direction for port = 9
eeprom: got port resistor direction for port = 10
eeprom: got port resistor direction for port = 11

       | Powerup Configuration | Pull-up/Pull-down Resistor |  Input State  |
| Port |   Output  |   High-Z  |        Configuration       |               |
|------+-----------+-----------+----------------------------+---------------|
|   0  |    0x00   |    0xFF   |              0x00          |      0x00     |
|   1  |    0x00   |    0xFF   |              0x00          |      0x00     |
|   2  |    0x00   |    0xFF   |              0x00          |      0x00     |
|   3  |    0x00   |    0xFF   |              0x00          |      0x00     |
|   4  |    0x00   |    0xFF   |              0x00          |      0x00     |
|   5  |    0x00   |    0xFF   |              0x00          |      0x00     |
|   6  |    0x00   |    0xFF   |              0x00          |      0x00     |
|   7  |    0x00   |    0xFF   |              0x00          |      0x00     |
|   8  |    0x00   |    0xFF   |              0x00          |      0x00     |
|   9  |    0x00   |    0xFF   |              0x00          |      0x00     |
|  10  |    0x00   |    0xFF   |              0x00          |      0x00     |
|  11  |    0x00   |    0xFF   |              0x00          |      0x00     |
finished writing to CHInCh first pass
finished writing to CHInCh second pass
finished writing to scratch pad of master STC3 pass 1
finished writing to scratch pad of master STC3 pass 2

 

It crashes here when the code tries to write to the scratch pad of the slave STC3.

0 Kudos
Message 3 of 7
(10,492 Views)

Hello,

 

Thanks for this information. From looking at the output, I see that you are already communicating correctly with the slave STC3. Ports 6 thru 11 are on that ASIC and the example is checking the StaticInputValue for each port.

 

While it is troubling that we cannot access the scratchpad register for self test, you may be able to use the other examples.

 

To further troubleshoot this issue, I recommend modifying the "ChipObject read and write functions" to print out the offset and data of the register it is writing/reading. For example, add prints to:

 

inline void tChpServices::tReg8IODirect32::write as well as the other functions (repeat for all chip objects).

This will help us see if anything special is happening on this particular access.

 

Thanks,

Steven T.

0 Kudos
Message 4 of 7
(10,486 Views)
Solution
Accepted by topic author Tim4software

I just noticed that the RTX operating system layer was not modified to work with the PCIe-6509. The os layer only allocates 0x40000 bytes for the card's retgisters. The problem is that the scratchpad register for the slave STC3 is at 0x40004, causing the problem. You can modify the osiUserCode.cpp to allocate more memory for bar0. I recommend 0x80000.

 

Thanks,

Steven T.

0 Kudos
Message 5 of 7
(10,481 Views)

Actually I commented out the actual reads of the StaticInputValue registers for ports 6 to 11 to make the boardBringUp example work per Joe Fried Chicken's advice.  So I am NOT reading any slave port registers (if I do I crash).

 

I actually started on the dioex1 example but couldn't get that to work either because of accessing slave STC3 registers.

 

Is there anything specific that needs to be set up at a low level in order to get the interface between the master STC3 and the slave STC3 working ??

 

Is there a little mini test or a register that I could read to see if that link is set up correctly?

 

I don't think I will be able to build a 'debug' version of the rtss since RTX apparently does not support the debug version of the C runtime when STL is used.

0 Kudos
Message 6 of 7
(10,480 Views)

bumped up the memory allocated for bar0 in the osiUser code from 0x40000 => 0x80000 and now it works.

 

thank you Steven T and Joe Fried Chicken for your help.

0 Kudos
Message 7 of 7
(10,477 Views)