ARM C++ Programming Reference

Useful coding references for nRF52840 microcontrollers

Variable Declaration

signed char,   int8_t
unsigned char, uint8_t
signed short,  int16_t
unsigned short,uint16_t
signed int,    int32_t
unsigned int,  uint32_t
signed long,    int64_t
unsigned long,  uint64_t

Useful Basic Function

nrf_delay_ms(500);                 //delay in msec
bsp_board_init(BSP_INIT_LEDS);     //initialising LED
bsp_board_led_invert(0);           //toggle LED
nrf_gpio_pin_set(LED_1); or bsp_board_led_on(0);
nrf_gpio_pin_clear(LED_1); or bsp_board_led_off(0);


//UART initialisation
const app_uart_comm_params_t comm_params =
#if defined (UART_PRESENT)



uint8_t cr;           //declare byte
app_uart_put(cr);     //send byte
app_uart_get(&cr);    //get byte
printf("\r\nUART example started.\r\n");     //print to UART

nRF5x Project Structure

All the function is written in a manner that is portable and general purpose coding. This may make it very difficult to read and understand. But basically, it works like PIC microcontroller where each pin or peripheral can be individually configure.

The entry point to the program is at “main.h” -> “int main(void)”.

Hardware specific “fixed” configuration are all done in “pca10056.h“. All pins input/output definition are configured in this file which is very specific to this designed pca10056 circuit board.

“boards.c” contains generic codes for managing the LED and Push Buttons codes.

Project (Solution) specific codes will be under the Application folder. Usually consist of “main.c” where the code starts, and “sdk_config.h” where are the configuration of the application will be.

Function that starts with sd_XXXXXX(), these are the basic functions provided directly from softdevice API module.

Function that starts with nrf_XXXXXX(), these are functions by nRF encapsulation softdevice API sd_XXXXXX().

Data type naming convention ends with XXXXXX_t

sec  - security
conn - connection
lbs  - led button service
ble  - Bluetooth low energy
auth - authorised
evt  - event
adv  - advertisement
lesc - LE security
len  - length
gattc_evt- GATT client event
gatts_evt- GATT server event

Peripheral useful for projects

More information of the examples project can be found at

More information about the library used in the example, refer to the SDK Library reference notes,

  • Digital IO pins (project “blinky“)
  • Pin Change Interrupt (project “pin_change_int“)
  • UART (project “uart“, “serial“)
  • Timer (project “timer“, “gpiote“)
  • Pin Change Interrupt (project “pin_change_int”)
  • Power Management (project “pwr_mgmt”)
  • SPI (project “spi“)
  • PWM (project “led_softblink“, “low_power_pwm“)
  • Watch Dog Timer (project “wdt”)
  • Low Energy Bluetooth BLE

Pin maps for the nRF52840-DK board examples demonstration

PeripheralsPin out in the nRF52840 example demo

One of the more important BLE event function

This ble_evt_handler() is callback whenever the BLE events occurs. The lower level will be called and propagated up to our application level through ble_evt_handler() where we will handle the BLE message.

For interrupt there are a total of 4 levels. Highest interrupt priority is taken by SoftDevice, the next level is by the application. Followed by a lower priority SoftDevice, then the lowest priority to the application.

How interrupts are handled by SoftDevice.

/**@brief Function for handling BLE events.
 * @param[in]   p_ble_evt   Bluetooth stack event.
 * @param[in]   p_context   Unused.
static void ble_evt_handler(ble_evt_t const * p_ble_evt, void * p_context)

The path of the incoming data event (BLE_GATTS_EVT_WRITE) start from
ble_conn_params.c->ble_evt_handler(ble_evt_t const * p_ble_evt, void * p_context),
then followed by
ble-lbs.c->ble_lbs_on_ble_evt(ble_evt_t const * p_ble_evt, void * p_context)
main.c->ble_evt_handler(ble_evt_t const * p_ble_evt, void * p_context)

For the event object p_ble_evt, the data structure is very large. But not all data in the structure are valid. It depends on the event that had took place. Read only that section of the structure. nRF simply lump everything into this single data structure. In actual fact the data communication isn’t so large.

nRF Object Class Documentation

Application Level
- LED Button Service modules

Middle Level
- GATT request queue module. Commands from application to SoftDevice are put to a queue system here

Close to SoftDevice Level

Low Level (Hardware)
boards.h, pca10056.h, bsp.h
- hardware board related. Board Support Package

nRF Singleton Object Instance

m_ represent singleton object.

- LED Button Service object for the Central device

- BLE scanning object

- GATT object

- DB Discovery object

- GATT queue object
p_ represent pointer to object
//Explore Variable p_ble_evt
    //  p_ble_evt
    //      header
    //          evt_id          //type of Bluetooth events
    //          evt_len
    //      evt
    //          common_evt      //common event
    //              conn_handle
    //              params
    //                  user_mem_release
    //                  user_mem_request
    //          gap_evt         //GAP originated event
    //              conn_handle
    //              params
    //                  adv_report
    //                  adv_set_terminated
    //                  auth_key_request
    //                  auth_status                     //(ble_gap_evt_auth_status_t)
    //                      auth_status                 //< Authentication status, see @ref BLE_GAP_SEC_STATUS.
    //                      error_src                   //< Authentication status, see @ref BLE_GAP_SEC_STATUS.
    //                      bonded                      //< Procedure resulted in a bond.
    //                      lesc                        //*< Procedure resulted in a LE Secure Connection.
    //                      sm1_levels                  //< Levels supported in Security Mode 1.
    //                          lv1
    //                          lv2
    //                          lv3
    //                          lv4
    //                      sm2_levels                  //< Levels supported in Security Mode 2.
    //                          lv1
    //                          lv2
    //                          lv3
    //                          lv4
    //                      kdist_own                   //< Bitmap stating which keys were exchanged (distributed) by the local device. If bonding with LE Secure Connections, the enc bit will be always set.
    //                          enc
    //                          id
    //                          link
    //                          sign
    //                      kdist_peer                  //< Bitmap stating which keys were exchanged (distributed) by the remote device. If bonding with LE Secure Connections, the enc bit will never be set.
    //                          enc
    //                          id
    //                          link
    //                          sign
    //                  conn_param_update
    //                  conn_param_update_request
    //                  conn_sec_update
    //                  connected
    //                  data_length_update
    //                  data_length_update_request
    //                  disconnected
    //                  key_presed
    //                  lesc_dhkey_request
    //                  passkey_diplay
    //                  phy_update
    //                  phy_update_request
    //                  qos_channel_survey_report
    //                  rssi_changed
    //                  scan_req_report
    //                  sec_info_request
    //                  sec_params_request
    //                  sec_request
    //                  timeout
    //          gattc_evt       //GATT client
    //              conn_handle
    //              error_handle
    //              gatt_status
    //              params
    //                  attr_info_disc_rsp
    //                  char_disc_rsp
    //                  char_val_by_uuid_read_rsp
    //                  char_vals_read_rsp
    //                  desc_disc_rsp
    //                  exchange_mtu_rsp
    //                  hvx
    //                  prim_srvc_disc_rsp
    //                  read_rsp
    //                  rel_disc_rap
    //                  timeout
    //                  write_cmd_tx_complete
    //                  write_rsp
    //          gatts_evt       //GATT server
    //              conn_handle
    //              params
    //                  authorize_request
    //                  exchange_mtu_request
    //                  hvc
    //                  hvn_tx_complete
    //                  sys_attr_missing
    //                  timeout
    //                  write
    //          l2cap_evt       //L2CAP, Logical Link Control and Adaptation Layer Protocol
    //              conn_handle
    //              local_cid
    //              params
    //                  ch_sdu_buf_released
    //                  ch_setup
    //                  ch_setup_refused
    //                  ch_setup_request
    //                  credit
    //                  rx
    //                  tx

Naming convention used in nRF SDK BLE codes

....xxx_t => the "_t" defines the data object type.

scan_evt => scan event data to the main application

nrf_ble_scan => Bluetooth scanning parameters

ble_gap_evt_adv_report => Advertise Report object
ble_evt_t -> ble_gap_evt_t -> ble_gap_evt_adv_report_t

ble_gap_evt => GAP event

//Advertise Data
p_adv_report->data.p_data => Advertising data pointer
p_adv_report->data.len => Advertising data length
Example data:
03 19 00 00 02 01 06 0E |........
09 4E 6F 72 64 69 63 5F | Nordic_
42 6C 69 6E 6B 79       |Blinky

Advertise data starts (length of 22 of the whole packet)
This advertise packet consist of 3x Advertising Data (AD) elements

First byte 03 indicates the length of the first element which is 03 19 00 00.
19 is the AD type «Appearance»
00 00 is the data for Appearance which is unknown
The next set of AD element is 02 01 06.
First byte 02 indicates the length.
01 is the AD type for «Flags»
06 is the data for flags.
It indicates that BR/EDR is Not supported, and LE General Discoverable Mode is true.
The next set of AD element is 0E 09 4E 6F 72 64 69 63 5F 42 6C 69 6E 6B 79
0E is the total number of data bytes which is 14.
The AD type is 09, which stands for «Complete Local Name».
The data 4E 6F 72 64 69 63 5F 42 6C 69 6E 6B 79 represent "Nordic_Blinky" which is the name of the device.

The AD type code can be found on this page,

<- Back to Bluetooth Resources Page