FAM output Voltages disable at PXI startup

[Jeff_Giacone]

Is it possible to "always" have the FAM module powered off until commanded ON?

I see when I have a PXI chassis powered on and no application running on the FLEXRIO FPGA, the I/O on a NI6583, NI6585 and or NI6587 FAM are "live" thus the internal pull ups located inside of the LVDS receiver IC are active...it appears that the 3.3 voltages going to the chips are powered on ...and I/O ports are set to input.

I know there is a Method I can call from my software VI that thurns off the module power which is great....but how can I have the FAM module power stay off until I command the module power on by this method....that is change the default behavior of the FAM?

[Johnnyg17]

Hi Jeff,

You are correct in that the 658X FAMs are powered when the FlexRIO module is powered, even when no user application is running. To better understand what is happening, and some strategies we can implement to get around the default behavior, it's best to go over the process of how FlexRIO Modules power FAMs:

1) When a FAM is inserted, it pulls an identification line low

2) Next, the FlexRIO module provides a single voltage line to the FAM to power to the EEPROM on the FAM and reads back the Module ID of the FAM.

     2a) If the Module ID of the inserted FAM matches the expected IO Module ID of the loaded bitstream (this is the intended IO Module that the bitfile was compiled with), then the FlexRIO provides power to the FAM power rails

     2b) Else, if the Module IDs do not match, all power rails to the FAM are disabled

Given this knowledge, your easiest workaround to prevent power to the FAM before needed would be to make, and then load, a dummy bitfile intended for a non-658X FAM; since FAM power is only provided if Module IDs match, having a default bitfile compiled for another FAM that did not match your 658X FAM would mean the I/O lines would stay tri-stated. Then, when you want to "command" the FlexRIO in to operating with your actual application, you can dynamically load the application bitfile that was made for your 658X FAM.

Regards,

John Gentile

PSE- FlexRIO

[Jeff_Giacone]

John, I was thinking about something like you are suggesting, or even changing the EEPROM ID of the device as an option....

Either options will work in a normal operating mode. In an anomalously condition when the PXI chassis were to be turn off with out writting the "bad" bit file or changing the EEPROM setting, then when the chassis were turned back on the FAMS output voltages would become live...which is not desired.

Jeff

[dklipec]

Short version

If the bitfile loaded at powerup does not support the adapter module, this avoids the case you are describing. Another case might be an unplanned reset - not necessarily a crash, just one where the system comes down without going through the "safe state."

I think that the best option here would be to set a bitfile that doesn't enable power as "Autoload on Reset" (or "Autoload on Powerup"), that way if your system is restart without control, you can guarantee the state is disabled.

Details

You can access this on your device using NI MAX.

If you choose to "Erase Firmware" - but set this to Autoload, it should load the default bitfile (which doesn't support any adapter module).  If you then set this to "Autoload on Reset" you'll always boot up the system with the adapter off.  You would then not download your application bitfile until you are ready to power up the adapter module like John suggested.

Normally, you have to act to put a bitfile in the device flash to autoload - it doesn't get there on its own, or come with anything interesting from the factory.  However, the only way to be sure you don't have a compatible bitfile loaded in the flash is to erase it (or intentionally load a user bitfile that you know won't power the adapter module).

I'll also note that if you don't have an autoloaded bitfile (ie: do not autoload is set), then your system should also not power up in a state where the adapter module could power up.  If you want it to actively blank the bitfile at reset, you have to autoload because the alternative/default is to persist the running bitfile.  You can also only autoload on reset for 795x and 796x and 793x targets.  The 797x targets do not support autoload on reset, only autoload on power up.

[Jeff_Giacone]

Autoload on Reset...is that the Run when loaded to FPGA check box on the Information tab of the build Compilation properties tab?   I don't see the following option in MAX  If you choose to "Erase Firmware" - but set this to Autoload, it should load the default bitfile (which doesn't support any adapter module).  If you then set this to "Autoload on Reset" you'll always boot up the system with the adapter off.   I see an update Firmware button in Max for each FPGA target setting tab.   Is this whole process documented in some help menu or document that I can read more about it...maybe some screen shots of the process.  I found this information that I think shows how to erase the firmware: http://digital.ni.com/public.nsf/allkb/4789525480C3B78C8625714000746BFD  So If I 1st right click on the FPGA target in the project, then select the Download Bitfile to Flash tab. The select Erase Bitfile on Flash button, that should do as suggested. Then click on the Device settings tab, and select Do not autoload VI and click "Apply setting" that should take care of the 2nd thing I need to do.  Compile the FPGA with the "Run when loaded to FPGA" not checked  The last thing would add to the software that using the FPGA bitfile is to add the methods to download bitfile, Control IO Module Power, then run   What do I put in the VI after I close the FPGA reference to insure on power is connected to the Module IO?

[dklipec]

So, "Run when Loaded" is independent of the media that contains/loads the bitfile.  It only impacts whether the bitfile automatically begins executing when loaded (regardless as to whether that is done via Open Bitfile Reference, the Download session method, or automatic load from flash on reboot/power-up).  However, this execution state is independent of the adapter module initialization procedure. which does not depend on the LabVIEW program's state, other than Reset.  Reset is not a "held" state, a bitfile that is reset experiences a digital reset and then enters an idle state.  At reset, the adapter module will shut down, but since reset is not held, it will immediately reinitialize.

The Update Firmware button in MAX is the way to access the functionality I mentioned above (but I omitted that detail).  The page you linked shows how to use RIO Device setup to accomplish this same task, but that method is considered deprecated (it works, and invokes the same underlying code - but I'd encourage you to use MAX as it is the intended user experience).

To restate the process with all steps:

1. Erase Bitfile in MAX via the Update Firmware button (just to be sure it is the default bitfile in flash)

2. Set to Autoload on Reset (can't do this on 797x targets)

3. When you are ready to power up your digital device, open a bitfile reference to it with a bitfile that matches the digital module.  This will download the FPGA, and it will immediately begin powering up your module.

4. If you want to ensure that it is disabled, you can simply power down the module under user control and it will not automatically reenable until the next reset, load, or reinsertion. An alternative (to ensure no event could unintentionally enable the module), would be to load a different bitfile that has no expected adapter module.

5. Unset Close and Reset as an option on the LV FPGA Close method (it is a right-click option). This is because the reset will clear your IO Module disable.

Alternatively, in your last message you mentioned leaving the power on.  If you don't do step 4, but do step 5 (uncheck reset), then your module will remain continously powered until the system powers off (or reboot, if step 2) or you load a different bitfile.  If you want to stop the VI contents and restart them without the adapter module reinitializing, you can call Abort on the session prior to close (which will stop any loops running in the block diagram).  If "Run the FPGA VI" is checked in your Open Bitfile Reference, it will restart those loops the next time you open a session, all without revoking power because there is no reset.

I'll follow up with our tech writers about the documentation on this topic.  The FlexRIO help topic "Adapter Module Interface Protocol" does cover the initialization/load/reset portion of this, but doesn't discuss the impact of "Run" options or autoload.