- Silicon Labs Community
- Welcome and Announcements
- Silicon Labs Knowledge Base
- 8-bit MCU
- 32-bit MCU
- Bluetooth / Wi-Fi
- Other Products Category
- Optical/RH/Temp Sensor
- Other Products
- Hardware and Software Tools
- Simplicity Studio and Software
- General Discussions and Suggestions
- Chinese Forum
- Software Libraries
- Development Kits
- Reference Designs
- Third Party Tools
- White Papers
- Official Blog of Silicon Labs
- Chinese Blog
06-03-2015 01:30 PM - last edited on 11-26-2015 05:18 AM by Siliconlabs
Yesterday/today, I downloaded Studio V3 and gave it a whirl. Here are the impressions so far. In short, it has great potential, but so far I'm rather less than impressed :-/ Hopefully someone from SiLabs can have a look at this, as it might attract enough "me too" posts to get the attention of someone who can address some of these issues.
1) Versioning, and "What is this Studio V3 of which you speak?"
There is a huge weakness around versioning all around, here. Aside from seconding (...thirding...n'th-ing) this sentiment about the lack of any versioning in the installer filename nor the web site itself, the ONLY way I knew there even *was* a Studio V3 was that I had just received a Happy Gecko starter kit, and Googling the "Unrecognized firmware version string" error coughed forth by the "latest", "updated just that morning" Studio (V2) did not return any results, so I went to post about it in this forum and saw posts referencing a "V3". Had this specific sequence of events not occurred, who knows how long I would continue happily using an obsolete, unsupported version and thinking it was up to date.
Sidenote: Even after becoming aware of "V3", it's difficult to even guess which version (V2) one has, since the version numbers shown by V2 (Help->About...) have absolutely no correlation to the "V2/V3" labeling. They report a large number of independent modules with versions of "1.something", including the "Simplicity Studio" module entry itself.
Suggestions: I understand there is a legitimate technical limitation that prevents V2 from being upgraded to V3 via its update functionality. But it should be possible to update V2 in such a way that it produces a popup notifying that a V3 exists, and that V2 is obsolete/unsupported despite the lack of any updates/warnings from the auto-updater. Otherwise I suspect you will have more support work on your hands as V2 becomes increasingly obsolete, users don't know about it and pester tech support about various problems/bugs that were fixed long ago. Also, for the love of the flying spaghetti monster and all that is holy, put "This is Version 3, released on xx/xx/2015" in big letters on the download site! If the "out of date" popup thing is not technically possible, at least put all over the website and any developer's email you have that there is a new version avaiable, and that V2 will NOT report so via its update mechanism (it will show up-to-date always).
2) Installation Safety (yay!)
Studio V3 installer works, and does not clobber V2 or any of its installed code (SDK/emlib/drivers/etc.). Yay!
3) Migration Experience (boo!)
a) Migration of a workspace project from V2 to V3 does not preserve linked resources from the old project. They are nuked with prejudice from the .cproject file, resulting in a project that no longer builds. Boo!
b) Not all projects from the old workspace are migrated. Out of 6 projects, the first 2 (alphabetically) came across and the rest did not (no folder or anything). Double boo!
c) If the project being migrated has been renamed at any point since it was created, the original name is somehow restored. This would not be a huge deal, except that after renaming (e.g. back to the migrating project's current name), some resources in .project/.cproject are not renamed. The result is more weird build errors, e.g.:
CMSIS/efm32gg/subdir.mk:30: warning: overriding commands for target `CMSIS/efm32gg/startup_efm32gg.o'
CMSIS/efm32gg/subdir.mk:23: warning: ignoring old commands for target `CMSIS/efm32gg/startup_efm32gg.o'
make: *** No rule to make target `C:/Users/yourname/SimplicityStudio/v3_workspace/O
Specifically, in my case the following tags in the project files were not updated:
<resource resourceType="PROJECT" workspacePath="/OriginalProjectName"/>
Needless to say, breaking the build = "boo!"
d) Incompatible changes in SDKs, despite having the same SDK version!!
After fixing all of the above, my project still would not compile. Most of the problems centered around incompatible changes made to the USB library. This should NEVER happen within the same SDK revision! If incompatible changes are necessary, they should a) be a new SDK major rev, and b) not automatically be substituted for the version the project was using. Believe it or not, this sort of thing creates a huge pucker factor for engineers using your tools for actual shipping products, even if they follow good backup and revision control practices themselves and can recover manually from such disasters if needed. Again, build-breaking "boo". (Luckily, V2 and its projects are preserved and still work, so no emergency recovery needed for shipping products, but still...)
4) User First Impressions
a) Overall, looks and feels the same as the old one. There are no longer a separate "Home" and "IDE" windows (the IDE window replaces the Home window; but there is a self-explanatory graphical button near the top of the IDE window for switching back to the home window.) Personally I preferred it the other way, but no big deal, and folks shouldn't have trouble adjusting.
b) The links to SDK (e.g. emlib) documentation seem to have been removed from Simplicity Studio. The quickest way to access these now seems to be Googling "emlib documentation" and clicking links until a non-404 one is encountered. That or the links to them from Studio are buried in a suitably non-obvious location.
c) Why are some tools (Energy Profiler, etc.) hidden by default? This might make sense if there was no room onscreen to display them, but there is. I think the target audience for embedded development is technically advanced enough not to become confused by "too many" (8) full-color point-n-click icons.
5) Misc. Problems & Regressions
a) Connecting to a debugger/target now involves extra steps (probably discovered via Googling various error messages and getting some webforum psots on the subject to wade through). Since Studio now supports several chip families with various debug interfaces (SWD, JTAG, etc.), you must now go into a menu and select this explicity for your debugger. This is understandable and not really a big deal, but when debugging, it seems like the software should be able to make a reasonable guess based on the chip specified in the project you are debugging. For example, in a Gecko-based project SWD is the only supported interface. So, not a big deal except...
b) Studio "forgets" target part/interface selections. After selecting a target interface/part in Simplicity IDE, those settings seem to get lost from time to time. When going from Debug session to the home screen, and/or closing/opening Studio? I haven't played with it enough to find which conditions reliably cause this to happen, but it's rather annoying.
c) Connecting to a target seems much less reliable in general. In V2, operations through a kit/debugger mostly Just Worked, and in the occasional occasions they didn't (the "Device Detection" window appeared), plugcycling the debugger and target board fixed it. In V3, I am mostly getting the "Device Detection" window instead of a working debug session and unable to continue from there, regardless of how many times the debugger/target are plugcycled and in what order (yes, I've set the debug interface and detected the target MCU). I'm using the STK3600 as a debugger, set to external debug, and an external target board with a 'GG330. Typical scenario:
On attempting to debug/flash, "Device Detection" - "No detected device is available or compatible with EFM32GG330F1024" window appears. My debugger, in this case "EFM Leopard Gecko Starter Kit Board" is shown, but grayed out. The text "Scanning devices..." periodically appears beneath it.
Refresh - no effect
Target Selection - set target interface to 'SWD' and hit 'Detect Target' - Part is detected correctly (EFM32GG330F1024). Hit OK.
Now, "EFM32 Leopard Gecko" (debugger) has changed from grayed out to black, but the dialog still says "The selected device is not compatible with this operation". Underneath the devkit name, a gray "Scanning devices..." is still appearing periodically as before. The "OK" button is grayed out.
Plugcycling or killing/restarting Studio has no effect. Very occasionally, it starts working again mysteriously after just leaving it alone for a while (i.e. a lunchbreak or so).
d) "Kit Update Available..." lack of feedback, and mysterious failure. When selecting Kit Manager on the home screen, a firmware update notice appears. After selecting "Yes" to perform a kit firmware update, nothing appears to happen. The dialog remains onscreen with the "Yes" and "No" buttons there and clickable, both during and (presumably) after the update. I say "presumably" because...
Got the following after about half a minute (the kit disconnected and reconnected to USB a couple times during the process, and the LED blink pattern on the blue J-Link LED appeared to change a bit):
Failed to program flash
TCF error report:
Command: FlashSupport flash "usb.440009246.adapter.kit", "C:\\SiliconLabs\\SimplicityStudio\\v3\\developer\
Error text: Kit failed to restart
Error code: 131073
It looks like it succeeded anyway though; after waiting "a while" and plugcycling the kit, I no longer get the firmware-upgrade nag and Kit Manager shows revision "0v11p0b14" (not sure how this versioning relates to the incompatible-looking version numbers in the changelog though; see previous comments about versioning.).
e) No longer able to add linked resources via drag-n-drop. In V2, the nice way to work with SiLabs-supplied code (libraries, etc.) is to add them to a project as linked resources, see discussion in this post. This involved either an excruciating mousedance through the GUI (some dozens of clicks per each and every file in the library, or about a month of billable time) OR simply dragging-n-dropping the parent folder into the IDE, and selecting "Linked" when prompted. This no longer works in V3. In the end I (re)introduced the linked resources (lost in migration, see first issue) by hand-editing the XML in .cproject rather than the mousedance, but users really, really should not have to do this.
My apologies if this comes off as kind of a rant, but it seems there are still a number of issues harming the experience of migrating to V3 (or for new users, using SiLabs tools/parts as a whole), a number of which seem like they would be very easy to fix, and some others that should never have been an issue for a professional company selling products to engineers for a living (e.g. SDK revisioning and rev control issues in general). Hopefully this will help get them fixed.
06-04-2015 05:14 PM
We've been bitching and moaning about the lack of versioning forever, and the SiLabs tech-support folks who handle this forum know we think it sucks, but haven't been able to convince the Powers That Be that the users hate it.
Oh, and yes, V3 completely borks projects done with V2. I was working on an 8051 design with V2, then noticed that V3 was available, so I installed it and it killed the project dead. Luckily, recovery was as easy as an $ svn revert and then opening the project again in SS V2.
12-17-2015 08:34 AM
Six months later, and as a new user, I continuously encounter most of these issues in both Windows and Ubuntu! I spend more time trying combinations to get the debugger connected than I spend working on my code! I sometimes have luck with detecting interface and target from homescreen, then clearing and resetting debug configurations in the IDE, switching EVB from MCU to OUT and back, resetting and power-cycling things, reseating cables, and basically just randomly dinking around. Sometimes this will work, and set the debugger to the beginning of main(). Other times, I can try things that worked before for an HOUR, and have no joy. Also, getting it to work once makes no guarantee that it will work again, even in the same session with the software. I am continuously having to redetect the interface and target.
I also sometimes have to recreate my project and move source files over because something will get hosed up and say "No rule to make target ." Even though Debug is the active configuration.
I really like the silicon, but the software is so buggy, I hesitate to use the EFM32 in any future projects.
Maybe if I can find a 3rd party development environment. em::blocks looked good, so too bad it was cancelled. Maybe if I dig up a copy of V2?
03-01-2016 02:11 AM
I wondered if others face the same problems and foundt: Yes still not fixed.
If any one had a workaround or solution please tell.
Why could this device recognition not be done automatically?
And why must one close/leave the dev perspective to selelct the same device that then suddendly worked?