Buy Now
Scoring
  • Total Score
  • Product Performed to Expectations
  • Specifications were sufficient to design with
  • Demo Software was of good quality
  • Product was easy to use
  • Support materials were available
  • The price to performance ratio was good
Review - Details
Group Actions
  • Author Author: baldengineer
  • Views 825 views
  • Likes 0 likes
  • Comments 8 comments

EFM32™ Zero Gecko Starter Kit w/ Sensor Card - Review

baldengineer

Table of contents

RoadTest: EFM32™ Zero Gecko Starter Kit w/ Sensor Card

Author: baldengineer

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?: null

What were the biggest problems encountered?: Lack of SPI / SD-Card Support, Limited Application Notes for Zero Gecko, Difficulty with Simplicity Studio

Detailed Review:

 

Background

When I was selected for the Zero Gecko Road Test I was excited to get a chance to look at SI Lab's stuff.  I haven't had a chance to dive into their product line, but have been waiting for a project to do just that. 


The board arrived the day before I left on a 3 week trip.  Which turned out to be great, because it gave me time to consider what to do with this new "Weather Station Demo" EFM32 Starter Kit I received.  Doing my research, I could see the EFM32 series is focused on low-energy performance.  The demo/starter kit (not sure which to call it) included an expansion sensor board with UV (Optical), Humidity, and Temperature sensors.

 

As I waited for the EFM32 software to download, it hit me.  Why not build a data logger?  For some time I've thought it would be cool to use my GoPro to capture a day from sunrise to sunset, with a data overlay.  So my plan was to write the code, benchmark the energy necessary, provide enough battery, and let it all go.  But first, let's talk about the Hardware and Software.

 

Hardware

The entire board is made of surface mount components on the top-side only.  This includes the pin headers.  I really liked this because it meant the board sits flat on a workbench and means easier mounting.

 

image

 

However, as you can see above if you attach the included sensor board, there's bending and physical stresses in place.

 

Sensor Board

UV Sensor is a si1147

Humidity/Temp sensor is a si7013

 

The board has an expansion connection, which appears to pass through 5V, 3.3V, I2C, SPI, and a UART.

 

 

Specs

The processor is based on a ARM Cortex-M0 with 32k of Flash and 4k of RAM.  The LCD is 128x128 pixels with impressive readability.  The board has two physical push buttons and two cap sense buttons.  Power can come from the USB Port or a coin cell (CR2032) battery.  There's a JTAG debug header and an expansion header.  The pin out on the header is a little awkward to follow.  Here's the pin out from the documentation

 

image

 

Now here's the EFM sitting on top of the sensor board.  Notice how you have to flip the board so that Pin 1 lines up with Pin 1 in the diagram.

 

image

 

Also, the expansion card, has no silkscreen on the expansion pins.

 

 

Software

When you open the box, there's a nice QR Code and Website that takes you directly where you need to download the software.  This is great.

 

image

 

After installing the software, I had to wait 10 minutes while it updated itself.  This was not great.

 

The IDE

This is the "Welcome" Screen for SimplicityStudio, which includes all of the resources necessary for developing with the EFM32 series.  The real issue I ran into here, it wasn't always obvious to me which things related to my board.  Oddly the package says its a SLSTK3201A, but the software clearly identifies the board as a EFM32ZG222F32 MCU.  So it can be a little confusing which to refer to.

 

image

 

If you're familiar with Eclipse, then you'll be familiar with SimplicityStudio.  One of the great things about Eclipse is its flexibility.  One of the downsides of Eclipse is its flexibility.  I think SI Labs has done a good job of customizing their own environment, but there were still a few moments where I had to figure out what Eclipse was doing with the interface.  If you've never used Eclipse before, I think you're going have a larger learning curve than I did. I would have called mine a learning bump.

 

image

 

 

Energy Monitor

The real-time energy monitor is a first for me.  I see a lot of value here.  Well, I did, until I noticed something.  Here's a shot from a sketch where I was trying to interface to a SD Card.  Notice the current is shown as about 2.5 mA?

 

image

 

I'm powering an Arduino Ethernet Shield from the board  (I'll explain why at the end), which draws almost 200mA.

 

The limit for the current sense circuit, according to the instructions, is 50mA.  So, I'm not sure what that's telling me.

Demos

There is a small assortment of demos to help start a project.  There are even a couple of RTOS examples.  The most interesting to me were "energy" and  "weatherstation".

Energy

The cool thing about energy is that it gives you a way to see how much voltage and current the processor is using at different clock frequencies.

 

Weatherstation

This is a good chunk of code that displays the current UV, Humidity, and Temperature.  Each has a graphic display associated with them.  This seemed like a great starting point, because this demo is making all of the measurements I need, so all I need to do is save them to some EEPROM or a SD Card.

 

Back to My Project

Here's where I ran into my first major roadblock.  It never occurred to me, this processor and board don't include any nonvolatile user-storage.  What's worse, when I went back to the demos I realized there wasn't anything on SD Cards.  In fact, there wasn't even anything that showed how to talk SPI.

 

Hm.  Okay, let's go back to the Welcome screen and check out that list of Application Notes.

 

image

 

SPI Application Note

So I dove into the App Note "AN0030 - FAT on SD Card."

 

That's exactly what I want to do!

 

Looks like there is a (free) FAT implementation, great!  Now I just need to add it to my project... but, uh, how?  I looked through the App Note multiple times, I couldn't find where that was explained, or where to download the code.  Thankfully I was able to use OSX's Spotlight to find a couple of instances of FAT libraries in the Simplicity install, but still wasn't sure which one to use with this board.

 

A Google search later, and I was brought back to the element14 road test thread...  Jan Cumps had already done a write-up, basically providing the necessary SD-Card (SPI and FAT) support necessary for the Zero Gecko.  Of course, even with his excellent write-up, I had to fight Eclipse to get it to load his project.  (See the thread for my comments on what I had to do, with Jan's gracious help.)

 

Eventually, I had compiled code, that was writing files to the SD Card.

 

Now I was ready to start capturing sensor data, or was i?

 

Expanding to sensor data

So I took the weather station example and stripped it down to just the code that captures the data.  I'm not interested in using the LCD and would rather save the energy anyway.  I got the code stripped down to what I think I need and started to combine it with my sd card code.

 

Then this error started happening.  Which I guess means I'm running out of RAM or something...

 

This video is unavailable.

 

...Sigh.  After so many road bumps and a couple of road blocks, I just decided it was time to give up.  So...

 

In Conclusion

Clearly, I'm not the right audience for this board.  I was hoping to get a project up and going quickly, but I lack the extensive experience with SI Labs hardware/software necessary to do that.  The low power performance of the processor is enticing, and is a reason I would consider using the processor family again on a future project.

 

If your application is focused on saving µW (or nW) of power, say like in an IoT powered by Energy Harvesting, I can imagine the man-months of studying necessary for this processor platform would be worthwhile.

Anonymous
  • in reply to baldengineer

    I've got the test setup working where the measurements are logged to an sd card every 2 seconds. In full debug mode with no optimization it (barely) fits in Flash and Ram,

    In release mode with size optimization there's significant resources left:

     

    arm-none-eabi-size "STK3200_weatherstation_sd_logger.axf"

       text   data    bss    dec    hex filename

      16924    116   1380  18420   47f4 STK3200_weatherstation_sd_logger.axf

     

     

    Log file content:

    temperature;humidity;uv
21125000;00040455;00000000
21114000;00040737;00000000
21104000;00040722;00000000
21104000;00040699;00000000
21104000;00040707;00000000
21104000;00041080;00000000
21125000;00040989;00000000
21114000;00040981;00000000

  • in reply to baldengineer

    I've created a separate thread for the 'log weather data to sd card' exercise here on element14: EFM32Tm Zero Gecko Starter Kit w/ Sensor Card: logging to SD card

  • I've been validating code sizes.

     

    The SD Card example that I ported from AN0030 (but did not optimize in any way) is taking up (in DEBUG config):

     

    Running size tool

    arm-none-eabi-size "STK3200_sd_card.axf"

       text   data    bss    dec    hex filename

      19828    180   2716  22724   58c4 STK3200_sd_card.axf

     

    The Weather Station by itself is:

    Running size tool

    arm-none-eabi-size "STK3200_weatherstation_2.axf"

       text   data    bss    dec    hex filename

      26024    140   2552  28716   702c STK3200_weatherstation_2.axf

    The starter kit is hosting this controller:

    Silicon Labs EFM32 Zero Gecko Microcontroller with 32 KB Flash and 4KB RAM - EFM32ZG222F32

    If I understand this report correctly,

    The 32 KB Flash will have to host 19828 + 180 + 26024 + 140 = 46172 --  significant pruning of code needed

    The 4KB RAM will have to contain 180 + 2716 + 140 + 2552 = 5588 -- needs to be reduced too

     

    Part of the flash is shared by both examples (libraries, ...) and size will shrink when compiling for release.

    I haven't tried the impact of combining the two yet, nor compilation in release mode.

     

    (I used this reference to calculate the figures: http://www.support.code-red-tech.com/CodeRedWiki/FlashRamSize )

  • in reply to Jan Cumps

    Jan Cumps wrote:

    SD card is a significant memory consumer because of the sector size and the buffer.

    I think with an appropriate optimization of the example FAT library, it could be made to work.  I've seen platforms with less RAM do more, but those still required very careful memory management.

     

    I'm going to try to replicate your approach with the SD card and check if it can be fitted into this controllers. Maybe we can try together on GitHub?

    I'd be open to trying, but it'll be several weeks before I can come back to this project idea.  My GitHub username is baldengineer, of course.  image

  • in reply to Jan Cumps

    That one wasn't it.  Thanks to your post, I already knew to make / check that change.  Something about my combined code caused the overflow.

  • I've been thinking about your application to store the measurements. SD card is a significant memory consumer because of the sector size and the buffer. That in combination with the weather station may be too much.

    It might be more appropriate to use the non-volatile flash on board of the controller (via AN0019 EEPROM emulatoion maybe?)  or another external non-volatile memory that's addressable without big buffer.

     

    I'm going to try to replicate your approach with the SD card and check if it can be fitted into this controllers. Maybe we can try together on GitHub?

  • You were so close. I had writen down the solution to your memory problem in my blog post:

     

    I made this change to line 17 of the ffconf.h file in /reptile/fatfs/inc/ to work around a memory size issue I had during compiling:

    #define _FS_TINY 1 /* 0:Normal or 1:Tiny */

     

    I believe there are also some compiler options that are described either in the weatherstation PDF uploaded to the roadtest, ot the embedded video, that explain some optimization settings to do to keep under the memory limit.

  • Nice writeup.

     

    I did read about the hoops you had to jump through, and I'm sure it would catch many people that weren't as familar.

     

    Mark