At Silicon Labs we highly value your feedback and always strive for improvement. Please share your experiences with our IoT development tools by filling out our short survey.
Your feedback will help us focus our improvements to serve you better, and it should take less than five minutes of your time.
The latest updates to Windows 10 and Windows 7 have caused reported issues with Silicon Labs' Toolstick adapters, 8-bit debug adapters, and 32-bit debug adapters.
The reported behavior is that the debug adapters do not enumerate properly. Affected devices will not show up in the Windows Device Manager. Example bug reports are linked below.
If you are running into these issues you can try to roll back the above updates. However note that Microsoft places some restrictions on rolling back an update. For more information about rolling back a windows update and Microsoft's restrictions on uninstalling updates click the links below.
I'm not certain if I accidentally changed the configuration or it just disappeared but, I'd like to get the progress dialog box showing the code download to display again. Can someone point me to the right option?
I have found what seems to be a pretty serious Studio issue, in which future changes to a project can retroactively break working code in source control. It sounds like a quantum entanglement meets the wrong side of a black hole story with zombies thrown in for good measure, but appears to be true.
Specifically, some project settings, notably related to SDK revision and 'Linked Resources', appear to be stored in, or at least affected by, data hiding in some non-project-specific meta-location outside the project (and thus outside any revision control system applicable thereto), such that changes to these items cannot be rolled back by reverting changes or checking out an older commit, and attempting to build code from an older commit will fail due to mismatched SDK or resource linkages. This also prevents maintaining functional builds of a project across multiple SDK revisions (e.g. active development branch on one and maintenance releases for legacy customers on another).
Create or have an existing project (EFM32 for my example) referencing an older SDK, which successfully compiles
Commit the entire contents of the project into revision control
Update to a newer SDK (add Linked Resources pertaining to the newer SDK, etc.), ensure successful compile, and exit Studio
Commit the current version, then revert to the original commit
Observe that your previously-working commit no longer compiles, and you don't have a path to fix this that won't break again as soon as you switch back to the newer commit!
Backstory, I am trying to track down a severe performance degradation that recently appeared on an EFM32 project, seemingly coinciding with upgrading from a very old SDK ("4.4.1") to a recent one ("5.7.x.x"). All the relevant code and settings (or so I thought), including .project/.cproject, are revision controlled through a Git repo, so it seems like an easy way to get to the bottom of it would be to walk back/forward through the commits, profile the build and confirm which commit the problem appeared in. However, compilation of a version predating the SDK update fails with e.g.:
make: *** No rule to make target `../emlib/em_aes.c', needed by `emlib/em_aes.o'. Stop.
...because that file doesn't exist in SDK v4.4.1, but is still somehow being referenced as a Linked Resource.
I've run into this type of "hidden meta-settings" issue before, resulting in some very weird Studio behaviors that were likewise only solved by nuking a project from orbit and starting over. In this case it was suspected (but not confirmed) that something had gone wacky in the hundreds-of-megs worth or undocumented cruft hiding in the ".metadata" directory of the Workspace. I got as far as confirming that nuking the ".cache" folder here has no effect on this issue, while nuking the ".plugins" folder wipes out (to Studio) any record of all projects' existence, as well as tools/tabs such as Simplicty IDE, Debug, etc.
Questions:
Where, exactly (e.g. specific file name), are the 'Linked Resource' settings (including any cached content) that may affect a project physically stored on disk?
What can I do to ensure all project-related settings, including SDK and linked resources, required to successfully build the project are correctly captured in revision control and used to faithfully build the project as-committed?
Is this considered a Studio bug proper or a documentation issue? Either way, when will it be fixed? (i.e. documentation of "How to correctly capture a project in revision control" exists as more than a to-be-written reply to a webforum post)
I am developing on BGM12S32F512GA using SDK Gecko SDK Suite v2.5.5, Bluetooth 2.11.5.0.
When I built a mesh example, I got some errors as below:
Building target: wristband_v2_mesh.axf
Invoking: GNU ARM C Linker
arm-none-eabi-gcc -g -gdwarf-2 -mcpu=cortex-m4 -mthumb -T "C:\Users\DellVostro3900\SimplicityStudio\v4_workspace\wristband_v2_mesh\bgm13p22f512ga.ld" -Wl,--undefined,bg_application_properties,--undefined,__Vectors,--undefined,__aeabi_uldivmod,--undefined,ceil,--undefined,__nvm3Base -Xlinker -no-enum-size-warning -Xlinker -no-wchar-size-warning -Xlinker --gc-sections -Xlinker -Map="wristband_v2_mesh.map" -mfpu=fpv4-sp-d16 -mfloat-abi=softfp --specs=nano.specs -o wristband_v2_mesh.axf -Wl,--start-group "./dcd.o" "./display_interface.o" "./gatt_db.o" "./graphics.o" "./infrastructure.o" "./init_app.o" "./init_board_efr32xg1.o" "./init_mcu_efr32xg1.o" "./lcd_driver.o" "./main.o" "./pti.o" "./temperature.o" "./hardware/kit/common/bsp/bsp_stk.o" "./hardware/kit/common/drivers/display.o" "./hardware/kit/common/drivers/displayls013b7dh03.o" "./hardware/kit/common/drivers/displaypalemlib.o" "./hardware/kit/common/drivers/i2cspm.o" "./hardware/kit/common/drivers/mx25flash_spi.o" "./hardware/kit/common/drivers/retargetio.o" "./hardware/kit/common/drivers/retargetserial.o" "./hardware/kit/common/drivers/si7013.o" "./hardware/kit/common/drivers/udelay.o" "./platform/Device/SiliconLabs/BGM13/Source/GCC/startup_bgm13.o" "./platform/Device/SiliconLabs/BGM13/Source/system_bgm13.o" "./platform/emdrv/gpiointerrupt/src/gpiointerrupt.o" "./platform/emdrv/sleep/src/sleep.o" "./platform/emlib/src/em_assert.o" "./platform/emlib/src/em_burtc.o" "./platform/emlib/src/em_cmu.o" "./platform/emlib/src/em_core.o" "./platform/emlib/src/em_cryotimer.o" "./platform/emlib/src/em_crypto.o" "./platform/emlib/src/em_emu.o" "./platform/emlib/src/em_gpio.o" "./platform/emlib/src/em_i2c.o" "./platform/emlib/src/em_msc.o" "./platform/emlib/src/em_rmu.o" "./platform/emlib/src/em_rtcc.o" "./platform/emlib/src/em_se.o" "./platform/emlib/src/em_system.o" "./platform/emlib/src/em_timer.o" "./platform/emlib/src/em_usart.o" "./platform/middleware/glib/dmd/display/dmd_display.o" "./platform/middleware/glib/glib/bmp.o" "./platform/middleware/glib/glib/glib.o" "./platform/middleware/glib/glib/glib_bitmap.o" "./platform/middleware/glib/glib/glib_circle.o" "./platform/middleware/glib/glib/glib_font_narrow_6x8.o" "./platform/middleware/glib/glib/glib_font_normal_8x8.o" "./platform/middleware/glib/glib/glib_font_number_16x20.o" "./platform/middleware/glib/glib/glib_line.o" "./platform/middleware/glib/glib/glib_polygon.o" "./platform/middleware/glib/glib/glib_rectangle.o" "./platform/middleware/glib/glib/glib_string.o" "./protocol/bluetooth/bt_mesh/src/bg_application_properties.o" "./protocol/bluetooth/bt_mesh/src/mesh_lib.o" "./protocol/bluetooth/bt_mesh/src/mesh_serdeser.o" "C:\Users\DellVostro3900\SimplicityStudio\v4_workspace\wristband_v2_mesh\protocol\bluetooth\lib\EFR32XG13X\GCC\binapploader.o" "C:\Users\DellVostro3900\SimplicityStudio\v4_workspace\wristband_v2_mesh\protocol\bluetooth\lib\EFR32XG13X\GCC\libcoex.a" "C:\Users\DellVostro3900\SimplicityStudio\v4_workspace\wristband_v2_mesh\protocol\bluetooth\lib\EFR32XG13X\GCC\libbluetooth_mesh.a" "C:\Users\DellVostro3900\SimplicityStudio\v4_workspace\wristband_v2_mesh\protocol\bluetooth\lib\EFR32XG13X\GCC\libpsstore.a" -lm -Wl,--end-group -Wl,--start-group -lgcc -lc -lnosys -Wl,--end-group
/var/lib/jenkins/workspace/Mesh/mesh-studio-sdk-1.4.x/platform/emlib/inc/em_crypto.h:879:6: warning: type of 'CRYPTO_KeyRead' does not match original declaration [-Wlto-type-mismatch]
../platform/emlib/src/em_crypto.c:253:6: note: 'CRYPTO_KeyRead' was previously declared here
void CRYPTO_KeyRead(CRYPTO_TypeDef * crypto,
^
../platform/emlib/src/em_crypto.c:253:6: note: code may be misoptimized unless -fno-strict-aliasing is used
/var/lib/jenkins/workspace/Mesh/mesh-studio-sdk-1.4.x/platform/emlib/inc/em_crypto.h:601:6: warning: type of 'CRYPTO_ModulusSet' does not match original declaration [-Wlto-type-mismatch]
../platform/emlib/src/em_crypto.c:199:6: note: 'CRYPTO_ModulusSet' was previously declared here
void CRYPTO_ModulusSet(CRYPTO_TypeDef * crypto,
^
../platform/emlib/src/em_crypto.c:199:6: note: code may be misoptimized unless -fno-strict-aliasing is used
../platform/Device/SiliconLabs/BGM13/Source/system_bgm13.c:124:17: warning: type of '__Vectors' does not match original declaration [-Wlto-type-mismatch]
extern uint32_t __Vectors;
^
../platform/Device/SiliconLabs/BGM13/Source/GCC/startup_bgm13.c:162:27: note: '__Vectors' was previously declared here
const tVectorEntry __Vectors[] __attribute__ ((section(".vectors"))) = {
^
../main.c:78:6: warning: type of 'mesh_bgapi_listener' does not match original declaration [-Wlto-type-mismatch]
bool mesh_bgapi_listener(struct gecko_cmd_packet *evt);
^
/var/lib/jenkins/workspace/Mesh/mesh-studio-sdk-1.4.x/protocol/bluetooth/apps/ncp_mesh/build/efr32mg13p-gcc-full-release/mesh_hal_gecko_obf/mesh_adv_impl_bgstack.c:138:6: note: 'mesh_bgapi_listener' was previously declared here
/var/lib/jenkins/workspace/Mesh/mesh-studio-sdk-1.4.x/protocol/bluetooth/apps/ncp_mesh/build/efr32mg13p-gcc-full-release/mesh_hal_gecko_obf/mesh_adv_impl_bgstack.c:138:6: note: code may be misoptimized unless -fno-strict-aliasing is used
Finished building target: wristband_v2_mesh.axf
Building project suddenly does not progress at all on Simplicity Studio with the Build Project window as shown below. In this case, clicking "Cancel" does not work and looks like Simplicity Studio has been completely frozen. Build progress information window persists forever even after closing Simplicity Studio main window, so I have no other choice but to kill studio.exe process in Task manager to remove this window residue. I'm not sure what triggered this symptom.
I tried to uninstall Simplicity Studio completely once, and re-installed Simplicity Studio from scratch, but this does not fix this issue.
I'm using Egit for source code version control, so I got back to the latest workable version which was successfully able to be built before. However, this approach also resulted in the same symptom.
when I try to upload Code on my SLSTK2010A board (with an EFM8SB1) today -yesterday it worked perfectly- , it wants me to run an Adapter firmware update. But unfortunately I always get errors doing this. After trying it via device configuration or Simplicity Commander, the error "The kit is still in Bootloader mode, it seems like the Installation failed." occurs. As a consequence, I can't even choose the debug mode. When I try it via Simplicity Commander, an MCU Change throws out "An error was encountered trying to set the debug mode: EMLINK failed."
I have a custom PCB using a BGM13P device. I want to be able to use the energy profiling capabilities of the Segger. I'm assuming I can do this within Simplicity Studio? However, reading the Users Guide, it appears I have to integrate with a starter kit? I'm a bit confused with this whole process, and was wondering if someone could clarify it for me. Currently, I am connecting my custom PCB to the Segger using the 10-pin needle adapter. I am also powering my PCB using the 5 VDC out (VKS) pin on the Segger.
We have been trying to get project sharing to work with Git for weeks now, still doesn't work even after following the SiLab AN article (pretty sire Simplicity Studio doesn't actually support git collaboration correctly).
Anyways, if we have any hope of evaluating Silicon Lab parts for our design, we decided to try exporting the project and importing it on another machine. We weren't surprised to find this doesn't work well either. See logs below. From source machine, we did a File > Export > FileSystem and did a File > Import on the new build machine.
The project now won't build because the Part Number is undefined and as a result the GPIO Typedefs are not defined.
We are still having a terrible time using git to collaborate with simplicity studio, despite following Si Lab's instructions. Anyways, to try to investigate the issue, I had one of my research students export his working project using File > Export > File System. I then tried to import into my computer using File > Import. The import works, but the project will not build because of missing macro definitions or something. Please see the build console output below.
I cannot figure out how to get the part number defined or get GPIO_Port_TypeDef to resolve.
Forum
Survey: Share your development experience with us
At Silicon Labs we highly value your feedback and always strive for improvement. Please share your experiences with our IoT development tools by filling out our short survey.
Your feedback will help us focus our improvements to serve you better, and it should take less than five minutes of your time.
Enter the survey here: https://www.surveymonkey.com/r/SLIOTDXC
Regards,
IoT Development Team
Informational Thread: Toolstick and Debug Adapter Issues After Recent Win10 and Win7 Updates.
The latest updates to Windows 10 and Windows 7 have caused reported issues with Silicon Labs' Toolstick adapters, 8-bit debug adapters, and 32-bit debug adapters.
The updates in question are:
KB4487044 (Win10 ver 1809)
KB4487017 (Win10 ver 1803)
KB4486563 (Win7)
The reported behavior is that the debug adapters do not enumerate properly. Affected devices will not show up in the Windows Device Manager. Example bug reports are linked below.
1 2 3
If you are running into these issues you can try to roll back the above updates. However note that Microsoft places some restrictions on rolling back an update. For more information about rolling back a windows update and Microsoft's restrictions on uninstalling updates click the links below.
Windows Patching Information
Windows 10 Update FAQ
If you are able to roll back these updates but still experience issues, please submit a support ticket here.
Silicon Labs is in contact with Microsoft and we are working to resolve the issue. Updates will be posted here.
Download progress dialog has disappeared
BUG: Zombie Linked Resources from the Future!
Hi,
I have found what seems to be a pretty serious Studio issue, in which future changes to a project can retroactively break working code in source control. It sounds like a quantum entanglement meets the wrong side of a black hole story with zombies thrown in for good measure, but appears to be true.
Specifically, some project settings, notably related to SDK revision and 'Linked Resources', appear to be stored in, or at least affected by, data hiding in some non-project-specific meta-location outside the project (and thus outside any revision control system applicable thereto), such that changes to these items cannot be rolled back by reverting changes or checking out an older commit, and attempting to build code from an older commit will fail due to mismatched SDK or resource linkages. This also prevents maintaining functional builds of a project across multiple SDK revisions (e.g. active development branch on one and maintenance releases for legacy customers on another).
This is the possible root cause of a previous issue I have reported here recently, as well as the fresh new issue I am currently having.
Steps to (maybe) reproduce:
Backstory, I am trying to track down a severe performance degradation that recently appeared on an EFM32 project, seemingly coinciding with upgrading from a very old SDK ("4.4.1") to a recent one ("5.7.x.x"). All the relevant code and settings (or so I thought), including .project/.cproject, are revision controlled through a Git repo, so it seems like an easy way to get to the bottom of it would be to walk back/forward through the commits, profile the build and confirm which commit the problem appeared in. However, compilation of a version predating the SDK update fails with e.g.:
...because that file doesn't exist in SDK v4.4.1, but is still somehow being referenced as a Linked Resource.
I've run into this type of "hidden meta-settings" issue before, resulting in some very weird Studio behaviors that were likewise only solved by nuking a project from orbit and starting over. In this case it was suspected (but not confirmed) that something had gone wacky in the hundreds-of-megs worth or undocumented cruft hiding in the ".metadata" directory of the Workspace. I got as far as confirming that nuking the ".cache" folder here has no effect on this issue, while nuking the ".plugins" folder wipes out (to Studio) any record of all projects' existence, as well as tools/tabs such as Simplicty IDE, Debug, etc.
Questions:
Thanks!
Build warnings on the functions CRYPTO_KeyRead / CRYPTO_ModulusSet / __Vectors
Hi,
I am developing on BGM12S32F512GA using SDK Gecko SDK Suite v2.5.5, Bluetooth 2.11.5.0.
When I built a mesh example, I got some errors as below:
Custom bootloader for BGM13S32F512GA
Hi,
I am developing on BGM13S32F512GA with SDK - BT Mesh v1.5.0 and BT 2.12.0.0.
I would like to create my custom bootloader for the module BRD4305A Rev A02.
However, after I created a new project (no matter SPI/Internal Flash Storage Bootloader) for it, I pressed the "Generate" botton.
I got error message.
Please note that it is ok with SDK version BT Mesh v1.4.3 and BT 2.11.4.0
Building project does not progress at all on Simplicity Studio
Hello,
Building project suddenly does not progress at all on Simplicity Studio with the Build Project window as shown below. In this case, clicking "Cancel" does not work and looks like Simplicity Studio has been completely frozen. Build progress information window persists forever even after closing Simplicity Studio main window, so I have no other choice but to kill studio.exe process in Task manager to remove this window residue. I'm not sure what triggered this symptom.
I tried to uninstall Simplicity Studio completely once, and re-installed Simplicity Studio from scratch, but this does not fix this issue.
I'm using Egit for source code version control, so I got back to the latest workable version which was successfully able to be built before. However, this approach also resulted in the same symptom.
What is a workaround in this case?
Adapter firmware update doesn't work
Hello,
when I try to upload Code on my SLSTK2010A board (with an EFM8SB1) today -yesterday it worked perfectly- , it wants me to run an Adapter firmware update. But unfortunately I always get errors doing this. After trying it via device configuration or Simplicity Commander, the error "The kit is still in Bootloader mode, it seems like the Installation failed." occurs. As a consequence, I can't even choose the debug mode. When I try it via Simplicity Commander, an MCU Change throws out "An error was encountered trying to set the debug mode: EMLINK failed."
I would be grateful for any idea how to fix this.
Regards,
Florian
Sometimes debugging under simplicity studio offers reset sometimes it does not.
How come randomly the debugger offers the option to reset the proccessor and other times it does not?
Thanks
How to unlock ISC file?
Hello,
I try to make a bootloader to follow this topic: https://www.silabs.com/community/wireless/proprietary/knowledge-base.entry.html/2018/07/15/adding_gecko_bootloa-DmFs
But when I want change the linker file, all the replacement template configuration are locked in the Other tab of *.isc file.
How I can unlock this?
Regards
Germain
Segger J-link ultra+ and energy profiling
Hi,
I have a custom PCB using a BGM13P device. I want to be able to use the energy profiling capabilities of the Segger. I'm assuming I can do this within Simplicity Studio? However, reading the Users Guide, it appears I have to integrate with a starter kit? I'm a bit confused with this whole process, and was wondering if someone could clarify it for me. Currently, I am connecting my custom PCB to the Segger using the 10-pin needle adapter. I am also powering my PCB using the 5 VDC out (VKS) pin on the Segger.
Thank you,
Mark
how to keep project settings when upgrading stack?
Hi,
I just upgraded my project stack by managing the build configuration and editing the stack.
When I compiled, it threw a bunch of errors, which I realized were missing files in .cproject (amongst other things).
I think the project settings were not kept (include paths, -lm link for gcc, etc... ).
What is the right /easiest way to upgrade the stack and keep your settings?
Gecko SDK install error
I want to install Gecko SDK but I can not get demos and software examples.
It prompted me with the following error. How to solve it? Thanks.
How to fix Part Number undefined after importing project from Exported copy
We have been trying to get project sharing to work with Git for weeks now, still doesn't work even after following the SiLab AN article (pretty sire Simplicity Studio doesn't actually support git collaboration correctly).
Anyways, if we have any hope of evaluating Silicon Lab parts for our design, we decided to try exporting the project and importing it on another machine. We weren't surprised to find this doesn't work well either. See logs below. From source machine, we did a File > Export > FileSystem and did a File > Import on the new build machine.
The project now won't build because the Part Number is undefined and as a result the GPIO Typedefs are not defined.
Export/ Import breaks project - cannot resolve Part Number or other macro definitions.
We are still having a terrible time using git to collaborate with simplicity studio, despite following Si Lab's instructions. Anyways, to try to investigate the issue, I had one of my research students export his working project using File > Export > File System. I then tried to import into my computer using File > Import. The import works, but the project will not build because of missing macro definitions or something. Please see the build console output below.
I cannot figure out how to get the part number defined or get GPIO_Port_TypeDef to resolve.