Analog output stops, Status 1 Register gives weird value

[Thorsten_Jens]

I output analog data on a PCI6733, FIFO interrupt on half full FIFO. Works so far, but after a time (the time differs greatly) the output stops, and in the interrupt handler I read a value of 0xffff from the AO Status 1 Register (which is strange, as it means that the FIFO is half full, empty and full at the same time). Has anybody encountered this before?

[Tim_Ousley]

Thorsten,

0xffff is also the value read from memory that does not contain a register.

Are you accessing the AO_Status_1 register directly, or using the Window Address Register? There could be a race condition.

Tim

[Thorsten_Jens]

I used the windowed access, but reading directly produces the same broken behaviour 😞

I also checked the register offset, it's the same a in previous reads, so no overwrites it by accident.

The last interrupt before the loss is hadled correctly, I also checked that: Status Register changes from 0x8023 at beginning of ISR to 0x2021 at the end.

[Tim_Ousley]

Let me know if I am describing your system correctly:

You configure the board for AO, load the FIFO, and start the waveform generation. You keep the FIFO full by an interrupt service routine (ISR). While the AO generation is continuing, only the ISR accesses registers on the board.

At the start of the ISR, it reads the AO_Status_1 register and normally reads 0x8023 (Interrupt_B_St, AO_UPDATE_St, AO_FIFO_Request_St, and Pass_Thru_1_Interrupt_St). After the ISR fills the FIFO it checks the AO_Status_1 register a second time and reads 0x2021 (AO_FIFO_Half_Full_St, AO_Update_St, and Pass_Thru_1_Interrupt_St).

The error occurs when the ISR first reads AO_Status_1 and sometimes reads 0xFFFF instead of the expected value(0x8023). No code other
than the ISR accesses STC registers after generation starts.

If all the above is true, then we can be fairly sure that the ISR is not actually reading the AO_Status_1 register when it gets the error. For instance, the G1_TC_St shouldn't assert in relation to AO generation.

It looks like the ISR is reading an address that does not contain a readable register. This might be caused by a race condition involving windowed register accesses. It may be caused by an incorrect register address, by a loose PCI card, or possibly bad hardware.

Check if other register reads are also 0xFFFF, which would indicate confirm that the problem is not specific to AO_Status_1. You could log a timestamp of each ISR entry and exit to check for race conditions. You could also re-seat the PCI card, or swap it out with a backup if available.

[Thorsten_Jens]

Your description is mostly correct, yes. From a certain point in time, I read 0xFFFF *every* time (from every register I tried, both DAQ-STC and card-specific). I checked the register addresses, they do not change.

I'll try re-seating the card (I don't put much hope into that, because rebooting and thus resetting the card resolves the problem), but I don't have a backup card. I'll let you know what happens.

[Thorsten_Jens]

- The card is definitely not loose.
- The register address is the same as always, so that's also OK.
- Only one ISR can be active at any point, so there can be no race conditions. The ISR does not use windowed access.
- No other code in my driver is active at that time.

I am really at my wit's end here. Could the MITE chip be in some condition that blocks access to the card's registers? Since it's the one that handles the PCI stuff.

[Tim_Ousley]

The MITE could be reprogrammed to disable register accesses to BAR1, but all MITE registers on on BAR0. I doubt your code writes to BAR0 after the initial MITE configuration though.

Once the 6733 reads only 0xffff, does the board start working again once you reload the driver? Some other variations to try are:
1) reload your driver
2) run one of the MHDDK examples for a 6713, any of them
3) read BAR0 registers on the MITE, such as offset 0x460 (32bit) which is the MITE Chip Signature register.

We are just looking to see whether the HW is in an undetermined state or if it is the SW. #3 checks whether just BAR1 is not responding, or if BAR0 is also not responding.

Also, which OS are you using?

[Thorsten_Jens]

I am using Windows 2000 (SP4).

Reading from the MITE @ 0x460 gives me 0x40133111 while everything is working and, like everything else, 0xffffffff when the interrupts stop.

Completely unloading the driver via Device Manager -> Disable, Enable can make the card work again. I do a software reset on driver load (AOPersonalize() and so on).

I have not been able to run any of the MHDDK samples yet.

[Tim_Ousley]

Since the MITE chip signature register is not valid either, we can rule out a misconfiguration of BAR1.

Since reloading the driver causes it to temporarily work again, we can say that it is probably a software error and not broken/loose hardware or a bad PCI slot.

Something about the Device Manager->Disable, Enable makes the card work again either in the OS, or in your driver. You could try re-executing all the code in your driver without reloading to see if that works, or research what Windows 2000 does during a PCI driver disable/enable.

One possibility is that something else on your system is trying to talk to the card at the same time. Do you have any NI drivers installed on the system that might t
ry to talk to the DAQ card? (NI-DAQ, NI-VISA?)

Another possibility is that the OS is changing page tables while your driver is running, so that a pointer address which used to point to the HW would point to a different location. I'm not familiar with the Windows 2000 driver model, but you may need to lock down the memory region you are using to keep the OS from moving it.

[Thorsten_Jens]

If it was just the misreadings, I could see it's a software error. But why should the interrupts stop? I definitely don't stop them.

There are no other drivers accessing the device, and I don't think there could be any, I think Windows forbids that.

The pointer is in nonpaged memory. I need to remap the card's memory space, so that is in nonpaged memory, too.

By the way, thanks for the support.