Official Blog of Silicon Labs

      • Top Three Security Concerns for IoT Applications

        Lance Looper | 02/60/2016 | 09:43 AM

        What is Security?

        A few weeks ago, Lars Lydersen shared his thoughts on steps the industry needed to take to improve IoT security, and this week applications engineer Ken Berringer kicks off an ongoing series focused on how we can do that.

        As an embedded engineer at Silicon Labs, I know that everyone is concerned about security; however, their concerns and needs depend on what they are trying to protect. When it comes to wireless Internet of Things (IoT) devices, I can group most of the security concerns into three categories:

        • Encrypted Communications
        • Physical Flash Security
        • Software Application Security

        My team works on adding security features to address this concerns on all of our low-energy microcontrollers (MCUs) and wireless systems-on-a-chip (SoCs). Let’s dive into these three concerns.


        1. Encrypted Communications

        Encrypted Communications protects the information transmitted over wires, or wirelessly over the air. Most wireless IoT protocols use some form of the Advanced Encryption Standard (AES) cipher. Encrypting sensitive information transmitted over the air will protect against eavesdropping or someone hacking into the network.

        Over-the-air encryption is built into the ZigBee, Bluetooth Smart, and Thread protocol stacks. Therefore, if you’re working on top of a wireless stack, you don’t need to know all of the gory details of things like the cipher block mode.

        However, it is helpful to have a fundamental understanding of why it’s important. The basic AES cipher has a block size of 16-bytes. To improve security for message longer than 16-bytes, many protocols use a cipher block mode, such as the counter mode, to improve security. This effectively changes the cipher for each block and adds an additional measure of security.

        To ensure that a message is not tampered with, many protocols use an authenticated block cipher mode. This mode includes an authentication code for each message to ensure data integrity and provide a fingerprint that is unique to the originator’s key.

        Bluetooth Smart, ZigBee, IEEE-802.15.4, and Thread all use some form of the counter cipher block mode for encryption and CBC-MAC (Cipher Block Chaining Message Authentication Code) for authentication.


        2.  Physical Flash Security

        Physical Flash Security for an embedded processor, this is the degree of protection against someone physically connecting to the pins of the device and reading out the code. For a low-energy microcontroller or wireless SoC with embedded Flash, there is a three-step process for physical security.

        • Lock the entire Flash
        • Disable the normal debug connection
        • Use a secure bootloader to upload encrypted firmware.

        If these three steps are followed, the firmware on the device is very secure. Once the Flash is locked and the debug connection is disabled, even the manufacturer will not be able to read out the Flash contents. (This may limit Silicon Labs' ability to process a Return Materials Authorization.)

        Physical security is not quite as secure as encrypted code. If the Flash contents are not encrypted, it is theoretically possible that someone with expert knowledge and sparing no expense might read out the Flash contents. Even for someone with expert knowledge and the expensive equipment required, this is still an expensive proposition. The economic deterrent is high enough to dissuade most hackers.

        A higher level of security is possible by encrypting the code in Flash and using a run-time decryption algorithm to decrypt the code from Flash and run from RAM. However, run-time decryption is difficult to manage, requires a lot of RAM, and will have a performance/energy penalty.


        3.  Software Application Security

        Software Application Security is the ability to secure some portion of the software against other software running on the same platform. This is important if one person develops the communication stack and someone else develops the application. If the stack provider delivers source code or a linker library, it is easy for the application developer to develop application code on top of the stack. However, this also exposes the stack assembler code to the application developer.

        Often there are more than two parties involved. For example, the stack developer might want to use a third party library. However, the stack developer needs to protect the third-party library code from the application code.

        A secure application environment, would allow an untrusted application developer to develop an application on top of secured code. The untrusted developer would not have access to the secured assembler code or be able to reverse engineer the secured code. The ARM mbed OS provides this kind of application security using the mbed OS uVisor. Future microcontrollers will improve the performance of this solution.

        What are your thoughts? What is the biggest security concern keeping you up at night?


        Coming Up on this Blog

        This is the first blog of a series on security. Upcoming blogs will go into more detail on these topics:\


        • Encryption and cipher block modes for data security
        • Secure Hash Algorithms and Authenticated Modes
        • Galois Counter Mode
        • Key Exchange using Elliptical Curve Cryptography
        • Digital Signatures using Elliptical Curve Cryptography
      • Wireless Protocol Webinar

        Siliconlabs | 02/60/2016 | 08:58 AM



        Date: Wednesday, March 30, 2016

        Time: 11:00 AM Japan Standard Time (Asia Pacific) / 10:00 AM Central European Summer Time (Europe) / 11:00 AM Central Daylight Time (Americas)

        Duration: 1 hour


        From Bluetooth to ZigBee and everything in between, this webinar will teach you how to choose the right wireless protocol or protocols for your application. Each protocol is optimized for specific benefits including conserving energy for longer better operation, achieving higher data rates, and providing greater connectivity ranges. But regardless of whether or not you’re working on a smart meter, wearable, or industrial device, this webinar will help you choose the right combination of protocols.


        After this webinar, you will be able to ensure your applications are optimally communicating with each other, gateways, the cloud, and/or consumers.



      • 4 Ways to Manage the IoT on an Energy Budget

        Lance Looper | 02/57/2016 | 03:37 PM

        From your toothbrush to your car, MCUs have become ubiquitous and our reliance on them is growing with the expansion of the Internet of Things (IoT). Today, speed has been replaced by energy efficiency as the key care-about for embedded applications. An MCU’s usefulness as part of an energy efficiency system depends on its ability to solve increasingly complex problems while consuming as little power as possible.


        We’re going to look at four considerations when maximizing energy efficiency in embedded applications.



        At a high level, all embedded applications are strikingly similar. They are built from a number of components specifically designed to perform a specific task such as power management, processing, connectivity, etc.) The components that perform these functions consume energy from your power source. So when building an energy-efficient system, logic dictates that you should choose components within your budget that are inherently energy efficient.


        Modes of Operation

        Besides integration, you should also understand the components’ various modes of operation. Most of them have an on mode and an off mode, but there may also be intermediate modes. An application can consist of a number of components, and you have to make a decision on how to control each component in the most efficient way. Designing for energy efficiency can in some ways be harder than designing a system that does not care about efficiency. But in energy-constrained systems, it is well worth the investment.


        When working with a sensor in an application, the straightforward approach is to leave the sensor on all the time. With this approach, the MCU can read the voltage across the variable resistor at any time, and calculate the current temperature based on the voltage.


        This option is the easiest way to control the sensor, but it’s also the method that consumes the most energy. Now, 33 µA might not seem like much, but when a solar cell that small only produces 10 μW of current, we quickly see the problem. A better setup is where the MCU is able to control the power of the sensor directly, turning it on only when needed.


        Energy Sources

        There are many types of energy sources for embedded applications including wired power, batteries, energy harvesting, and wireless power. A single application might use multiple power sources, but minimizing current consumption is key. Factors including mobility, lifetime, cost, and form factor put some constraints on your application. So uncderstanding the trade-offs that come with each is important.


        Batteries - Let’s say you’re a designer and the specificiaton states that the product or application needs to last for at least three years.  You’ve decided to use batteries as the energy source.  With that choice, comes the reality that you will need to make a tradeoff between lifetime, form factor, and cost.


        Energy harvesting – Energy harvesting uses the surroundings to generate energy. And naturally, these methods are dependant upon environmental factors that may be unpredictable. Solar harvesting panels, for example, must be in a bright location, and they need to have a given surface area. They might be able to generate 10 mW/cm^2 under direct sunlight, but can drop to 10 μW/cm^2 when indoors. That is 1000 times less energy to play with! To support nighttime operation, a rechargeable battery is needed as well, which increases cost and penalizes form factor.


        Wireless power - Wireless power delivery, also known as remote power delivery, is similar to energy harvesting in that your application picks up energy from its surroundings. The difference is that a power transmitter generates the energy the application is supposed to pick up. For inductive power delivery, the transmitter is generating an alternating magnetic field, and the receiver uses a coil to capture the energy. In this scenario, the maximum distance between the transmitter and the receiver, and also the amount of power that can be delivered, are based on the size of the coil. This puts constraints on form factor and flexibility because the receiver and transmitter must be in very close proximity.


        The MCU Itself

        Just as application components must be duty-cycled in order to maximize efficiency, the same is true for the MCU itself. Because they are more sophisticated components, MCUs almost always have more than just an on/off button. MCUs have multiple energy modes, where each mode allows a set of capabilities with an associated current consumption overhead.


        By requiring the CPU to be off as much as possible in order to save energy, the CPU tasks must be offloaded to the hardware in the MCU. Instead of being in a paradigm where software running on the CPU does everything, software development should focus on setting up hardware to do the heavy lifting and only intervene when hardware needs assistance. This takes the system to an event-driven architecture, allowing massive energy savings.


        At the heart of most embedded products lives a microcontroller with power sources that may be limited to small coin sized batteries. When focusing on using available power more efficiently, designers will be able to create energy-friendly products and applications that are smaller, have longer battery life and cost less.


        For more information, read the whitepaper.



      • Wireless Gecko Dazzles at Embedded World!

        Lance Looper | 02/57/2016 | 09:46 AM

        It was a big week for us in Nuremberg, where we announced several new products designed to simplify the process of adding connectivity to your applications. These include our new Wireless Gecko portfolio, which includes our new Blue Gecko Bluetooth Smart SoC, and our new Wizard Gecko WGM110 Wi-Fi module.


        The only thing more fun than showing these off for thousands of show attendees, was the response we received. Here are some of the highlights from the past few days.


        The value a chip company like Silicon Labs brings to IoT is no longer just about chips.” -


        Here's an interview with Embedded Computing Design's Rich Nass did with Daniel Cooley:


        Here’s an interview Power Systems Design’s Alix Paultre did with Daniel Cooley about Wireless Gecko:

          wrote about how the new portfolio could reduce development costs and the integration of ARM Cortex-M4 processors, and about must-have features for SoCs.


        EETimes wrote about how the new Wireless Gecko portfolio stacks up against the competition.


        "With a higher performance processor and greater memory, the Wireless Gecko will likely support a wider range of applications and target more single chip solutions."  - Tom Hackenberg, IHS Technology.


        Electropages wrote about Wireless Gecko and WGM110


        Power Systems Design also covered the WGM110 news here.


        Electronic Design covered the news and showed off the wireless starter kit.


        Wireless Starter Kit.png


        Learn more about Wireless Geckos and Wizard Gecko.

      • Do you Know the 6 Hidden Costs in a Wireless SoC?

        Lance Looper | 02/55/2016 | 11:17 AM

        Adding Wireless to Your Product?


        There are generally two options:


        Option 1: Use a wireless system-on-a-chip (SoC) directly on the product printed circuit board (PCB). A fully-integrated SoC has RF, analog and digital circuitry, and a microcontroller (MCU) on an easy to use, inexpensive integrated circuit.

        • Why use one? It’s smaller and cheaper than a wireless module.
        • Why not? There are lots of unknowns of designing it into a product. 


        Option 2: Use a wireless module. It includes the same wireless SoC as Option 1, but most are fully characterized products, including RF and shielding, timing components (crystals), external bill of materials (BOM), regulatory approvals, and standards bodies’ certifications.

        • Why use one? It removes the unknowns of a wireless SoC.
        • Why not? They are bigger and more expensive than a wireless SoC.


        There is a point in each product’s life when an “on-board” solution might make sense to save money. But it’s not always obvious, or tied to volume. Even the Apple iPhone 6 uses a Wi-Fi module instead of an SoC and it has shipped something close to 200 million units. Why?


        Six Hidden Costs to Using an SoC

        The answer may be one of the six hidden costs to using an SoC that every product development company needs to consider. Check out more detail of the summary bullets in this whitepaper.


        • RF Engineers – A company needs RF engineering expertise, or access to it, if they’re using RF on their PCBs. RF can be very tricky and RF engineers are expensive. estimates they cost $80-150K/year without benefits or overhead.


        • Lab Equipment and Facilities – Owning and equipping an RF lab is also expensive because it’s fundamentally required to do RF development.

        Hidden Costs Image 1.png


        • PCB Layout and Antenna Selection – Even with RF engineers and lab equipment, getting the RF done correctly takes time. There is generally very good advice in RF Application Notes like AN930 for Bluetooth Smart. But it can be hard even when following these documents very carefully.


        • Regulatory Approvals and Wireless Standard Certifications – All wireless products in the unlicensed bands must be approved by various governments and standards bodies. Each certification costs money and can take multiple tries. They may even cause delays or product redesigns. Modules generally come with these certifications already in place.


        • Reduced Product Revenue from TTM Delays – All of the above can add up to product delays. If a product misses its target window, or if competing product beats it to market, the revenue projections can fall, reducing the target ROI.


        • Supply Management and Assurance – And of course, once a product is in the market it must have supply. If a company is using a module, it’s a single ordering part number with a the buying power of a consolidated module customer base. If it’s an SoC design, there are lots of components and supply may be an issue.

        It’s not easy to predict all the reasons it might make sense to use a module over an SoC, or when the right time to switch to an SoC might be.


        In fact, some companies have many products in production that use either an SoC or a module. When companies use modules and SoCs for the same functionality, they often use the same supplier for both so their software is portable between both types of designs. They can also be sure their support will be consistent for both products.


        Silicon Labs offers both wireless SoCs like the wireless Geckos announced at Embedded World 2016, and modules that incorporate them. The software for them is portable, and both are supported by our world-class applications teams making it easy to move from modules to SoCs when the time is right.


        Check out Silicon Labs Wireless Solutions.

        Check out Silicon Labs Bluetooth Solutions.

        Check out the whitepaper on hidden costs of SoCs.

      • Chapter 9.5: SPI Flash Part 5 – Write Data to Flash From the Serial Port

        lynchtron | 02/54/2016 | 10:37 AM



        This is the final part of a 5 part series on the use of an external SPI flash with the EFM32.  In the last section, we learned how to use the SPIDRV, which is important to get the kind of performance that we need in order to keep up with hardware tasks, like the serial port.  The serial port (without flow control) doesn’t wait for your flash chip to finish its programming before sending the next byte.  Therefore the embedded application must take care to handle serial data interrupts and buffer all data received until the flash chip is ready for the next chunk of data to be programmed.


        Computer to MCU Data Transfer

        We can now combine the SPIDRV with the serial port driver from the last lesson to build a load mechanism that will accept data from the computer and transfer it into the flash chip.  The tricky part is to ensure that we can fill the flash chip faster than we can receive data from the serial port.  If a byte of data arrives from the serial port and cannot be written to the SPI flash chip in time, then the next byte of data will arrive and something will be missed. 

        The serial port example from the last lesson was configured to run at 115k baud or bits per second (which is 14400 bytes per second) and since the SPI driver can run at many MHz, at first it seems that the flash chip will easily be able to keep up with the serial port.  However, with all things embedded, all of the little details are super important.  The SPI flash has a page programming delay of up to 5 ms that adds to the overall time necessary to program a page of 256 bytes.  During the time that the page is being programmed, 0.005 seconds * 14400 bytes per second = 72 bytes will arrive from the serial port that can't be written to flash while the last page is being programmed.  The new data will need to be stored in the MCU memory buffer until the page programming completes and then fetched when the next transfer cycle starts via SPIDRV.


        To solve this issue, I created a ring buffer to store data coming from the serial port.  The ring buffer is four times as big as the page size (4 x 256 bytes) of the flash chip.  This should give us plenty of room to store the incoming data from the serial port, even if the MCU gets busy with other things.  I created a function called push_onto_ring_buffer that is called from the USART0_RX_IRQHandler.  When a byte of data is received from the serial port, the serial port interrupt handler will spring into action and place the byte into the ring buffer and exit.  It is important to do as little work as possible in the interrupt handlers, allowing the main program loop to handle the bulk of the work.  This allows your MCU to be able to catch all of the interrupts.  If you spend too much time in the interrupt handlers, a lower-priority interrupt could be missed due to excessive delays.


        The ring buffer is a simple array that I created in memory and then created a head and tail index pointer.  Here is the buffer when things are just getting started and there is not enough data yet to fill a page (256 bytes) on the flash:

        Once the delta between the tail index and the head index is bigger than the flash page size, we can initiate a SPI transfer on the segment.  While the SPI transfer is in progress, new data on the serial port is placed into the ring buffer at the head index, which does not disrupt the SPI transfer.  We have a whole two extra buffers of cushion before we wrap back around and overwrite data that is in flight on SPI.


        When the SPI transfer is complete, the tail index is incremented by the page size and the system waits until the delta between head and tail is bigger than a page size.  The process repeats forever but we will need to take care of the last chunk of data that is smaller than a page size separately, otherwise we could only send data that was in exact chunks of 256 bytes.  We will do that with a timer interrupt to handle the last chunk when the serial port hasn't been active for a while.




        First, we need to create the ring buffer and a bunch of state flags to keep track of things:


        // Ring buffer indicies and tail pointer
        uint8_t ring_buffer[RING_BUFFER_SIZE];
        int ring_head_index = 0;
        int ring_tail_index = 0;
        // Flags that control logic flow
        bool programming_chip = false;
        bool start_flash_transfer = false;
        bool perform_chip_erase = false;
        bool spidrv_active = false;
        bool timer_initialized = false;
        bool finish_last_chunk = false;
        // Counters
        int flash_address = 0;
        uint32_t total_bytes = 0;
        uint32_t bytes_to_dump = 0;
        // Must always use this for putting data into
        // ring buffer or else could exceed RING_BUFFER_SIZE
        // This gets filled by the LEUART handler
        void push_onto_ring_buffer(uint8_t byte)
              ring_buffer[ring_head_index++] = byte;
              if (ring_head_index >= RING_BUFFER_SIZE)
                    ring_head_index = 0;


        This simple push_onto_ring_buffer function places the received character into the ring buffer and then increments the index, taking care of the overflow that will happen at every 1024 bytes. The push_onto_ring_buffer function is only called from the USART interrupt handler:


        void USART0_RX_IRQHandler(void)
              if (USART0->IF & USART_IF_RXDATAV)
                    char test_char = USART_Rx(USART0);
                    if (!programming_chip && test_char == 'p')
                          perform_chip_erase = true;
                    else if (!programming_chip)
                          USART_Tx(USART0, test_char);
                          // Reset the timer count
                          TIMER1->CNT = 0;
                          // Tell the main loop to stop resetting TIMER->CNT
                          timer_initialized = true;


        I have created a special command parser within the interrupt handler to look at the first bytes of data to ensure that programming is desired.  This will keep from overwriting a previously programmed flash chip inadvertently.  If an ASCII character “p” is found when programming is not already in progress, the programming shall commence with the next data to follow.  All other serial port transfers will be ignored and simply echoed back to the terminal.


        Back in the main program loop, once safely outside of the interrupt handler, we check to see if there is a page of valid data in the ring buffer available to fill a page in the flash.  As soon as the buffer has enough data to fill an entire page in the flash chip, the main loop will initiate a write_memory function call that invokes a SPIDRV cycle for that section of the ring buffer.  The SPIDRV will handle transferring the page of data while new bytes arriving on the serial port will be stored into another part of the ring buffer by the USART interrupt handler. 


        // Returns true if there is a PAGE_SIZE of data
        // available, else false
        bool ring_buffer_valid()
              int width = ring_head_index - ring_tail_index;
              if (width >= PAGE_SIZE || width < 0)
                    return true;
              return false;


        This function is called from within the main program loop: 

                    // Check to see if there is enough data to write to flash
                    if (ring_buffer_valid())
                          write_memory(flash_address, &ring_buffer[ring_tail_index], PAGE_SIZE);
                          flash_address += PAGE_SIZE;
                          // Increment the tail index, and handle rollover
                          ring_tail_index += PAGE_SIZE;
                          if (ring_tail_index >= RING_BUFFER_SIZE)
                                ring_tail_index = 0;

        This process will repeat until the data transfer has stopped, which can be detected through the use of a timer that is reset every time that the serial port interrupt handler is called.  See the line TIMER1->CNT = 0; in the USART interrupt handler.  When no more data arrives on the USART, the USART handler stops being invoked and the timer is finally allowed to expire, and the final bit of data in the buffer is written to the flash chip by the following section of code in the main loop:


                    if (finish_last_chunk)
                          // Wait for any pending transfers to finish
                          while (spidrv_active)
                          // Check to see if there is something left to transfer
                          if (ring_tail_index != ring_head_index)
                                write_memory(flash_address, &ring_buffer[ring_tail_index], PAGE_SIZE);
                          // Let the flash write finish before starting the print function
                          while (spidrv_active)
                          print("Transfer complete of %d bytes.\n", total_bytes);
                          bytes_to_dump = total_bytes;
                          finish_last_chunk = false;


        The timer is set up to expire after 200ms of inactivity by the following code.  The first function call sets up the timer, and the second function call sets the count and enables it.


        #define ONE_MS_TIMER_COUNT          14
        // Get counter started but no ints yet
        void setup_timer()
              CMU_ClockEnable(cmuClock_TIMER1, true);
              // Set up TIMER1 for timekeeping
              TIMER_Init_TypeDef timerInit = TIMER_INIT_DEFAULT;
              timerInit.prescale = timerPrescale1024;
              TIMER_Init(TIMER1, &timerInit);
              // Wait for the timer to get going
              while (TIMER1->CNT == 0)
        // Disabled automatically when expires
        void enable_timer_ints()
              // Set TIMER Top value
              TIMER_TopSet(TIMER1, ONE_MS_TIMER_COUNT * 200);
              // Reset the count
              TIMER1->CNT = 0;
              TIMER_IntClear(TIMER1, TIMER_IF_OF);
              TIMER_IntEnable(TIMER1, TIMER_IF_OF);
              // Enable TIMER0 interrupt vector in NVIC
        // Called after last chunk of data is received
        void TIMER1_IRQHandler(void)
              if (!programming_chip)
                    TIMER1->CNT = 0;
                    TIMER_IntClear(TIMER1, TIMER_IF_OF);
              TIMER_IntDisable(TIMER1, TIMER_IF_OF);
              TIMER_IntClear(TIMER1, TIMER_IF_OF);
              finish_last_chunk = true;

        In the previous section, we used the SPIDRV function MTransferB for the write_memory function, which blocked until the transfer was complete.  Now, we modify the write_memory function to use the MTransfer function, which does not block and required the definition of a callback function that gets called whenever the background process completes.  The callback function simply sets a flag to prevent two SPIDRV cycles to run at once, which will cause a hard fault, and those are not fun to debug at all!  The use of a non-blocking call is not strictly necessary for this particular case, but the SPIDRV is fully capable to work in the background using DMA, which frees the main loop up to do other things while the SPI transaction is in flight.


        void TransferComplete( SPIDRV_Handle_t handle,
                               Ecode_t transferStatus,
                               int itemsTransferred )
          if ( transferStatus == ECODE_EMDRV_SPIDRV_OK )
            // Success !
              spidrv_active = false;
        void write_memory(uint32_t address, uint8_t data_buffer[], uint32_t num_of_bytes)
              while (spidrv_active)
              if (num_of_bytes > PAGE_SIZE) DEBUG_BREAK
              if (read_status() & WIP_BIT) DEBUG_BREAK
              //uint8_t status;
              uint8_t dummy_rx[SPI_TRANSFER_SIZE];
              uint8_t tx_data[SPI_TRANSFER_SIZE];  // Need room for cmd + three address bytes
              tx_data[0] = PAGE_PROGRAM;
              tx_data[1] = (address >> 16);
              tx_data[2] = (address >> 8);
              tx_data[3] = address;
              for (int i=0; i < PAGE_SIZE; i++)
                    if (i >= num_of_bytes) break;
                    tx_data[i+4] = data_buffer[i];
              spidrv_active = true;
              SPIDRV_MTransfer( handle, &tx_data, &dummy_rx, SPI_TRANSFER_SIZE, TransferComplete);
              // Comment these out so that SPIDRV can work in background
              //do status = read_status();
              //while (status & WIP_BIT);


        Once data finished being transferred to the flash chip, the main program loop will immediately read it back and output the contents of flash to the serial port.  That is accomplished with the following code: 

                    if (bytes_to_dump > 0)
                          uint8_t read_chars[PAGE_SIZE];
                          print("****  Data read from flash follows **** \n");
                          int i = 0;
                          while (bytes_to_dump > 0)
                                read_memory(i, read_chars, PAGE_SIZE);
                                for (int j=0; j < PAGE_SIZE; j++)
                                      USART_Tx(USART0, read_chars[j]);
                                      if (read_chars[j] == '\r')
                                            USART_Tx(USART0, '\n');
                                      if (bytes_to_dump == 0)
                                i += PAGE_SIZE;


        Now if we build and run this code, we can put together a text file that is greater than 512 bytes to test handling of two ring buffer segments.  Feel free to use the test_transfer.txt file in the src directy. Then, connect the serial port to USART0 as in the last lesson, with PC0 to serial port RX and PC1 to serial port TX, and with the ground connection as well.  Open the terminal emulator and set the baud rate to 115,200 baud, then use the terminal emulator and type some keys on the keyboard and see that they appear in the terminal window.  This ensures that everything is connected properly.  Remember though that a ‘p’ character will start the programming sequence, so don’t type that one until you are ready to transfer a file. 


        In the TeraTerm terminal emulator, your plain text file can be sent by selecting File -> Send file...  It might be different in your terminal emulator program.  But you want to let the emulator take care of transferring the file all at once.  When you do so, you should see confirmation of the file transfer in the terminal like so:


        Press p to erase chip and start programming:
        Erasing chip...
        Done.  Transfer file now.
        Transfer complete of 693 bytes.
        ****  Data read from flash follows ****
        Test transfer document.  Used to see if the data transfer from
        the host computer can get to the MCU and back again OK.
        This file is big enough to use both of the two RAM buffers that are
        256kb each.
        This newlines in this file are in PC format. The handling of newlines
        are not consistent across PC, Linux, Mac, and not even across terminal
        programs that you may encounter.  In my case, I have to add \r to every
        \n when I print information to TeraTerm.  Yet, I have to add \n to every
        \r if the data originates on LEUART coming from TeraTerm.  I have not
        handled it very completely in my code.
        That is all.  Have a good time with your EFM32 Starter Kit
        and The Maker's Guide to the IoT!!


        If that worked, disconnect your Starter Kit to ensure that the MCU and flash chip are both fully unpowered.  This proves that the data that you transferred is not saved in any RAM buffers on the MCU.  Reconnect the Starter Kit and change the starting value for the bytes_to_dump variable to the size of the text file that was sent into the flash.  This will dump the contents of the flash chip to the serial port as soon as the chip boots up, before erasing and programming the chip with the letter p.


        Whew!  There is a lot of stuff going on in this code to keep the data moving from the serial port to the flash chip without dropping any bytes.  This is where a good embedded programmer makes a difference.  It can be tricky to debug such a program, because the timing of any print statement (to the serial port) to help debug things can disrupt the timing by giving the MCU even more to do.


        This wraps up the foundational lesson on SPI.  You now have a few different ways to communicate with SPI devices.  You also have learned about some of the nuances of multitasking and found your first taste of DMA transfers thanks to the use of the SPIDRV.  In the next chapter, we will continue our exploration of communication protocols for embedded devices through the use of the I2C interface.



      • Announcing New Multiprotocol Wireless Gecko SoCs

        Lance Looper | 02/54/2016 | 08:37 AM

        We’re at Embedded World this week introducing our new multiprotocol wireless system-on-chip (SoC) devices, bringing simplicity and connectivity to Internet of Things (IoT) applications. Based on our energy-friendly Gecko technology and integrated radio, these Wireless Gecko SoCs aren’t holding anything back and represent the next step in low-power wireless connectivity.


        EFR32 Family.png 


        With this the introduction of our Wireless Gecko SoC portfolio, developers now have a one-stop-shop solution for meeting their multiprotocol IoT connectivity needs. Flexible cost/performance options significantly simplify wireless design by making it possible for developers to maximize their investment in development tools and software by allowing them to choose the wireless protocol that meets their current application needs today and migrate to other protocols within the portfolio.


        The Wireless Gecko portfolio features three families of multiprotocol SoCs optimized for real-world IoT use cases and the most popular wireless protocols:


        • EFR32MG Mighty Gecko – Provides best-in-class ZigBee and Thread connectivity for mesh networks
        • EFR32FG Flex Gecko – Includes flexible, proprietary wireless protocol options for diverse application
        • EFR32BG Blue Gecko – Features Bluetooth Smart connectivity with powerful output and long range

        To help get you up and running, you can evaluate and prototype with hardware development kits, application notes, and example code that include energy monitoring, USB, touch sensor, LCD and on-board debugging capability. Check out Simplicity Studio today to get started and register for our webinar, B to Z Connectivity: Which Wireless Protocol is Right for You?


      • Wizard Gecko WGM110 WiFi Module Debuts at Embedded World

        Lance Looper | 02/54/2016 | 08:14 AM

        Today at Embedded World we introduced the Wizard Gecko WGM110 Wi-Fi module, a plug-and-play Wi-Fi module ideally suited for IoT applications. RF performance? Check. Low power consumption? Check. Faster time to market? Check. The fully integrated WGM110 will simplify incorporating Wi-Fi functionality into industrial systems, wireless sensors, remote controls, thermostats, connected home products, fitness equipment and other devices.


        wizard-gecko-press-image copy.jpg


        Some key benefits include:


        Small size & exceptional RF performance:

        Best in class module size

        Integrated high performance antenna

        Low power consumption


        Rapid time-to-market:

        Onboard Wi-Fi and Software stack

        Minimal end product certification

        World-wide application engineering support


        BGScript standalone applications:

        Run applications on the module

        Quick development

        No external MCU is needed


        To help you get up and running with your own Wi-Fi IoT applications, check out the Wizard Gecko Wi-Fi Module Wireless Starter Kit. 









      • Up Close and Personal with the IoT at SX Create

        Lance Looper | 02/50/2016 | 04:36 PM

        I was having a conversation this week with a colleague about how my 4-year old is beginning to interact with the various IoT devices we have around the house. Our Amazon Echo now recognizes his voice and we were wondering what it must be like to have so much information literally at your beck and call at his age. Like most parents these days, watching him learn to navigate a world of connected devices is fascinating. I want part of that learning process to be exploration into how these advances happen. 


        This is where SX Create comes in. One of the hallmarks of the SXSW Interactive Festival is the creative spirit and diverse mix of technology and bringing these innovations to life. A funky blend of art and science, SX Create is a three-day event designed to stoke the fires of curiosity by giving attendees the opportunity to get hands-on exposure to things like 3D printing, hacking, robotics, and other innovations.


        SXCreates 2.png


        We’ll be part of this year’s line-up again with demos and activities, including a robot coloring station, high-tech pinewood derby races, and more from our extended family of makers, hackers, and DIYers. Our VP of IoT Solutions, Peter Vancoreland, will also be moderating the “Making the Internet of Things” panel that will explore how makers are helping to shape the IoT and the challenges, opportunities, and trends that lay ahead.  


        SX Create is free and open to the public. The event takes place at Palmer Events Center in Austin from Friday, March 11th through Sunday, March 13th and when you get there be sure to check us out!


        Check out some of the fun we had last year with our friends at littleBits!

      • IoT Hero Brings the Hive to the 21st Century

        deirdrewalsh | 02/50/2016 | 08:23 AM



        I love how IoT can turn up in the most unique applications. I recently sat down with Rich Morris, a hobbyist-beekeeper turned entrepreneur when he decided to take his beekeeping to the next level using embedded, connected technology.


        Hi, Rich. Tell us a little bit about yourself:

        I’m an electrical/system engineer with more than 35 years of experience in product design. I have spent the last five years of my career at an engineering development firm as VP of Operations. I recently left after an acquisition and had some new time on my hands.


        Sounds like that’s when BroodMinder came to be. What was the inspiration?

        I started raising bees as a hobby eight years ago. I found that keeping a brood healthy and safe through a Wisconsin-winter was really tricky. If your bees are struggling, you really don’t know until you open the hive up. So you either wait until the end of the season, when you can’t do anything to correct it, or you open the hive up and put the bees at risk of the cold temperature. Being an electrical engineer and experienced product designer, I decided to do something about it. The concept was to build a system that could accurately monitor temperature and humidity inside the hive without having to open it. That’s when I started BroodMinder.


        In the meantime, declining bee populations is a big problem and threat to global agriculture. Awareness of this threat has brought beekeeping to the mainstream. I saw proof of how mainstream this had become through an IndieGoGo campaign by FlowHive. This startup out of Australia is building these plastic taps you can attach to your hive so honey will flow out the back. These guys were only trying to raise $500,000. They ended up raising $12M.


        So it was obvious to me at that point that bees are sexy. A lot of people are concerned about the decline in population. Awareness about this has become pervasive even to urban areas. These people are my target market. And I know a device for these concerned enthusiasts must have a very low barrier to entry.


        So how did you go about designing BroodMinder?

        Considering the target market, I knew Bluetooth low energy (BLE) would be critical; people need to be able to connect to their smart device easily. I also knew I needed to sell something affordable, on the order of tens of dollars (not the $100s to $1000s of dollars, like what was already on the market).




        When choosing the technology that satisfied these criteria, I considered a variety of options. I knew my way around the industry since I had spent much of my career building embedded devices for clients and customers.


        I chose to build with the BLE113 module because of the simplicity of implementation and the impact it would make on my time to market. Having something pre-certified and stable saved me a lot of development and debugging time. Plus, I had already worked with the technology before. I was very confident of the Bluetooth stack these guys had put together. In my previous role, I knew the quality of the product is better than most.


        I love BlueGiga (now part of Silicon Labs) because they work so well going from small to large volume. As I sell more units, I won’t have to rewrite software when going from certified module to chip on board; this will be more seamless and efficient, saving time and money in the future.



        So what was the biggest hurdle for you when starting up your new company and bringing a new device to the market?

        We are a startup…just me and a couple of other guys. We need to focus on things other than the hardware and firmware; anybody in a startup will tell you there are many other factors to success. So even though it is a little more expensive to go with a module, the fact that it is reliable and proven takes one major item off of our crowded plate. That leaves us available to solve the unexpected problems bound to arise whenever introducing a new product.


        What’s the next milestone on your horizon?

        Well, monitoring temperature and humidity is helpful for people fighting winter. But the next device we are building is to monitor hive weight.


        With hive weight, you basically get to see the brood build and grow in population. Additionally, as the honey flow comes in, you get to see the hive weight jump in a matter of hours or days as honey is made. This helps you capture varieties of honey as different plants and flowers bloom, versus simply harvesting the bulk of what you get at the end of the season.




        People are DIY’ing this or paying $1000s for a solution. I’m going for target price of $150, which brings it into the realm of the 200,000 hobbyists. The key to solving this problem is getting it to mass production.


        This is a great example of Internet of Things. What does a more connected world mean to you?

        Lots of companies want to get into IoT. As a result, there are a lot of crazy, superfluous ideas. But among these, there are some game changers. And there are niches. Ability to simply connect to your smart device is powerful.


        In the case of BroodMinder, we can get large quantities of data from the field. Not just from specialists but also from enthusiasts, people who otherwise wouldn’t connect and collect data. The power of data analysis gets really cool when you include the masses.



        Let’s close with a big question: In your opinion, what does the future of IoT look like?

        It’s obviously going to be here forever. It’s going to be pervasive, and we have guys like Silicon Labs to thank for that. With IoT, there are things that are not noticeable, but become deeply ingrained in our lives. The things that will win are the subtle ones.


        Watch BroodMinder in action:



        For anyone interested in buying one, visit the BroodMinder buy page