NRF51822 revision 1: Development environment

[BuriedCode]

I have a number of BLE modules I bought from various distributors (yes, Aliexpress was one...) to test and set up a reasonable development environment for creating fairly basic BLE devices.

One of them is a WT51822-S4AT module with an NRF51822 which, according to OpenOCD, is revision 1 (nRF51822-QFAA(build code: CA/C0).  The others are NRF52 based - with one other NRF51822, but that's revision 3.  I have this revision 3 device tested with Arduino, but will set up VisualStudio Code for actual development (Arduino environment was just for confirming hardware).

So, I'm stuck with just one module, revision 1 hardware and would like to put it to some use - nothing major, perhaps a small BLE remote for android.  However, after googling and coming across this forum it seems, since the revision 1 is so old I would need a softdevice S110 v5.2.1, and nrf51 SDK 4.4.2 according to this post:  nRF51822 revision 1 programming 

I managed to download the softdevice hex, and the ZIP of the SDK 4.4.2, but am unsure what development environment to use.  It seems NRF Connect is too recent to work with the old revision 1, so using Segger (free license for nrf51822), or Visualstudio code (with NRF Connect extension) are out.  Would I have to set up eclipse? And if so, are all that is needed is the IDE, the SDK, and softdevice?  I can flash using STlinkv2 and OpenOCD so hardware connection won't be a problem.  But setting up the toolchain seems like much more work than just what I've mentioned.

Its a pain to do this just for one device, but would be nice to put it to work, even if its just a small BLE test application. Perhaps the trial version of Keil IDE?

[Vidar Berg]

Hello,

nrf51 SDK 4.4.2 supports IAR, GNU Make, and Keil4 uVision for building (Only selected projects can be built with GCC/IAR.) However, I'm not sure if you will find a version of IAR or Keil old enough to be compatible with this SDK available for download. The ARM GCC toolchain can be downloaded at https://launchpad.net/gcc-arm-embedded/4.9/4.9-2015-q3-update. 

Best regards,

Vidar

[BuriedCode]

Thanks for the prompt reply, and apologies for my late response - was googling around trying to download the relevant software and messing about with revisions to see what works.  With the version you pointed to I was able to use Keil uVision 5 (community license) too get the blink example working with the WT51822-S4AT module - its on my bench right now with a nice lightshow.  Used a cheap STLinkv2 clone as the debugger.

Along with:

NRF SDK 4.4.2

ARM compiler V5.06u7 (used for the blinky example, it seems all examples are made for this compiler, works out the box)

GCC ARM v4_7-2014q2 (as backup, as yet untested in hardware, but seems to compile if linker script and include paths are added to Keil project options. The file structure of the examples is odd and I had to manually add lots of paths to the project for it to pick up the header files required. Produced a 'hex' but only with the HID example, which didn't work, but that could easily be hardware  as this module has no 32kHz xtal)

This was all just to verify I could compile and flash the target chip - revision 1 QFAA CA/C0 - so hopefully, I can move on to actual BLE apps/examples.   I included all the details, revision numbers here so others can find this thread in search if they happen to get this module or another module with this revision chip.

[Vidar Berg]

Thanks for the update. It's good to hear that you were able to build with Keil uVision5. This SDK did not include Keil v5 project files, so I assumed that Keil v4 would be required.

BuriedCode said:

GCC ARM v4_7-2014q2 (as backup, as yet untested in hardware, but seems to compile if linker script and include paths are added to Keil project options.

I have not tried to use GCC with Keil, I've only used it with the Makefiles. One important difference is that they use different startup files.

BuriedCode said:

Produced a 'hex' but only with the HID example, which didn't work, but that could easily be hardware  as this module has no 32kHz xtal)

The Softdevice will request the 32K clock source when it is enabled through BLE_STACK_HANDLER_INIT(), and the source is set to the crystal oscillator by default. You can change this to the internal RC oscillator with the NRF_CLOCK_LFCLKSRC_RC_250_PPM_4000MS_CALIBRATION symbol.

e.g.

/**@brief Function for initializing the BLE stack.
 *
 * @details Initializes the SoftDevice and the BLE event interrupt.
 */
static void ble_stack_init(void)
{
    BLE_STACK_HANDLER_INIT(NRF_CLOCK_LFCLKSRC_RC_250_PPM_4000MS_CALIBRATION,
                           BLE_L2CAP_MTU_DEF,
                           ble_evt_dispatch,
                           false);
}

Please note that the hex file generated by the build does not include the Softdevice binary. The Softdevice needs to be flashed separately.

[BuriedCode]

Vidar Berg said:

The Softdevice will request the 32K clock source when it is enabled through BLE_STACK_HANDLER_INIT(), and the source is set to the crystal oscillator by default. You can change this to the internal RC oscillator with the NRF_CLOCK_LFCLKSRC_RC_250_PPM_4000MS_CALIBRATION symbol.

Ahhs, eys, I read about this in other threads, but wasn't sure where to actually change the clocksource - or if it had to be done in multiple files - but the pointer you gave meant I could just search for the handler.

Vidar Berg said:

Please note that the hex file generated by the build does not include the Softdevice binary. The Softdevice needs to be flashed separately.

I had done this - flashed the softdevice (s110, v5.2.1) - but... I think when I flashed the application, I had "Erase Full Chip" set in the Keil's STLinkV2 debugger settings, so it was wiped when the application was flashed.

Changed that to "Erase Sectors", used openocd and the STLinkV2 to flash the softdevice again, then keil for the HID application.  After making slight modification to the button/LED GPIO numbers, I now have that up and running - tested on Android and Windows 10! 

So that's pretty much everything I wanted to achieve, and I can now play about with the examples for different functionality, as well as make a jig for (accurately) testing current consumption for optimising power usage.

Thanks again for your help, wouldn't have known where to start without it!

Cheers,

Scott

[Vidar Berg]

Hi Scott,

Great, I'm glad to hear that it worked. I just want to add that the nRF51 series is not recommended for new designs, in case anyone else is reading this. It's also not possible to qualify new designs with Bluetooth SIG using this series silicon revision 1:  What impact does the deprecation and withdrawal of Bluetooth Core specification v4.0 and v4.1 have on your current and future products? 

BuriedCode said:

The others are NRF52 based

 For these you can use our online power profiler at Online Power Profiler for Bluetooth LE if you want to estimate the expected current consumption for your configuration. 

Cheers, 

Vidar