Accessing TNT-5002 Register Sets

[BACcA]

Following are my last questions.
We need to be confident about a few concepts, say the algorithm in itself. Please could you confirm/answer to every sentence below:

1) The only settings required, starting from reset and after the PCI initialization, to access the 4882 register set is writing (PBAR0+0xc0) location in the PCI space with (PBAR1+0x80) value, i.e. in C_likenotation: *(PBAR0+0xc0)=PBAR1+0x80; for any other register default values are correct (i.e. nothing else should be set from reset).

2) at this point just reading PBAR1+0x117 we should get 0x4c (i.e. the signature), i.e. something like if(*(PBAR1+0x117)==0x4c)printf("Now it works!"); please confirm explicitly there is nothing more to do to access them and direct addressing is the right procedure to do that (i.e. DMA is not required but only optional). By the way please could you specify what offset is the right one because we got two values in the last replies (i.e. either 0x017 or 0x117 from PBAR1).

3) PBAR1 is in PCI "memory" space, i.e. not in "io" space. Please confirm that.

Please notice that if above points are the only required this does not work at all, providing just zeroes in all the PBAR2 space. We tried the same stuff with an INTEL IXDP425 evaluation board and NI'sPCI-GPIB board with exactly the same results. This seems to exclude hardware implications. Furthermore we tried to access PCI addresses by register-programming the processor, in order to avoid any operating system interference, always without improvements (i.e. everything can be accessed but the PBAR2 area, still filled with zeroes).

4) Please explain what is stored at addresses (PBAR0+0x470) and (PBAR0+0x4f0): NI's software initializes them at the start-up (i.e. in the same routine that sets IODWBSR but there is nothing about in the component's manual. Please comment.

We are quite worried about some setting may be implemented in NI’s drivers but not disclosed in any manual or official way that could prevent us from using the device unless by NI’s drivers (a bit complex for our embedded application).

5) We are using the PCI clock as the only internal clock for the device. Please confirm it is allowed and the only required setting for that is pin USE_PCI_CLK pulled at high level.

6) Please carefully check the TNT5002 connectivity provided by the attached schematic diagram (pdfformat) in order to confirm hardware is as expected.


We are somehow sceptical about errors in the PCI bus connectivity because anything in PBAR0 can be read and written and the action caused by bits toggling are those expected. May be some TNT5002 specific pin could be wrongly connected. A check in this sense should be easy to you.


7) Please suggest any other default value stored in the lower sector of PBAR0 (i.e. near to IODWBSR) that could help us to check our addressing correctness (i.e. what should we find and where).


Just to summarise we are struggling for an apparently trivial issue that, just because trivial, has been check in deep detail without getting any improvement: this seems to suggest some missing action/setting. Please could you suggest any other way to proceed or send us some piece of software to be run under either Windows or Linux and NI’sPCI-GPIB card and showing the device signature, just to check if the above procedure is correct in itself on a totally different environment.
---------------------

[devguy]

1) Yes, that's correct. Nothing else is required to write/read the GPIB Register set. I have tried this myself on a PCI-GPIB board without any NI driver loaded.

2) Also correct. The manual says offset 0x117 from PBAR1, but I found that 0x17 works too. Stick with PBAR1+0x117. I read 4C without a problem.

Please could you explain in detail how did you do that in order to try by ourselves with a PCI-GPIB board. Please could you send also the PBAR settings you used.

7) PCI Config space should be mirrored at PBAR0+0x300 according to the diagram on page 3-3 of the manual. Thus, at PBAR0+0x300 you should find the Device ID and Vendor ID. The full 32-bit word should be 0xC8501093. Try to read it in 8-bit increments to make sure it's correct as well.

As said we are able to read and write EVERYTHING in the PBAR0 area, including the PCI configuration stuff. What we are NOT ABLE to is reading  the 4882 register area in PBAR1, including data at 0x117 displacement. My question was about any stuff we could read as verification near the IOWBSR register, in order to check if we are really reading that area.

😎 New question: could be the JTAG pins responsible for not getting anything out of the device? Please could you check with the schematic we already sent. Is the PCI-GPIB board schematic diagram available somewhere? 

Regards

[Collin M]

1.  Yes, this is correct. Can you verify at run-time that you are reading PBAR1 correctly, and also read PBAR0 + 0xC0 to make sure that register was written correctly?

2. At this point reading offset 0x117 in PBAR1 should give 0x4C. The GPIB specific registers are located at offset 0x100 in PBAR1.

3. PBAR0 and PBAR1 are both located in memory space, not IO space. You mentioned PBAR2. PBAR2 is not implemented in the TNT5002. Was this a typo?

4. Registers at offset 0x470 and 0x4F0 in PBAR0 are for legacy applications and should not be modified.

5. If USE_PCI_CLK is pulled high then an external 40MHz oscillator is not necessary. What value resistor is being used to pull this high? Have you measured the voltage at the pin?

6. I did not see an attachment but would be happy to review one. There used to be an example schematic posted at ni.com but seems to have disappeared, I'll try to find the example schematic and direct you to it.

Some things to check:

1. Can you read offsets 0x0, 0x4, 0x10, and 0x14 in PCI config space and post the results?

2. When you read PBAR0 and PBAR1 are you reading them using a PCI configuration access or memory access? Do the values read through using memory accesses and config accesses match?

3. Can you verify that PCI reset is not asserted?

I agree this is probably something simple and shouldn't take too long to figure out.

[devguy]

Hi dittohead,

thanks for your support, we are literally getting crazy here for something apparently trivial but still hard to be fixed.

Please find some answer to your questions:

1) How? In PBAR1 we should read the device registers but we get just zeroes. Is there anything else to read? In PBAR0+0xC0 we read what we previously set (i.e. PBAR1+0x80).

2) Here is the issue: we read zero and we cannot modify anything out of there. We tried with both 0x017 and 0x117 and we did a search in PBAR1 for anything not null, without results.

3) PBAR2 is my mistake. After the PCI configuration we see only PBAR0 (size=0x800) and PBAR1 (size=0x4000), as expected.

4) OK

5) Is is more than 3V, by a 10K resistor.

6) A reference schematic could help. Please find attached our own (PCI/GPIB sheet).

Some things to check:

1) I can read them by both the PCI handling functions and direct memory addressing in PBAR0+0x300 (same values, as expected).

*(0x0)   = 0xc8501093

*(0x4)   = 0x02800003

*(0x10) = 0x01000000

*(0x14) = 0x01004000

*(0x40) = 0x0000b4a8

and

*(0x010000c0) = 0x01004080

*(0x010000c4) = 0x0100608c

2) As said for PBAR0 I can use both ways with the same results. For PBAR1 I tried only memory mapping: should PCI configuration access work also for PBAR1?

3) PCI_reset is at a stable high level (again 3V3). It goes down at the  PCI initialization as for the PCI specs. A pull-down resistor keeps it low during the power-up.

I am not confident about setting properly IODWBSR: is there some other register/memory location near to it I could read in order to verify if we are addressing the expected area? I mean something in PBAR0 but not in the PCI configuration table.

Additional questions:

- our PCI space assignment seems different by standard PC because PBAR0 address is lower than PBAR1. Could it be an issue? (I tried also swapping them without improvements).

- you suggested to check the PCI reset. Would you expect a similar behaviour if the device is in reset status? Could you check please.

In the beginning we tried also with an Intel IXDP425 Evaluation Board and NI's PCI-GPIB card. That development board has four standard PCI slots. We got the same problem (same software). Now, could you suggest any mean to check the signature in PBAR1+0x117 in a standard PC (either Linux or XP)? We can easily verify/modify under Linux the PCI settings of the card but we are struggling with direct memory mapping of assigned PBAR spaces. May be you could suggest a workaround/patch/utility for that. Being confident about something could help now.

Back to our design, it seems like we are not able to read anything in PBAR1 but: what is the difference between PBAR1 and PBAR0 in the PCI addressing? If we are able to read the PCI configuration table memory remapped in PBAR0+0x300 I do not see any reason because PBAR1 addressing could fail (please advise if you see any potential flaw in this assumption). Still I am not confident about writing the expected value in IODWBSR because I have not any confirmation, its readback value apart.

Regards

[devguy]

The attachment ...

[Collin M]

Try removing the pullup resistor on TRST. This pin has an internal pulldown to keep it in its unasserted state.

Can you verify that R217 is populated and measure the voltage at the pin?

I don't think the assignments of PBAR0 and PBAR1 by the BIOS will be an issue.

When you use the the IXDP eval board and an NI PCI-GPIB, are you able to read offset 0x117 in PBAR1? You could either load the NI-488 linux driver and let it configure the board or manually configure it using some register access utility.

PBAR0 and PBAR1 are just different memory ranges in the TNT. There shouldn't be anything different about the two other than the write to IODWBSR.

[devguy]

I removed the pull-up from TRST (now it is low level): no change.

About R217 I replaced the value with 220R. The voltage on the pin is still 3.26V, same as "mode" pin.

We tried also some other test: we can easily access DMA registers in PBAR0 but still nothing in PBAR1.

Disabling the PCI clock the board hangs and with the pci-reset asserted we get scratch everywhere - this seems to exclude the issue is caused by those signals.

We are programming now the processor at register level in order to avoid any operating system issue but nothing changed. It seems uneasy the problem is there.

Just as a feeling, it seems that everything in the PCI works fine. We can move the BAR windows and we get data only addressing within those windows. We can disable either PBAR0 or PBAR1 by PBACOR register, we can change their sizes by the same register and everything seems to work as expected with the only problem data retrieved from PBAR1 is always zero.

From the datasheet it seems that the PCI section could live without accessing the 4882 register set if mode is set wrong. May be this is a simplified view but it seems exactly this way, i.e. everything in the PCI area can be accessed but not the additional register set(please see the attachment).

[Collin M]

Can you confirm you are doing an 8-bit register access to offset 0x117 in PBAR1, as opposed to a 32-bit access? The register accesses to the DMA registers and other registers in PBAR0 should be 32-bit accesses, but most accesses to the GPIB registers (starting at offset 0x100 in PBAR1) should  be 8-bit accesses.

[devguy]

Not too easy answering without doing some test: in theory we were accessing the PBAR1 area at byte level. But with a Xscope we found the IXP425 always makes read accesses at 32 bit, i.e. all c/be signals are active (low) when accessing the a PCI device in  read mode.

Please notice we are using register programming of the IXP425 device, where we can explicitely set what c/be configuration we'd like on the bus. But in read mode our settings are ignored (not the same in write mode, where settings are kept). It seems like the processor only enables "prefetch" accesses to targets, whilst the TNT5002 seems not to provide prefetching (PBAR's bit3 = 0).

I do not know if it could create any problem to the GPIB device itself, nothing seems specified in its manual about that nor any timing is provided for PCI mode.

Any suggestion about how to check this point (i.e. what the NI device does expect for PBAR1 accesses)?

[Collin M]

Performing a 32-bit access to the 4882 registers will result in unpredictable results. I'm not sure why all C/BEs are asserted when doing a byte access from the processor. Through what means are you reading the TNT registers? Do you have a function or do you de-reference a pointer? If you are using a function is there a parameter that indicates the access size? Or is there a different function for byte-level accesses? If you are de-referencing a pointer to read registers, it may be necessary to do so in a different way as when reading 32-bit registers.

What operating system are you using?

Also, what software are you using that writes of offset 0x470? This register should not be modified for the TNT5002.