With the recent Simplicity Studio release (September 12, 2018) Mighty Gecko modules (MGM111, MGM12P, etc.) are now understood as having their own part numbers and so they do not need to be referred to by a SoC part number. This makes it easier to develop projects using modules and it offers the following benefits:
Module Part Number can be used throughout the entire development process and there is no need to even know what IC is used in building the module.
The EmberZNet and Thread SDKs now represent an image of the module instead of a SoC image making it easier to do pin configuration in the hardware configurator.
An example of the last point is shown in these two images:
Figure 1:
The above is the package outline that had previously been displayed for an MGM13P module. The screenshot below is the outline that is now presented for the MGM13P module:
For modules as parts support to happen things had to change on all levels from the purchased part itself, the tools used by Simplicity Studio, Simplicity Studio itself and the supporting SDKs.
Simplicity Studio identifies connected boards by reading an EEPROM on Silicon Labs radio boards that are used with the Silicon Labs Wireless Starter Kit (WSTK) main board. The EEPROM will indicate if the part included on the radio board uses the module part number or a pseudo part number used for the modules that do not have the necessary module identification information. Simplicity Studio will use the detected information throughout the development process (project creation, generation, building and debug) unless the information is manually overwritten using the device configuration dialog boxes from the Debug Adapters view. The observed change in behavior will depend on the information stored in the Silicon Labs radio board and the SDK revision being used. Radio boards with updated EEPROMS are being phased into production and this started happening in the second quarter of 2018.
When a customer's board is connected to Simplicity Studio through the STK / WSTK debug port or with an external Segger J-Link device, the target part must be manually specified using the device configuration dialog boxes and then the module part number should be specified.
Simplicity Commander can be used to check if the module identification information is present or not. This check is just mentioned for reference information as the presence or absence of module information does not affect development flow in Simplicity Studio. Launch Simplicity Commander from the Launcher perspective by either clicking the tools icon (green wrench) or by clicking the Compatible Tools tab in the main window. In Simplicity Commander select the correct debug adapter from the J-Link Device drop down menu and then select the [Connect] button next to [Adapter] and then click the [Connect] button next to [Target]. If the Chip type in the MCU Information box in the lower right is a module part number then the device has the necessary identification information. If the Chip type is a SoC part number then the device does not have the necessary identification information. The first image below shows a module without the necessary identification and the second image shows one with the necessary identification information.
Figure 3: Commander connected to part without Module identification information
Figure 4: Commander connected to part with Module identification information
SDK support for modules as parts started with Gecko SDK Suite version 2.4.0 and all of the protocol SDKs contained within that suite (Bluetooth SDK 2.10.0.0, EmberZNet 6.4.0.0, Thread SDK 2.8.0.0). If a radio board that has the pseudo part number is used with Gecko SDK Suite 2.4.0 or later then a popup will appear notifying the user that the stack being used requires a module part number and it will show the part number change that was made:
Figure 5: SDK Upgrade Notice to Module Part Number
If Gecko SDK Suite versions before 2.4.0 are used with radio boards that use the module part number, the opposite situation is present and a popup will appear notifying you that the stack being used needs to treat the module as a SoC and that the part number has been changed accordingly:
Figure 6: SDK Upgrade Notice to SoC Part Number
Both of these dialog boxes are just informational to alert the user to changes that were made to make the project compatible with the selected part and SDK.
If the part was changed when creating the project then additional warning popups can be displayed when launching the debugger warning of the difference between the target part and the project configuration. Popups like these images are to be expected and it is fine to accept the warning and proceed with the debug session:
If the “Remember my decision” checkbox highlighted in green in the first image above is checked, then the two warning popup dialogs will only be seen the first time that project is launched, after that the selected debug adapter will automatically be used and neither popup will be seen with that project again.
So this is an interim situation and going forward, the newer module parts and Gecko SDK Suite 2.4.0 or later should be used to create project using modules. Then there will be no changes made to the parts during project creation and there will be no upgrade notice popups or debugger warnings for modules as parts.
If behavior is seen that is different than what has been described in this KBA is seen, please submit a support ticket at the bottom of this web page: https://www.silabs.com/community.
Simplicity Studio Knowledge Base
Simplicity Studio now Treats Mighty Gecko Modules as Parts
With the recent Simplicity Studio release (September 12, 2018) Mighty Gecko modules (MGM111, MGM12P, etc.) are now understood as having their own part numbers and so they do not need to be referred to by a SoC part number. This makes it easier to develop projects using modules and it offers the following benefits:
An example of the last point is shown in these two images:
Figure 1:
The above is the package outline that had previously been displayed for an MGM13P module. The screenshot below is the outline that is now presented for the MGM13P module:
Figure 2:
The main take away from this is when developing for a module to always specify a module in Simplicity Studio in either the “My Products” view or for the part connected to a debug adapter. When a custom board is being used the Target part has to be specified in the debug adapter hardware configuration as explained in this KBA: https://www.silabs.com/community/software/simplicity-studio/knowledge-base.entry.html/2016/10/07/simplicity_studiov4-FMQd
For modules as parts support to happen things had to change on all levels from the purchased part itself, the tools used by Simplicity Studio, Simplicity Studio itself and the supporting SDKs.
Simplicity Studio identifies connected boards by reading an EEPROM on Silicon Labs radio boards that are used with the Silicon Labs Wireless Starter Kit (WSTK) main board. The EEPROM will indicate if the part included on the radio board uses the module part number or a pseudo part number used for the modules that do not have the necessary module identification information. Simplicity Studio will use the detected information throughout the development process (project creation, generation, building and debug) unless the information is manually overwritten using the device configuration dialog boxes from the Debug Adapters view. The observed change in behavior will depend on the information stored in the Silicon Labs radio board and the SDK revision being used. Radio boards with updated EEPROMS are being phased into production and this started happening in the second quarter of 2018.
When a customer's board is connected to Simplicity Studio through the STK / WSTK debug port or with an external Segger J-Link device, the target part must be manually specified using the device configuration dialog boxes and then the module part number should be specified.
Simplicity Commander can be used to check if the module identification information is present or not. This check is just mentioned for reference information as the presence or absence of module information does not affect development flow in Simplicity Studio. Launch Simplicity Commander from the Launcher perspective by either clicking the tools icon (green wrench) or by clicking the Compatible Tools tab in the main window. In Simplicity Commander select the correct debug adapter from the J-Link Device drop down menu and then select the [Connect] button next to [Adapter] and then click the [Connect] button next to [Target]. If the Chip type in the MCU Information box in the lower right is a module part number then the device has the necessary identification information. If the Chip type is a SoC part number then the device does not have the necessary identification information. The first image below shows a module without the necessary identification and the second image shows one with the necessary identification information.
Figure 3: Commander connected to part without Module identification information
Figure 4: Commander connected to part with Module identification information
SDK support for modules as parts started with Gecko SDK Suite version 2.4.0 and all of the protocol SDKs contained within that suite (Bluetooth SDK 2.10.0.0, EmberZNet 6.4.0.0, Thread SDK 2.8.0.0). If a radio board that has the pseudo part number is used with Gecko SDK Suite 2.4.0 or later then a popup will appear notifying the user that the stack being used requires a module part number and it will show the part number change that was made:
Figure 5: SDK Upgrade Notice to Module Part Number
If Gecko SDK Suite versions before 2.4.0 are used with radio boards that use the module part number, the opposite situation is present and a popup will appear notifying you that the stack being used needs to treat the module as a SoC and that the part number has been changed accordingly:
Figure 6: SDK Upgrade Notice to SoC Part Number
Both of these dialog boxes are just informational to alert the user to changes that were made to make the project compatible with the selected part and SDK.
If the part was changed when creating the project then additional warning popups can be displayed when launching the debugger warning of the difference between the target part and the project configuration. Popups like these images are to be expected and it is fine to accept the warning and proceed with the debug session:
Figure 7: Select Compatible Device Warning Popup
Figure 8: Connected Device Compatibility Warning Popup
If the “Remember my decision” checkbox highlighted in green in the first image above is checked, then the two warning popup dialogs will only be seen the first time that project is launched, after that the selected debug adapter will automatically be used and neither popup will be seen with that project again.
So this is an interim situation and going forward, the newer module parts and Gecko SDK Suite 2.4.0 or later should be used to create project using modules. Then there will be no changes made to the parts during project creation and there will be no upgrade notice popups or debugger warnings for modules as parts.
If behavior is seen that is different than what has been described in this KBA is seen, please submit a support ticket at the bottom of this web page: https://www.silabs.com/community.
Thank you,
jpitt