Advice for Designing with the nRF52

The Field Application Engineers (FAEs) at Nordic Semiconductor work hard every day to help customers be successful with their designs. In that process, a number of issues come up repeatedly. This list was created to help the designer avoid those potential pitfalls ...

  1. Follow the reference design, particularly the RF, decoupling, trace size, part selection and material areas. Any deviation from the reference design will likely result in reduced performance, even something so small as changing the geometry of a component position or trace. Via’s in RF lines are evil.

  2. Leave 3 additional place holders near the antenna for a PI tuning network. It is easier to remove them later than add them.

  3. Use the DK design as a GPIO template. If your software can run on the DK, it will allow Nordic engineers to more easily support you if needed. The headers on the DK implement the Arduino Uno pin-out. Use that interface to rapidly create your system by stacking sensors or proto-board custom circuits on the DK without needing to build a complete prototype PCB.

  4. There is no “best” antenna, only the one that’s best for your needs. If you can afford the PCB space, the DK’s monopole is low-cost, has excellent performance and can be well tuned by trimming it to length. Meandering antennas are slightly smaller and have reduced nulls and slightly shorter range. Chip antennas provide good performance in size constrained designs. Batteries and other metallic items, including the enclosure itself, will influence antenna design and placement.

  5. Use the software examples in the SDK as a template. Pick an example close to your own needs and modify it. This will also assist Nordic in supporting you. No one starts from a blank page.

  6. nRF5-SDK: If you are using the SoftDevice, pay attention to the SoftDevice spec, especially chapter 7. If you access something the spec describes as “restricted” from your application, you will likely experience a hard fault.

  7. Review the device errata and note what applies to your design. Nordic is very open about this information. Ignore it at your peril.

  8. Provide access in your design and layout for the SWD pins (VDD, GNS, SWDIO and SWDCLK) and, preferably, 2 pins for the UART as well. While you can access the debug_log via the SWD (RTT) as well as the UART, in order to easily run both the Radio Test Example (for FCC testing) and the Direct Test Mode example (for BT qualification), you should pin out the UART signals. No need to bring out the RTS/CTS signals.

  9. Consider using the Tag-Connect layout for the SWD connections. This is a zero-cost option on your PCB that is compatible with bed-of-nails gang programming.

  10. If you are connecting the nRF52 to a host processor, connect a few extra GPIO pins (if available) between the nRF52 and the host processor for future use.

  11. Remember that all the digital GPIO pins can be configured for almost any digital purpose. Use that to optimize your layout.

  12. Observe the restrictions on high-frequency pin usage near the RF pins to maximize receiver sensitivity (if applicable).

  13. Use the DK’s DEBUG_OUT port for debug and initial programming purposes. If your needs outstrip its capabilities, you can purchase a more expensive and capable device. You can use the DEBUG_IN port on the DK to verify that your new debugger is working.

  14. Production programming can be done by buying pre-programmed devices (from distribution) or programming them via the SWD interface during production. It’s normal to see bed-of-nails connections and gang-programmers used. See this paper.

  15. If you are using a CSP package, make sure to cover the device sides with a coating to prevent IR light intrusion issues.

  16. Use the index.html link in the documentation folder of the nRF5-SDK to go directly to pertinent Infocenter

  17. Use the Infocenter. Search the Nordic DevZone for answers. Use your Nordic FAEs. Open public or private support cases as needed. Close them when you are finished.

  18. Save a maximum of 35% of your power by enabling/populating the DCDC converter (none of the examples do this) and another 2 - 10% by enabling/populating the 32kHz crystal (all the examples do this). There is no combination of circumstances where having these in place will not result in lower current, though the percentage saved is lower at lower voltages.

  19. If you think your device is in SYSTEM_ON idle and it’s drawing 3 -4mA, it’s not really in idle ... the CPU is still running. If you are in SYSTEM_OFF mode and drawing more than a few hundred nA, you’re not in really in SYSTEM_OFF mode. It’s common to find that the part is actually in DEBUG INTERFACE MODE rather than SYSTEM_OFF mode when the debugger is connected.

  20. The transmitter output power defaults to 0dBm at reset. If you want something different, you must set it in your code.

  21. The nRF52 debugger interface may remain on if the nRF52 is not turned off prior to removing the JTAG connection. If production programmed parts are not power cycled, the debug interface may remain on and continue to draw excessive current.

  22. The nRF52 devices are optimized for running at 3v (although the ‘840 will accept 5V). Running at lower voltages will not result in reduced power consumption.

  23. Use the online power profiler and Product Spec numbers to estimate your average current. Use the PPK2 or another correct method to measure it. 

  24. Make sure to power your design with a battery when measuring current, since a power supply can introduce unknown variables. Don’t expect a DMM to properly measure current that changes by 3000x in microseconds.

  25. It is a good idea to provide two pads and a cut-able bridge between them on the top PCB layer in the VDD supply to the nRF52. This will facilitate current measurements and optimization. If the nRF52 power is combined with other circuitry, you will not be able to measure it independently .

  26. Run your code on the DK to eliminate hardware issues. Run SDK example code on your hardware to eliminate software issues.

  27. All the examples use the external 32kHz crystal. The SoftDevice will hard-fault if your design does not have the crystal and your code tells the SoftDevice to use it. nRF5-SDK: Configure the pca10040.h file or sdk_config.h ( nRF_SoftDevice / NRF_SDH_ENABLED) to use the internal low-frequency oscillator if you don’t have an external 32kHz crystal. Be sure to set the accuracy to 500PPM or you may see occasional disconnects. An external clock source may alternately be used for the 32kHz clock (SiTime or similar). An external clock must meet the phase and jitters specifications for the nRF device you are using.

  28. The 32MHz high-frequency crystal is mandatory for SoftDevice operations. Be aware that if only the CPU is in operation, it may use the internal 64-MHz oscillator instead.

  29. Learn to use the error handler and debug output (via RTT or UART) to debug error conditions. Know where to find the meanings of the codes. The SoftDevice outputs and logs important data for its status and errors. For instance, it will tell you if your memory settings are incorrect and what to change them to.

  30. Learn to use the command line tools, especially nrfjprog. This tool is very handy for erasing/programming your nRF52, enabling the reset pin function and locking the SWD port from readback. This last feature will erase the part if someone tries to read your code from the nRF52. Use the command line tools instead of nRFGo Studio.

  31. Pick a battery applicable to your design. nRF52 pulse currents are 7mA (with DCDC) and 12mA (w/o DCDC). Proper decoupling can mitigate the effects of these pulses on a battery, but high pulse currents can reduce the overall capacity of a coin cell significantly.

  32. Be aware of the following from the POWER section of the product specification: A step increase in supply voltage of 300 mV or more, with rise time of 300ms or less, within the valid supply range, may result in a system reset.

  33. nRF5-SDK: Nordic supports four different IDEs. The root folder in the SDK includes MDK files for IAR and Keil. Make sure to run these when you update your SDK. These files provide IDE-specific files and errata work-arounds.

  34. Free versions of the IDEs may have size restrictions. Be aware of the costs and limitations before committing to an IDE.

  35. While debugging code with the SoftDevice (Nordic’s BLE stack), remember that setting breakpoints will cause a hard-fault due to BLE timing being violated. This will result in a broken connection and the software trapping in the error-handler.  Alternatives include using RTT or UART for debug messages and/or toggling GPIOs to indicate software states.  See this blog for a rundown on debugging with the SoftDevice.

  36. Try to offload as many tasks to the PPI (Programmable Peripheral Interconnect) subsystem as possible to make your system more deterministic and reduce CPU load. For instance, upon a timer expiration, a GPIO may be toggled without any CPU intervention.  Another example: upon receiving a packet from the radio, a SPI transaction can start without CPU intervention.  See here for more information on the PPI subsystem.

  37. When using the Keil IDE, make sure to set optimizations to 0 (OFF) and define the DEBUG symbol to enable debugging code to be compiled as well. SDK examples do not have the DEBUG symbol defined by default.  These steps will enable you to step through the source much easier as well as see debug log information on a UART or RTT terminal.

  38. nRF5-SDK: When adding a Nordic-provided library or driver to your source code, ensure that:

    a) It is added to the project file of your development suite.
    b) It is enabled in sdk_config.h; defines in this file enable/disable/configure Nordic libraries and drivers during compilation.
    c) The directory path of the driver/library is added to the compiler’s search path the header files for the newly added source code can be found.

  39. It is recommended to use RTT for log output rather than the UART, as it is higher-performance for outputting debug information.

  40. Bluetooth Qualification and FCC/ETSI/etc. testing can be time consuming and confusing. Nordic can offer guidance and suggestions. You don’t want yours to be the first Nordic design a testing house has ever seen.

  41. Contact your Distributor or Nordic Regional Sales Manager regarding product availability and forecast planning as early as possible. The parts you need may not otherwise be available when you need them.

  42. Nordic offers schematic and layout review. Simply submit a private support case with your files. Send Nordic your schematic before working on your layout. This will save potential re-layout work for you. Nordic engineers who optimize this very design every single day will help you optimize your design and, hopefully, pass certification the first time. For free. The process normally takes a couple of days.

  43. Nordic is not a testing house, but after the previous step you can ship your enclosed prototype to Norway for RF characterization and antenna tuning. For free. The testing normally takes about a week. Nordic uses the Direct Test Mode (DTM) or Radio Example software from the SDK programmed into your device for this purpose.

  44. The SPI port receive buffer size is determined by the RXD.MAXCNT register. This register is 8-bits long on the '832 and 16-bits long on the '840. You may find that the '832's buffer size limits large data throughputs more than the '840's.

  45. Nordic provides a fault handler that stores fault information and then resets the device. It is up to the designer to change this behavior to what makes sense for their design. You might consider having the fault handler trigger the bootloader so that a firmware update would be possible (in order to fix the fault). Note that the bootloader can be programmed to time out after a set period and then transfer execution to your application. The default fault handler code stores the name (string) of the file and the line number in RAM where the fault was generated .You might also consider writing that information to flash and then adding the ability in your bootloader code to transfer that information to your mobile app before performing the DFU.

  46. When using buttonless DFU you should consider what to do if you somehow break the process and are unable to broadcast the DFUTarg advertisement. If you have any kind of button on your device you should think about configuring the bootloader code to use that button to initiate the DFU process. That way, even if you send out an update that breaks buttonless DFU, you can still recover the device by holding that button down at power-up. It's cheap insurance.