Silicon Labs Silicon Labs Community
silabs.com
Language
  • 简体中文
  • 日本語
  • MCUs
    • 8-bit MCU
    • 32-bit MCU
  • Wireless
    • Bluetooth
    • Proprietary
    • Wi-Fi
    • Zigbee & Thread
    • Z-Wave
  • More Products
    • Interface
    • Isolation
    • Power
    • Sensors
    • Timing
  • Development Tools
    • Simplicity Studio
    • Third Party Tools
    • Thunderboard
  • Expert's Corner
    • Announcements
    • Blog
    • General Interest
    • Projects
  1. Community - Silicon Labs
  2. Blog

Essential Best Practices and Debugging Tips for EFM32 Project Success - Part 2

01/27/2017 | 08:13 AM
lynchtron

Level 5


debug_teaser.png

In the first part of this series on best practices and debug tips, a Revision Control System was introduced, and how it can stash your design files safely away and help you find differences across design files.  In this section, you will learn what it takes to be a success with building your own hardware.

 

Start Development on a Breadboard

 

When starting a new project on EFM32, you may have followed some of the examples of this book and felt that you have learned enough to develop your own EFM32 solution on your own custom Printed Circuit Board (PCB).  But don’t make that leap too fast!

 

1.      Test out the pieces one at a time first

For best results, every project should start with a “breadboarding” phase where you assemble a Starter Kit and a breakout board for each major device in the design.  While you can read specifications for the devices in your design many times over, you don’t truly learn how to use a device until you have tried to interact with it from software.  Just the experience of connecting a device to your Starter Kit and trying to talk to it over the electrical interface will yield many insights that are not gleaned simply from reading the spec.  While some specs can make a lot of sense at first, you will soon discover that the spec doesn’t cover everything needed to bring up a device and start using it, or at best it glosses over some important information that requires an extra signal wire, an extra external circuit, or a number of other important details.

 

2.      Find or make your own breakout board for each device

In order to work with external devices, you need to find a breakout board, evaluation, or development kit for each device in the design.  If you cannot locate one for a device (or if it is too expensive), you can usually build one yourself by following the instructions of Chapter 9 of this book.  If that is not possible, for example if your device has some difficult-to-solder device package like BGA, you can sometimes find alternate packages for chips that have the same electrical properties with an easier-to-solder package. 

 

If your device requires extensive support circuitry to function, for example a special voltage regulator, it can be completely worthwhile to develop your own evaluation PCB for that device, for your own personal use, since developing such a board will prove that the pinout, footprint and support circuitry of your device is well understood before you go to build the whole system PCB.  These footprint files can then be reused in your system design, and you will know that they are already completely verified.

 

3.      Aim for basic functionality only

Once you connect your evaluation devices to the Starter Kit for testing, the focus should be to just get the part to basically function. Since you are connecting over jumper wires, there are situations where the electrical requirements of the signal interface won’t work at full speed, so keep the speed to the slowest allowable for the electrical interface and at the lowest drive strength on the EFM32 GPIO outputs.  Write code to do something simple, like reading a device ID register or making a simple write to make something happen on the device, before going into further functionality.   It may be possible that certain frequencies are unreachable, due to the complicated signal integrity issues that can happen over jumper wires, so don’t expect too much out of a breadboard mockup. 

 

The point of this process is to learn as much as you can about the requirements of the device before you go to design a custom PCB solution and integrate the device driver into the system software.  This isolates any issues to a single subsystem and makes your final development an exercise of system integration.

 

Keys to Breadboarding Success:

  • Start all projects with an isolated breadboard for every subsystem of the design
  • Develop evaluation boards for any tricky footprints or parts that require extensive onboard circuitry
  • Focus on getting parts “just working” and don’t expect full performance on a breadboard

 

Plan a Prototype Build

Once your breadboarding experiments are done and you have settled on the devices that will make up your EFM32 solution, it is time to develop a custom PCB to house all of those components together as a single system.  While it is tempting to also define the enclosure at this time and develop a tiny board that fits within the target enclosure, it is a better idea to develop your first custom PCB as a large test system that is focused on testing and development only.

 

1.      Use testpoints religiously

A built-for-test PCB is a version of the final solution that includes access to all signals in the design as testpoints.  Any signal in the design with a testpoint can then be probed either by a multimeter, oscilloscope, or logic analyzer.  A testpoint can be an exposed “pad” of copper, a through-hole junction that allows a header pin and jumper wire to be applied, or even a loop of metal for a probe clip.  It is also a good idea to place all components and test points on the top side of the built-for-test board, so that once again, debugging is easier because you can get to everything at once without needing to flip the board over.

 

To see the types of test points, just look at the back of your Starter Kit.  The plated through-hole test points are the ones that we have soldered header pins into.  The small gold round pads are the surface-mount test pads, which are suitable for probing or soldering tiny wires in which a small probe clip can be attached.

 

2.      Plan a for a hardware design spin

By planning a built-for-test version of the PCB, it will require at least one “spin” or redesign the board for the production solution.  It is very rare, almost impossible, to design a board that goes from first test to production in a single spin.  A built-for-test PCB allows you to interrogate the system during bring-up and study the electrical interfaces between devices easily, without resorting to special soldering skills to attach probe points to electrical signals.  A fully-featured through-hole JTAG debugger connector should be added to fully interact with the Simplicity Studio IDE as if your design was a Starter Kit.  While it is possible to develop production boards with UART-only programming, you will lose debugging functionality without a JTAG debug header, which is the 3M N2520-5002RB available here .

 

You can study power consumption of each device in the system by placing a precision resistor around 1 ohm between the power supply and each device, and then measuring (or scoping) the voltage difference across the precision resistor.

 

3.      Use a bigger, better version of the EFM32 part than you think you will need in production

When you develop your first custom PCB version of a design, use a version of the EFM32 family of parts that have more flash and RAM than what you think that your final solution will require.   You can sometimes keep the same pin count and footprint but gain additional flash and RAM by building your design with a more capable part than your final production solution.  The “Debug” builds in Simplicity Studio require more flash storage and RAM than the “Release” builds that use optimizers to reduce memory footprint, so by moving up to more capable parts during the prototyping stage, you will make debug possible.  You can also move up to more capable families with more pins if it will make the job of debugging your solution easier.   Just be careful not to rely upon features of the upgraded family that will disappear when you move to your production solution.  A selector guide that shows the capabilities, capacities, and pin counts of each device in each family is found here.

 

4.      Connect to your own PCB over JTAG as if it were a Starter Kit

When your built-for-test PCB arrives, to use the JTAG debug header on your PCB, you can attach an IDT cable, such as the Assmann H3CCH-2018G available here to the JTAG connector on the Starter Kit.  Then, under the Kit Manager tile in Simplicity Studio (after you have connected the Starter Kit to your computer) select Debug Mode: Out.

 debug_out.png

 

You may have to go back to the home page of Simplicity Studio and select the “Target Part.”  Do that, right click on the Starter Kit that is detected and select the choice for “Select Target Part...” 

select_targe.png
  

In the “Target Selection for EFM32...” window that opens, change the Target Interface to SWD, ignore any warnings that it produces (as long as you are connecting to an EFM32 part) and then click the Detect Target button.  Press the Yes button for any popup windows that appear until the Part label shows your actual device on your custom PCB.  This will prove that the JTAG connection from your Starter Kit to the EFM32 part on your custom PCB is being detected by Simplicity Studio on your computer.

 

detect_target.png
 
With all of these steps completed, whenever you launch your project in Simplicity Studio IDE, the part used for your project must match the part found in the target selection in order for flash programming and debugging to commence.  This allows you to debug your custom PCB as if it were a Starter Kit.

 

Keys to Prototyping Success

  • Don’t skip the prototype build—You won’t go “straight to production” on your first PCB anyway.
  • Add a JTAG connection to your first build as well as the largest, fully-featured EFM32 chip you can find.
  • Configure your project for the correct device and set your Starter Kit Debug Mode to Out to debug your own project as if it were a Starter Kit.

 In the next section, tips for software development and debug will be introduced.

  • Blog Posts
  • Makers

Tags

  • Wireless
  • High Performance Jitter Attenuators
  • EFR32MG21 Series 2 SoCs
  • Blue Gecko Series 2
  • Zigbee SDK
  • ZigBee and Thread
  • Internet Infrastructure
  • Sensors
  • Blue Gecko Bluetooth Low Energy SoCs
  • Z-Wave
  • Micrium OS
  • Blog Posts
  • Low Jitter Clock Generators
  • Bluetooth Classic
  • Makers
  • Flex SDK
  • Tips and Tricks
  • Smart Homes
  • IoT Heroes
  • Reviews
  • RAIL
  • Simplicity Studio
  • Mighty Gecko SoCs
  • Timing
  • Blue Gecko Bluetooth Low Energy Modules
  • Clocks
  • Ultra Low Jitter Clock Generators
  • General Purpose Clock Generators
  • Industry 4.0
  • Giant Gecko
  • 32-bit MCUs
  • blue-gecko-xpress-modules
  • Bluetooth Low Energy
  • 32-bit MCU SDK
  • Gecko
  • Microcontrollers
  • News and Events
  • Industrial Automation
  • Wi-Fi
  • Bluetooth SDK
  • Community Spotlight
  • Biometric Sensors
  • General Purpose Jitter Attenuators
  • Giant Gecko S1
  • Flex Gecko
  • Internet of Things
  • 8-bit MCUs
  • Isolation
  • Powered Devices

Top Authors

  • Avatar image Mark Mulrooney
  • Avatar image Siliconlabs
  • Avatar image Nari Shin
  • Avatar image lynchtron
  • Avatar image deirdrewalsh
  • Avatar image Lance Looper
  • Avatar image lethawicker

Archives

  • 2014 December
  • 2015 January
  • 2015 February
  • 2015 March
  • 2015 April
  • 2015 May
  • 2015 June
  • 2015 July
  • 2015 August
  • 2015 September
  • 2015 October
  • 2015 November
  • 2015 December
  • 2016 January
  • 2016 February
  • 2016 March
  • 2016 April
  • 2016 May
  • 2016 June
  • 2016 July
  • 2016 August
  • 2016 September
  • 2016 October
  • 2016 November
  • 2016 December
  • 2017 January
  • 2017 February
  • 2017 March
  • 2017 April
  • 2017 May
  • 2017 June
  • 2017 July
  • 2017 August
  • 2017 September
  • 2017 October
  • 2017 November
  • 2017 December
  • 2018 January
  • 2018 February
  • 2018 March
  • 2018 April
  • 2018 May
  • 2018 June
  • 2018 July
  • 2018 August
  • 2018 September
  • 2018 October
  • 2018 November
  • 2018 December
  • 2019 January
  • 2019 February
  • 2019 March
  • 2019 April
  • 2019 May
  • 2019 June
  • 2019 July
  • 2019 August
  • 2019 September
  • 2019 October
  • 2019 November
Silicon Labs
  • About Us
  • In the News
  • Email Newsletter
  • Cookies
  • Contact Us
  • Community
  • Site Feedback
  • Investor Relations
  • Blog
  • Privacy and Terms
  • Corporate Citizenship
Copyright © Silicon Laboratories. All rights reserved.
粤ICP备15107361号-1