NOTE: For FAQs relating to the BSP, see the dedicated BSP FAQ list.
The two board families take very different design approaches.
All of the nRF51 based modules are based on an AT command set (over UART or SPI), and require two MCUs to run: the nRF51 hosting the AT command parser, and an external MCU sending AT style commands.
The nRF52 boards run code directly on the nRF52, executing natively and calling the Nordic S132 SoftDevice (their proprietary Bluetooth Low Energy stack) directly. This allows for more efficient code since there is no intermediate AT layer or transport, and also allows for lower overall power consumption since only a single device is involved.
The nRF52 will generally give you better performance, but for situation where you need to use an MCU with a feature the nRF52 doesn't have (such as USB), the nRF51 based boards will still be the preferable solution.
No. The two board families are fundamentally different, and have entirely separate APIs and programming models. If you are migrating from the nRF51 to the nRF52, you will need to redesign your sketches to use the newer API, enabling you to build code that runs natively on the nRF52832 MCU.
The S132 Soft Device and the nRF52832 HW support Central mode, so yes this is possible. At this early development stage, though, there is only bare bones support for Central mode in the Adafruit nRF52 codebase, simply to test the HW and S132 and make sure that everything is configured properly. An example is provided of listening for incoming advertising packets, printing the packet contents and meta-data out to the Serial Monitor. We hope to add further Central mode examples in the future, but priority has been given to the Peripheral API and examples for the initial release.
In order to run Arduino code on the nRF52 at the same time as the low level Bluetooth Low Energy stack, the Bluefruit nRF52 Feather uses FreeRTOS as a task scheduler. The scheduler will automatically switch between tasks, assigning clock cycles to the highest priority task at a given moment. This process is generally transparent to you, although it can have implications if you have hard real time requirements. There is no guarantee on the nRF52 to meet hard timing requirements when the radio is enabled an being actively used for Bluetooth Low Energy. This isn't possible on the nRF52 even without FreeRTOS, though, since the SoftDevice (Nordic's propietary binary blob stack) has higher priority than any user code, including control over interrupt handlers.
You can, yes, but it will require a Segger J-Link (that's what we've tested against anyway, other options exist), and it's an advanced operation. But if you're asking about it, you probably know that.
Assuming you have the Segger J-Link drivers installed, you can start Segger's GDB Server from the command line as follows (OSX/Linux used here):
$ JLinkGDBServer -device nrf52832_xxaa -if swd -speed auto
Then open a new terminal window, making sure that you have access to gcc-arm-none-eabi-gdb
from the command line, and enter the following command:
$ ./arm-none-eabi-gdb something.ino.elf
`something.ino.elf
` is the name of the .elf file generated when you built your sketch. You can find this by enabling 'Show verbose output during: [x] compilation' in the Arduino IDE preferences. You CAN run GDB without the .elf file, but pointing to the .elf file will give you all of the meta data like displaying the actual source code at a specific address, etc.
Once you have the (gdb)
prompt, enter the following command to connect to the Segger GDB server (updating your IP address accordingly, since the HW isn't necessarily local!):
(gdb) target remote 127.0.0.1:2331
If everything went well, you should see the current line of code where the device is halted (normally execution on the nRF52 will halt as soon as you start the Segger GDB Server).
At this point, you can send GDB debug commands, which is a tutorial in itself! As a crash course, though:
- To continue execution, type '
monitor go
' then 'continue
' - To stop execution (to read register values, for example.), type '
monitor halt
' - To display the current stack trace (when halted) enter '
bt
' - To get information on the current stack frame (normally the currently executing function), try these:
-
info frame
: Display info on the current stack frame -
info args
: Display info on the arguments passed into the stack frame -
info locals
: Display local variables in the stack frame -
info registers
: Dump the core ARM register values, which can be useful for debugging specific fault conditions
If you have a Segger J-Link, you can also use Segger's OZone debugger GUI to interact with the device, though check the license terms since there are usage restrictions depending on the J-Link module you have.
You will need to connect your nRF52 to the J-Link via the SWD and SWCLK pins on the bottom of the PCB, or if you are OK with fine pitch soldering via the SWD header.
You can either solder on a standard 2x5 SWD header on the pad available in the board, or you can solder wires to the SWD and SWCLK pads on the bottom of the PCB and use an SWD Cable Breakout Board, or just connect cables directly to your J-Link via some other means.
You will also need to connect the VTRef pin on the JLink to 3.3V on the Feather to let the J-Link know what voltage level the target has, and share a common GND by connecting the GND pins on each device.
Before you can start to debug, you will need to get the .elf file that contains all the debug info for your sketch. You can find this file by enabling Show Verbose Output During: compilation in the Arduino Preferences dialogue box. When you build your sketch, you need to look at the log output, and find the .elf file, which will resemble something like this (it will vary depending on the OS used): /var/folders/86/hb2vp14n5_5_yvdz_z8w9x_c0000gn/T/arduino_build_118496/ancs_oled.ino.elf
In the OZone New Project Wizard, when prompted to select a target device in OZone select nRF52832_xxAA, then make sure that you have set the Target Interface for the debugger to SWD, and finally point to the .elf file above:
Next select the Attach to running program option in the top-left hand corner, or via the menu system, which will cause the debugger to connect to the nRF52 over SWD:
At this point, you can click the PAUSE icon to stop program execution, and then analyze variables, or set breakpoints at appropriate locations in your program execution, and debug as you would with most other embedded IDEs!
Clicking on the left-hand side of the text editor will set a breakpoint on line 69 in the image below, for example, and the selecting Debug > Reset > Reset & Run from the menu or icon will cause the board to reset, and you should stop at the breakpoint you set:
You can experiment with adding some of the other debug windows and options via the View menu item, such as the Call Stack which will show you all of the functions that were called before arriving at the current breakpoint:
Yes, by running one board in peripheral mode and one board in central mode, where the central will establish a connection with the peripheral board and you can communicate using BLE UART or a custom service. See the following Central BLE UART example to help you get started: https://github.com/adafruit/Adafruit_nRF52_Arduino/tree/master/libraries/Bluefruit52Lib/examples/Central
This is probably caused by a conflict between 32-bit and 64-bit versions of the compiler, libc and the IDE. The compiler uses 32-bit binaries, so you also need to have a 32-bit version of libc installed on your system (details). Try running the following commands from the command line to resolve this:
sudo dpkg --add-architecture i386 sudo apt-get update sudo apt-get install libc6:i386
If you get this error:
Timed out waiting for acknowledgement from device.
Failed to upgrade target. Error is: No data received on serial port. Not able to proceed.
Traceback (most recent call last):
File "nordicsemi\__main__.py", line 294, in serial
File "nordicsemi\dfu\dfu.py", line 235, in dfu_send_images
File "nordicsemi\dfu\dfu.py", line 203, in _dfu_send_image
File "nordicsemi\dfu\dfu_transport_serial.py", line 155, in send_init_packet
File "nordicsemi\dfu\dfu_transport_serial.py", line 243, in send_packet
File "nordicsemi\dfu\dfu_transport_serial.py", line 282, in get_ack_nr
nordicsemi.exceptions.NordicSemiException: No data received on serial port. Not able to proceed.
This is probably caused by the bootloader version mismatched on your feather and installed BSP. Due to the difference in flash layout (more details) and Softdevice API (which is bundled with bootloader), sketch built with selected bootloader can only upload to board having the same version. In short, you need to upgrade/burn bootloader to match on your Feather, follow above Update The Bootloader guide
It only has to be done once to update your Feather
They all support BLE Mesh, but we don't provide Arduino library for Mesh. You need to write code based on Nordic sdk mesh.
If you get error similar to this:
Arduino: 1.8.8 (Mac OS X), Board: "Adafruit Bluefruit nRF52832 Feather, 0.2.9 (s132 6.1.1), Level 0 (Release)"
[1716] Error loading Python lib '/var/folders/gw/b0cg4zm508qf_rf2m655gd3m0000gn/T/_MEIE6ec69/Python': dlopen: dlopen(/var/folders/gw/b0cg4zm508qf_rf2m655gd3m0000gn/T/_MEIE6ec69/Python, 10): Symbol not found: _futimens
Referenced from: /var/folders/gw/b0cg4zm508qf_rf2m655gd3m0000gn/T/_MEIE6ec69/Python (which was built for Mac OS X 10.13)
Expected in: /usr/lib/libSystem.B.dylib
in /var/folders/gw/b0cg4zm508qf_rf2m655gd3m0000gn/T/_MEIE6ec69/Python
exit status 255
Error compiling for board Adafruit Bluefruit nRF52832 Feather.
It is probably due to the pre-built adafruit-nrfutil cannot run on your Mac. The binary is generated on MacOS 10.13, if your Mac is older than that. Please update your macOS, or you could follow this repo's readme here https://github.com/adafruit/Adafruit_nRF52_nrfutil to manual install it ( tried with pip3 first, or install from source if it doesn't work). Then use the installed binary to replace the one in the BSP.
Text editor powered by tinymce.