Package close ordering logic

To explain the logic behind such a closing order, let me explain first what's expected to happen at the package closing time. Each package configures other required packages possibly depending on its own config parameters, assigns default values to its config parameters that haven't been configured by anyone else, and configures its internal config parameters to be consistent with public config parameters.

If pkgA requires pkgB, pkgA has to close first so it can set all relevant config parameters in pkgB before pkgB can make any configuration decision based on the values of pkgB's parameters. If you turn it around, pkgB can determine that no one sets pkgB's config parameters so they should have default values, which may for example include loading pkgC. Now, pkgA comes next and reconfigures pkgB according to pkgA's needs, but pkgB is already closed and can't bring itslef into a consistent state.

I suspect that this is not working for you because you have a different use case. We are aware that this model doesn't cover all use cases, for example both pkgA and pkgB may require pkgC and require it configured in two different, mutually incompatible ways. Who ever happens to be the last gets to configure pkgC. Please tell me more about your use case, and I'll see if we already have an example that covers that case.

Adding 'requires package B' to package A won't change the order because XDCtools can determine that dependency anyway so the order stays the same. Adding 'requires package A' to package B creates a cycle, and you should get a warning about it. You should avoid cycles, and you can't depend on the cycles broken in any particular order. It just happened in this case that package A still gets to be closed before package B. 

I am starting to understand the reasoning behind this ordering now. I recently added to one of my driver packages the ability to update the Dev.tableSize based on the number of instances. That was a case where my driver package required to make a change to Dev.

The particular situation which is giving me trouble, I have a module which wants to configure a handful of it's own config parameters based on another module's instance's config parameters. Those config parameters for those instances are updated in the users script, and no where else.

below is a code snippet from module A's package close. ModB was useModule'd in ModA's module$use.

// configure all max values
   ModA.NumPowerMonitorDevices = ModA.PowerMonitorDevices.length;
   ModA.NumHotSwapDevices = ModA.HotSwapDevices.length;

   ModA.PowerMonitorDeviceRxSyncEventH.length = ModA.NumPowerMonitorDevices;
   ModA.HotSwapDeviceRxSyncEventH.length = ModA.NumHotSwapDevices;

   ModA.NumVoltageReadingsPerPowerMonitor.length = ModA.NumPowerMonitorDevices;
   ModA.NumCurrentReadingsPerPowerMonitor.length = ModA.NumPowerMonitorDevices;

   ModA.NumTempReadings = LM95214.NumCommands + ModA.NumHotSwapDevices + ModA.NumPowerMonitorDevices;
   ModA.NumVoltageReadings = ModA.NumHotSwapDevices * 2;
   ModA.NumCurrentReadings = ModA.NumHotSwapDevices;

   for(i = 0; i < ModA.NumPowerMonitorDevices; ++i)
   {
      ModA.NumVoltageReadingsPerPowerMonitor[i] = 0;
      ModA.NumCurrentReadingsPerPowerMonitor[i] = 0;
      print(ModA.PowerMonitorDevices[i]);
      print(ModA.PowerMonitorDevices[i].match(/^\/\w*(\d+)/)[1]);
      var devInstInd = parseInt(ModA.PowerMonitorDevices[i].match(/^\/\w*(\d+)/)[1], 10);;
      print(devInstInd);
      // Aux reading
      ++ModA.NumVoltageReadings;
      ++ModA.NumVoltageReadingsPerPowerMonitor[i];
      // For all channel readings
      for(var j = 0; j < ModB.NumPages; ++j)
      {
         if(ModB.$instances[devInstInd].MonitorPageChannelDataDescriptions[j].Valid == true)
         {
            if(ModB.$instances[devInstInd].MonitorPageChannelDataDescriptions[j].CurrentTVoltageF == true)
            {
               ++ModA.NumCurrentReadings;
               ++ModA.NumCurrentReadingsPerPowerMonitor[i];
            }
            else
            {
               ++ModA.NumVoltageReadings;
               ++ModA.NumVoltageReadingsPerPowerMonitor[i];
            }
         }
      }
      print(ModA.NumVoltageReadingsPerPowerMonitor[i]);
      print(ModA.NumCurrentReadingsPerPowerMonitor[i]);
   }

my problem is that all of ModB.$instances[devInstInd].MonitorPageChannelDataDescriptions[j] (which are instance config values) are still the defaults from ModB.xdc.

Maybe this isn't even a package close problem? the users script should finish before package close.

Thanks

The user's script always finishes before packages are closed, and your problem is definitely not related to close() functions ordering. That should be easy to check, just add a couple of print statements to the user script and see whathappens when.
What looks suspicious is that you are accessing ModB instances using the index derived from a parameter in ModA. It could all be fine, but for purposes of testing can you try just listing instances of ModB in the order they are created to confirm that they do have expected values for config parameters. You can add this code at the beginning of close outside of the main for loop and see what's printed:
for (var i = 0; i < ModB.$instances.length; i++) {
    for(var j = 0; j < ModB.NumPages; j++) {
        print(ModB.$instances[i].MonitorPageChannelDataDescriptions[j].CurrentTVoltageF);
    }
}

You have probably seen this guide, but I'll post it again anyway: http://rtsc.eclipse.org/docs-tip/Creating_Configurable_Content. This is the place to check for the order of the config phases.

I added the loop based on ModB.$instances.length as you suggested, and it is reporting back the default value as well, not the values configured in the user script.

ModB.$instances[i].<instance parameter> is the correct way to access instance parameters correct?

the ModB handle i'm using is a global which was set in a module$use function. That should be valid still too correct?