package close, module$use, and platform packages

So when does the platform make it's way into the configuration process?

And should runtime modules be used / called / instances created in a platform?

Here is a very much unfinished guide about creating platforms: http://rtsc.eclipse.org/docs-tip/Creating_Platform_Packages. The figure on that page shows when are the various Platform functions invoked. Platform modules are special in the sense that they have some additional functions that are invoked by the config shell (getExeContext for example), however their standard module and package functions are invoked in the same way and in the same time as for other modules. There is no any other doc that describes these standard functions and their order of invocation other than http://rtsc.eclipse.org/docs-tip/Creating_Configurable_Content, so I'll have to use that one to explain what could be happening.

The first thing to mention is that all package.close and module$use functions are invoked after the user's script. For each package in turn, all its module$use functions are invoked first and then package.close is invoked. Then the next package is selected, and so on. Packages are ordered only to the extent that if package A references package B in any of its XDC spec files, or in any of the functions that can run in Phase 2, package A's module$use and close functions will be invoked first. If there are no references established that way, these two packages can be closed in any order. Note that if a reference is established in module$use, it's too late to affect ordering because B.close may have already run by the time module$use in package A makes a reference to package B. That could be caused by a third package or the user's script calling xdc.useModule for a module from B. I suspect that the platform package is package A and your other module is in package B in that scenario.
If your platform unconditionally uses a module from package B, you should than call xdc.useModule for your other module in the platform's instance$meta$init function.
That should fix the problem if my assumpions are correct. You can add some debug print statements in the relevant functions and see in which order those debug messages are displayed.

Let me know if you have more questions. I know this aspect of RTSC is little bit tricky, and I can see that some important facts are not documented, so I'll update the docs along with answering this and any further questions.

That certainly sounds like the issue at hand. and I tried moving the useModule call into the module$meta$init, and now i get a new error:

TIME=02:07:12.013 PM -- xdc: xdc.useModule called on prog.drivers.MCP23009 from prog.catalog.arm.cortexm4.progArmM4init (useModule, all)
js: "/home/Norton256/p4/tidsp/ti_rtsc/bios_6_34_01_14_extra_arm_targets/packages/ti/sysbios/family/arm/Settings.xs", line 416: TypeError: Cannot read property "catalogName" from undefined (/home/Norton256/p4/tidsp/ti_rtsc/bios_6_34_01_14_extra_arm_targets/packages/ti/sysbios/family/arm/Settings.xs#416)
    "/home/Norton256/p4/tidsp/ti_rtsc/bios_6_34_01_14_extra_arm_targets/packages/ti/sysbios/family/arm/Settings.xs", line 568
    "/home/Norton256/p4/tidsp/ti_rtsc/bios_6_34_01_14_extra_arm_targets/packages/ti/sysbios/family/Settings.xs", line 209
    "/home/Norton256/p4/tidsp/ti_rtsc/bios_6_34_01_14_extra_arm_targets/packages/ti/sysbios/family/Settings.xs", line 121
    "/home/Norton256/p4/prog/dev/MCU_RTOS_DEV/program_common/rtsc_common/prog/catalog/arm/cortexm4/progArmM4init/BoardAMaint.xs", line 10
    "/home/Norton256/p4/prog/dev/MCU_RTOS_DEV/program_common/rtsc_common/prog/platforms/BoardAMaintPlatform/Platform.xs", line 11
    "./package/cfg/BoardAmaint_pm4g.cfg", line 135

It seems that this is happening so early now, that it is killing the sysbios family settings code.

Using a requires statement to the platform module produces the same error.

Thanks

it looks like my problem may be that I'm trying to do too much before getExeContext is called?

You will certainly hit fewer issues if you use that other module at the very end of getExeContext, and it's still early enough.

I added the module right before the return statement in getExeContext and it is still producing the same error. It looks like something slightly after getExeContext must be using the return value to initialize the pieces which are giving me trouble.

My next attempt was to move the offending useModule in my platform.xs file into the platform's package.xs close function. I then added requires statements to the package.xdc files to help resolve the packages being closed in the correct order. I suspect the requires statements cause it to crash even sooner, since the platforms module$meta$init function does not even execute (my print statement did not show up).

This is turning into a tough nut to crack. I really like xdc and what it has to offer for re-use. And BIOS is a really nice small OS. I really want this to catch on more at my company, but If i have a tough time making these hardware platforms running it easy to set up, it is going to make things more difficult.

Your order of operations of what I would like to occur is correct. I think my fundamental problem is that I'm trying to use the Platform package in a manner in which it was never intended.

I'm attempting to configure all of the hardware for the board. From configuring GPIO to loading the drivers for all the peripherals which are present on that board. I attempted to associate a "Platform" with a specific piece of silicon on a specific PCB. More than just a memory map and a way to stuff device specific boot code into the process.

Maybe I just need to add a meta function to the platform which just needs to be called in the users script.

It is in device support check that it is dying.