RoadTest: EFM32™ Zero Gecko Starter Kit w/ Sensor Card
Author: hlipka
Creation date:
Evaluation Type: Evaluation Boards
Did you receive all parts the manufacturer stated would be included in the package?: True
What other parts do you consider comparable to this product?: None - this project evolved through several stages with new generations of EFM32 Gecko lines.
What were the biggest problems encountered?: The interesting choice of which pins to breakout in the headers, and the documentation that doesn't mention these quirks in the right places (see below)
Detailed Review:
I already have quite a long experience with the EFM32 lines of energy-efficient MCUs. The KompMon project started over three years ago (funny enough: also with a design contest). Back then my question was whether the compost heap we have in our garden worked as it should (hint: it didn't). So I created the first version of the project, using the first Gecko processor, and build a solar-powered temperature and humidity logger. It had two SHT21 channels, and could store data for more than a year (with hourly values). But it was quite klunky, so I set out to make it smaller.
So when I saw this road-test, the fact that the Zero Gecko STK has a MemoryLCD on it made it perfect for what I wanted. Its low power means it can show the measured values all the time, which makes the user interface much simpler. So I could build the project without external display, which means much smaller form factor. I had already calculated (for the second version of the project) that a 1F super cap is sufficient as power storage to run the EFM32 even through a long winter night. So no clunky LiIon battery with charger anymore - just a solar cell should be fine.
So this road test went mainly the route of getting accommodated with the board, and then migrating over my existing project from the Gecko / Giant Gecko to the Zero Gecko (and the MemoryLCD).
(There even will be pictures at the end 
Since all the other road test did already a great job of unboxing, I won't repeat that here. As I already knew from EnergyMicro, the quality of the board is great (this has not changed with Silabs now). The form factor is still the same, unfortunately the two rows of header pins are still mis-aligned by 0.05'' (so its difficult to put it into a breadboard). Headers and connectors are still the same though, and the board can still be used to debug other EFM32 MCUs.
The Silabs sensor expansion board is a nice addition. It contains a combined temperature and humidity sensor (a Si7031) and an environmental light sensor and proximity sensor (a Si1147). The latter one is not only used for measuring UV light, but also for detecting hand gestures.
Interestingly the quality of the sensor board is not as good as for the STK. There are still many remains of flux and cleaning fluid, especially around the headers. Its also a bad idea that the sensor board comes with standoffs, but the STK board doesn't. That way there is way to many stress on the STK headers when the boards are connected.
The STK comes with a Space Invaders demo game which is a nice change from the more functional demos that come with other boards. But on the other hand it means that, for testing the sensor board, one needs to upload a new firmware. It would have been nice if this had been the default. But after installing the SimplicityIDE its rather simple to upload new demo firmware.
The weather station program works quite well. Guiding through the different pages by waving your hand over the board takes some time to get used to, but works quite well. Its a good showcase for that kind of UI.
I'm a Linux user for several years now. So naturally all RoadTests involving software are more a challenge - most software is still written with only Windows in mind 
When Silabs took over EnergyMicro, fortunately they kept the cross-platform SimplicityStudio and the accompanying IDE. So all tools that are available also run under Linux. The installation works out of the box without problem, though one needs to download all the MCU packages afterwards.
While everything worked at my PC at home, the IDE was quite picky on my Laptop at work. Both run Kubuntu, but there the SimplicityIDE crashes right after opening a project (about 4 out of 5 times). Thats really annoying.
Also, I found out later on that, for some reason, setting breakpoints in a debug session doesn't work. Maybe I'm just using the IDE wrong, but I cannot remember doing something special with earlier versions (and there it worked).
Having setup the work environment, it was time to get started with the project migration. First I established that it was still working in its previous version - it was laying in a box for several months now. Then I looked up all the connections my SHT21 connection board (that also contains the super cap) made to the STK, and checked whether they are still valid.
While the Giant Gecko used in v2 had two I2C channels, the Zero Gecko now has only one. And since the connections are on different pins for each MCU line, the connections were different. Luckily I only needed to change one wire (the I2C SCL line), anything else could be re-used.
On the software side things were a little bit more involved. The Giant gecko STK came with a big NAND flash chip, so I had used that. On the Zero Gecko board this was not available so I needed to rewrite the whole storage subsystem (because otherwise the code would not even compile).
Taking over the code was rather straightforward. In SimplicityIDE I created a new project for the Zero Gecko board, and the copied over the needed source code files. No additional configuration was needed, just removing the software parts that are not available on this board.
Next step was to change all the hardware connections to the new GPIO ports (buttons and I2C pins). That was also not a problem, the EM library (the EnergyMicro C library used for all peripherals) makes this quite easy.
Last step was changing the UI from using a segment LCD to the MemoryLCD. From the examples I discovered that there is a printf() API available that allows easy usage of the display. That looked quite easy to use so I did. The API allows, by adding escape sequences to the output strings, clearing the screen and basic cursor movement. Unfortunately there seems not be any support for explicitly setting the cursor to a given position, so GUI is quite complicated. And I did not find any documentation about this either. (although I find the documentation rather good overall)
After removing and changing all the code. I found out that the program won't fit into the Zero Geckos memory. Bummer! I needed to strip about 8k from my code. So I started looking into the memory map provided by GCC. There I saw that the floating point math functions and the whole printtf support where the biggest blocks. So I started to change all the math functionality to be integer based (mainly by shifting the decimal point one place to the left, so e.g. I now work with 10th of degrees instead of degrees and float numbers. That was quite easy. The I needed to remove the board support package (I used it for setting the boards LEDs to notify the current state of the program) and there I was.
The RTC, locale temperature and battery voltage measurement worked with just small problems (did the math wrong during removing the FP calculation). But I did not get the SHT21 to work. After two evenings of debugging I took out my scope and started to look at the hardware. And even then it tooks me two hours to find out what went wrong.
I used one of the GPIO lines to switch the SHT21 on and off, so the consume power only when doing a measurement. With the scope I saw the signal on the SCL line replicated on that power line, so the SHT21 got turned on and off in rapid succession. No wonder it did not work. But my code was fine, so why did this happen?
After much cursing, measuring and looking at the data sheets I found the reason. And it actually was the biggest gripe I always had with the EnergyMicro boards.
On all the connectors there are signals that are already used internally. In some cases the component might be not active all the time, but in many cases the signal just cannot be used. In my case the PD7 signal which is available on the expansion board it also used as data line for sending data to the MemoryLCD. No wonder it was doing strange things... This is mentioned in the STK user guide, but only in the section explaining the LCD. In the description of the Expansion Header its marked as being usable for USART purposes. There are also two other pins that are used for other purposes (PD4, PD5 are used to communicate with the board controller). Why are they then on the header? They take up room, and will confuse also other users.
Oh, and why are there pins on the expansion header that are not on the breakout pads? That way sometimes both must be used to get all signals.
I remember the same problems from the STK3300 and STK3500 - on the latter one some peripheral components even ate up some precious specialized GPIOs (I think I needed to remove even something to get two I2C ports available on the headers).
And if there are reserved pins (or pins with multiple uses on the board), this should be documented in the right places (esp. since now the schematic is not part of the boards user guides anymore).
So, whats a road test without pictures? Here my test setup (right after I got the SHT21 to run)
On the oscilloscope screen the yellow trace is the (negated) power on signal, the blue line is the SDA line. Next to the STK is my breakout board.
The UI for showing the measured values currently looks like this:
(I think the temperature reading is a little bit on the low side), but I want to change that to get all values (including battery voltage and locale temperature) on one screen.(
So whats my verdict? This has been more of a project report than a roadtest report for now. Mainly this is due to me already knowing quite a bit about the EFM32 MCUs, so I knew what to expect (and how good they are).
The Zero Gecko is a great low-power micro controller. I like the IDE (despite it being sometimes very beta under Linux), and also the library support for all the peripherals. The drivers now even have been extended to include other chips like the Silabs temperature sensors.
I also still like the hardware. But the situation around what signals are provided on the headers and how are they documented should be improved, this can be very confusing and frustrating otherwise.
I will continue with this project, but fortunately there is some time left until I need this project again...
