[FlexRIO adapter module] unknown I/O module (NI5791)

[yifengc]

Hi!

I recently reinstalled LabVIEW 2013 and MAX 5.5 together with all other device drivers after an update failure. I am using FlexRIO 7961R with NI5791, and after the reinstallation, the FAM is no longer recognized. When I click on the "status" under my FPGA project, it shows the IO module is "unknown", not matching any of the FAM ID number. 

I have checked through the RIO driver (13.0) and other drivers that might be dependent (FAM support 3.4 etc), the versions seem to be fine. Any idea why this happened?

Thank you!

[[dk]]

Hello yifengc,

You mentioned that you installed LabVIEW 2013, etc after an update failure. What exactly was this update failure? Were these versions of LabVIEW and the drivers the same ones that you had previously had (before the update failure)?

Do you receive the 'unknown I/O module' status when you try to automatically detect the I/O module in the LabVIEW project? What happens when you attempt to manually select the NI 5791 in the General category of the I/O module properties? (Or is this what you have already done?)

Did you reinstall LabVIEW and the drivers from physical media or did you download and install them? If you used physical media, the installation could possibly be corrupt.

I would also recommend trying to a force reinstall of the RIO driver and FAM support as this will make sure that they were installed correctly.

[yifengc]

Hi djDannyK,

To answer your questions:

1. I tried to update NI-RIO from 13.0 to 14.1.1 (I didn't know it was incompatible with LabVIEW 2013 at that time, only saw the update reminder). The failure occurred when 14.1.1 refused to install NI webserver 2014. It half installed MAX 14.0, but DAQmx was still 9.8.0, which was also incompatible with the newer version of MAX. Because of these error I uninstalled MAX, DAQmx, NI-RIO, FAM support 3.4 and their dependent drivers, and then reinstalled the previous version. 

2. I selected the category manually. The status showed the IO module was powered off because it didn't know which adapter module it is (the IO module ID number was different for the first two digits). If I simply took the adapter module out, the project knows that adapter module is not inserted, but if I inserted it back in, it is the same problem.

3.I downloaded the installers and installed them. 

I am currently repairing all modules, and want to try for one more time reinstalling the modules. During repair, I noticed error 1603 occurred a couple of times for drivers depending on DAQmx, but if I tried repairing again the error was gone. Does it mean my DAQmx installer is corrupted? Should I download the installer again?

I also have some other silly questions that I hope you won't mind. How does NI automatically detect the adapter module? Is it possible that a software corruption also causes some hardware changes, say some default values in some addresses change? If so, is there a way to reset the adapter module? 

Thank you!

[David-A]

When you installed FAM support did you make sure that you had RF Adapter Module Support selected?

---

How does NI automatically detect the adapter module?

---

There's an eeprom on the adapter module that has a unique ID that identifies what adapter module it is. If that ID doesn't match the ID that a bitfile is looking for then the initialization fails and the FAM is never powered up. 

[yifengc]

Yes, I checked again, LabVIEW 2013 RF support is selected.

So if the ID doesn't match, does that mean EEPROM could be potentailly changed/corrupted?

[David-A]

Yea it looks like the eeprom was changed. The module ID for a 5791 is 1093765A. I have no idea where that ff93765a module id came from. Has someone been tampering with the eeprom? Also this may sound like a silly question, but how certain are you that what you have isn't a custom FAM that someone made and not actually a 5791?

[yifengc]

Hi,

I am certain it is NI5791 because it is written on the outside of the FAM and the same program worked before.

So if the EEPROM is accidentally changed, is there a way to force the FAM reset? 

[David-A]

You'll want to send it in for RMA and they'll reprogram the eeprom. Any idea what may have changed the eeprom? For example, were you storing configuration parameters on the FAM by writing them to the eeprom?

[yifengc]

The only part a write occurs for FAM is on the FPGA target, where FAM register is configured (I attached the vi). This part of program is completely copied from the ni579x Streaming example. 

Some more questions:

1. I know this was not right, but earlier I manually changed ID number for NI5791 in .fam and CLIP file to this FFxxxxxx number just to see what would happen. The status still showed that it didn't know what the module is, even though it sees the ID for NI5791 is now the same.

2. Is there a way to confirm that FAM is corrupted and need to be repaired, or it is caused by a software corruption, or both?

[David-A]

You can't actually interface with the eeprom from the fpga. You would interface with it using some host side functions. Anything on the host vi that you can think of that would access the eeprom? 

1) I would discourage anyone that stumbles across this thread from changing the ID number in the .fam file. The reason it probably did nothing is that you would need to recompile the fpga vi before changing the .fam did anything since the module ID that the fpga is looking for is compiled into the bitfile. Again though, don't do that. 

2) Tough to say. Modifying the clips starts to muddy the whole situation. You can try running a repair on the FlexRIO adapter module support, but I doubt that will do anything. If possible tracking down what modified the eeprom would be the best next step. That way we'll know if trying to change the eeprom back is safe, otherwise the application might just change it back again. If you can't track down what changed the eeprom then sending it in for RMA is the safest move.