Developer Studio project settings problem

Often when you change the Framework Profile version of an application to compile for a different OpenAT version, settings information is lost and has to be manually reentered.

Usually what is lost seems to be the project’s symbols (e.g. OAT_API_VERSION and WIP_PLUGIN_VERSION can be stripped out of the project for the affected configuration, or not updated to reflect the new profile version), and include directories (e.g. the referefence to “${package_loc:com.wavecom.openat.ide.spm.lib.os.model/}/ADL/basic” could be either gone or not updated to the new version).

When this happens it seems to happen for just one of the configurations, either debug or build, not both. We’ve seen for DS 2.2.0 and also 2.2.1

On the project you have issues, do you remember if the project was created using DS 2.2.X or if it was created with an older DS version, and then you upgraded DS?

It was created on an older version, over a year ago. Also at some point it was renamed, which as I recall required a lot of manual fixes and configuration entries before it would work again. Not sure if renaming a project could trigger these sorts of issues.

The main reason we are changing the framework profile is because we have units in the field running a variety of different firmware versions, so we’ve been compiling for whichever version a unit is running before doing an application update.

Maybe you could confirm whether it is even necessary to do this. Can you take an application that is compiled using say OpenAT framework version 2.35, and install it safely on a modem that is running a newer firmware version, say 7.47? I assume you can’t install an application on a modem running older firmware than the application was compiled against, but can you install it on modems with newer firmware?

Not sure indeed, but it can be…
However, you should be able to fix your project settings, following the procedure below:

  • Go to Window > Preferences > C/C++ > Property Page Settings > CDT Utils property pages, and enable the Display “External Settings” tab option
  • On your project, go to Right click > Properties > C/C++ General > Path and Symbols > External Settings
  • Check that the “Developer Studio external settings provider” is checked for all configurations, and click OK
    Hope that fill fix the issue. Actually, this “external settings provider” mechanism allow to contribute to project settings (macros, include paths) with information coming from other settings (like Open AT project configuration). We have better experience with projects created with 2.2.X, but sometimes with project created with older versions, settings can become corrupted.

There is no universal truth on this topic. About what you can be sure: it is recommended to always use software versions coming from the same Open AT Application Framework set, because Sierra Wireless has made sure they are interworking well together by validating them. After that, versions that are on the same branch (e.g. 2.3X) can usually interwork correctly (assuming the rule you’ve formulated well: FW should be more recent, but never older), but you should always ask before to your Sierra Wireless contact, to check if an interoperability test campaign has been ran on this particular software combination, or if it can be done.