Overview of nRF52 Series

Before diving into the development kits, let’s briefly discuss what makes the nRF52 series so popular. The series is built on a powerful ARM Cortex-M4 CPU and offers excellent RF performance, low power consumption, and multiple I/O peripherals. The key features that make the nRF52 series attractive include:

Now let’s move on to the development kits themselves.

1. nRF52832 Development Kit (PCA10040)

Pros:

Cons:

2. nRF52840 Development Kit (PCA10056)

Pros:

Cons:

3. nRF52833 Development Kit (PCA10100)

Pros:

Cons:

4. nRF52811 Development Kit (PCA10056e)

Pros: 

Cons:

5. nRF5340 Development Kit (PCA10095)

Pros:

Cons:

Conclusion

Choosing the right development kit depends on the complexity of your project and the specific features you need. Here’s a quick summary:

No matter which kit you choose, Nordic's nRF Connect SDK and Segger Embedded Studio will ensure a smooth development experience. Happy coding!

The post nRF52 Development Kit Comparison: Which One Should You Choose? appeared first on Teach Me Microcontrollers!.

Cloning the nRF52 SES Template

To begin, we’ll use a pre-configured template available on GitHub, which already has some of the initial settings in place. Clone or download the repository from this link:

git clone https://github.com/eldstal/nrf52-ses-template.git

Once you have the project downloaded, extract the files or navigate to the directory where you cloned the repository.

Understanding the SES Project Structure

The structure of an SES project for nRF52 typically follows the layout used in Nordic's SDK. If you're using the PCA10040 SDK, the project is organized in a standard folder hierarchy. Here's a breakdown:

Project Folder: This is the root of your project, where the main.c file resides. This file contains the main application code for your project.

Project_Folder/
├── main.c
└── pca10040/

pca10040 Folder: This folder is specific to the nRF52832-based development kit (PCA10040). Inside, you'll find specific configurations for this board. 

Project_Folder/
├── pca10040/
└── s132/

s132 Folder: This folder corresponds to the SoftDevice you're using, such as S132 for Bluetooth applications on nRF52832.

Project_Folder/
├── pca10040/
└── s132/
└── ses/

ses Folder: This folder contains the Segger Embedded Studio project files, including the .emProject file that opens the project in SES and flash_placement.xml which outlines the memory layout of the nRF52. If you have user-defined headers and source code, it is also advisable to put them in here.

Project_Folder/
├── pca10040/
├── s132/
└── ses/
    └── your_project.emProject
    └── flash_placement.xml
    └── Source/
       └── user-defined-source-1.c
       └── user-defined-source-2.c
    └── Include/
       └── user-defined-header-1.h
       └── user-defined-header-2.h
    └── Output/
       └── Debug/
            └── Exe/  --> .elf, .hex, .map files are here
            └── Obj/  --> .o files are here

Thus, when you open the project in SES, you'll typically navigate to pca10040 > s132 > ses to locate the .emProject file, which is the project’s entry point.

The Output folder will be created when the project successfully compiles. If you have a Debug configuration, you will see a Debug folder and inside it are the binaries you need to upload to the nRF52 SDK as well as the compiled object files.

Opening the Project in SES

Once you have your folder structure and project files set up, open the project in SES:

1. In SES, go to File > Open Solution.
2. Navigate to Project_Folder > pca10040 > s132 > ses and select the .emProject file.

This will open the project with pre-configured settings for the PCA10040 development kit and the S132 SoftDevice, assuming you’re working with Bluetooth.

Configuring the SDK Path

After opening the project, you'll need to configure the SDK path so SES can find the necessary files. 

You can create a macro to specify your SDK location and use that everywhere in the project. In Project Explorer > Options, select Debug > Build. Under the Project Macros field, browse the location of your SDK file. You can also make the location relative to the .emProject file for portability. For example, my SDK is always five folders above my .emProject file:

You also need to specify the location of your libraries.

1. Right-click on your project in the Project Explorer and select Options.
2. Go to Common > Preprocessor > User Include Directories.

Add the paths to your nRF5 SDK installation. For example:

$(SDKDir)/components/ble/ble_advertising
$(SDKDir)/components/ble/ble_db_discovery
$(SDKDir)/components/ble/ble_dtm
$(SDKDir)/components/ble/ble_link_ctx_manager
$(SDKDir)/components/ble/ble_racp
$(SDKDir)/components/ble/ble_services/ble_ancs_c
...

This ensures that the project can locate the necessary headers, drivers, and libraries provided by the SDK.

Modifying sdk_config.h

The sdk_config.h file is the configuration hub for enabling or disabling various modules in your project. The project template includes an sdk_config.h file, but you may need to tweak it based on your needs. For example, if you want to enable UART logging, you would modify:

#define NRF_LOG_ENABLED 1

Each peripheral or library you want to use must be enabled in this file. So, depending on whether you're using Bluetooth, UART, GPIO, or other features, you'll need to adjust the sdk_config.h accordingly.

See the examples folder inside the SDK to view how each project contains different sdk_config.h files.

Customizing main.c

In your Project Folder, you'll find the main.c file, which contains the main logic of your program. The template project includes a basic structure that you can build upon. As a simple test, let's create a basic LED blink program:

#include "nrf.h"
#include "nrf_gpio.h"
#include "boards.h"
#include "nrf_delay.h"

int main(void)
{
    // Initialize LED pin
    nrf_gpio_cfg_output(LED_1);
 
    while (1)
    {
        // Turn LED on
        nrf_gpio_pin_set(LED_1);
        nrf_delay_ms(500);
     
        // Turn LED off
        nrf_gpio_pin_clear(LED_1);
        nrf_delay_ms(500);
    }
}

This code initializes one of the GPIO pins connected to an LED and makes the LED blink with a 500ms delay.

Building and Flashing the Project

Now that the code is ready, let's build and flash it onto the nRF52 device.

1. Click the Build button (or press F7) to compile the project.
2. Connect your PCA10040 development board to your PC via USB.
3. In SES, go to Target > Download <Project Name> to flash the program to the chip.

If everything is working correctly, the LED should start blinking.

Troubleshooting

Here are a few common issues you might encounter:

• Header or library not found: Double-check that the SDK path in User Include Directories points to the correct folders.
• Configuration errors: Ensure that the sdk_config.h file is correctly set up to enable the peripherals or libraries you need.
• Flashing issues: Make sure that the correct development kit is connected and that you’ve selected the correct target device in SES.
• “.text section is larger than specified size”: open the flash_placement.xml file and remove the part that says “size  = 0x4”.

<ProgramSection alignment="4" load="Yes" name=".text" size="0x4" />

Customizing the Template for Future Use

One of the best parts about using a template is that you can customize it for future projects. For example:

• Add your own commonly used libraries or peripherals to the project.
• Pre-configure frequently used settings in sdk_config.h.
• Create multiple .emProject configurations if you work with different devices or development boards.

Final Thoughts

Using the template project from GitHub saves time and effort in setting up a new project in Segger Embedded Studio for nRF52. With a solid understanding of the project structure and how to configure the SDK, you can easily start working on firmware without having to set everything up from scratch. By reusing this template and customizing it for your specific needs, you’ll speed up your development process significantly.

The post Setting up a New Project in Segger Embedded Studio for nRF52 Using a Project Template appeared first on Teach Me Microcontrollers!.

What is Flash Data Storage (FDS)?

Flash Data Storage (FDS) is a library provided by Nordic Semiconductor that simplifies the process of writing, deleting, and updating data in non-volatile flash memory. This is useful for storing configuration settings, device state, and other critical information that must persist across power cycles or resets.

FDS manages flash memory by organizing data into records,  identified by a file ID and a record key. This abstraction layer eliminates the need for the developer to manage low-level flash operations manually.

Key Components in FDS

1. File ID: A unique identifier for a group of records.
2. Record Key: A unique identifier for each record within a file.
3. Record: A single data entity that you want to store.
4. Pages: Flash memory is divided into pages -- the minimum unit that can be erased in flash memory.

Saving Data in Flash

To save data using FDS, you need to define a record that contains the data you want to store, and then call the FDS API to write this record to flash memory.

Example of Saving Data

#include "fds.h"

// Sample data to be stored
uint32_t sample_data = 0x12345678;

// File ID and Record Key
#define FILE_ID 0x1111
#define RECORD_KEY 0x2222

void save_data(void) {
    fds_record_t record;
    fds_record_desc_t record_desc;
    fds_record_chunk_t record_chunk;

    // Set up the record chunk
    record_chunk.p_data = &sample_data;
    record_chunk.length_words = sizeof(sample_data) / sizeof(uint32_t);

    // Define the record
    record.file_id = FILE_ID;
    record.key = RECORD_KEY;
    record.data.p_chunks = &record_chunk;
    record.data.num_chunks = 1;

    // Write the record to flash memory
    ret_code_t err_code = fds_record_write(&record_desc, &record);
    if (err_code == NRF_SUCCESS) {
        // Data was written successfully
    }
}

In this example, a simple uint32_t value is stored in flash memory. The FDS library handles the details of writing the record, and the data is identified by the file ID and record key.

Updating Data in Flash

Updating data in flash is a common requirement when working with configuration settings or other dynamic information. The FDS library allows records to be updated efficiently by writing a new record and marking the old one as obsolete.

Example of Updating Data

void update_data(uint32_t new_data) {
    fds_record_desc_t record_desc;
    fds_find_token_t ftok = {0};

    // Find the record to update
    if (fds_record_find(FILE_ID, RECORD_KEY, &record_desc, &ftok) == NRF_SUCCESS) {
        // Create the new record data
        fds_record_t record;
        fds_record_chunk_t record_chunk;
        record_chunk.p_data = &new_data;
        record_chunk.length_words = sizeof(new_data) / sizeof(uint32_t);
       
        record.file_id = FILE_ID;
        record.key = RECORD_KEY;
        record.data.p_chunks = &record_chunk;
        record.data.num_chunks = 1;

        // Update the record
        ret_code_t err_code = fds_record_update(&record_desc, &record);
        if (err_code == NRF_SUCCESS) {
            // Record updated successfully
        }
    }
}

In this example, the fds_record_update function updates the existing record with new data.

Deleting Data in Flash

To delete data from flash memory, you can use the fds_record_delete function. Deleting a record does not immediately free up space, but marks it as obsolete. Space will be freed during garbage collection.

Example of Deleting Data

void delete_data(void) {
    fds_record_desc_t record_desc;
    fds_find_token_t ftok = {0};

    // Find the record to delete
    if (fds_record_find(FILE_ID, RECORD_KEY, &record_desc, &ftok) == NRF_SUCCESS) {
        // Delete the record
        ret_code_t err_code = fds_record_delete(&record_desc);
        if (err_code == NRF_SUCCESS) {
            // Record marked for deletion
        }
    }
}

Once a record is marked for deletion, it will not be accessible, but the space it occupies in flash memory will not be immediately reclaimed.

Garbage Collection

Flash memory has limited erase cycles, and the smallest unit that can be erased is a page. This means that you cannot immediately reuse the memory occupied by deleted or updated records. The FDS library handles this by performing garbage collection.

Garbage collection reclaims flash memory by erasing pages that contain obsolete records (those marked for deletion or old versions of updated records). This process can be triggered manually using the fds_gc() function or will happen automatically when necessary.

Example of Triggering Garbage Collection

void trigger_garbage_collection(void) {
    ret_code_t err_code = fds_gc();
    if (err_code == NRF_SUCCESS) {
        // Garbage collection was successful
    }
}

Garbage collection will erase entire flash pages, freeing up space for future writes. It’s important to note that if a page contains any active (non-obsolete) records, it cannot be erased until all records are either moved or deleted.

Best Practices for FDS and Flash Memory Management

1. Avoid frequent writes: Flash memory has a limited number of erase/write cycles. Try to minimize the frequency of updates to prolong the life of the flash.
2. Use garbage collection proactively: Trigger garbage collection periodically to ensure that flash space is freed up for future use.
3. Monitor flash usage: Keep an eye on how much flash memory is being used and reclaimed. FDS provides functions like fds_stat to check memory usage.
4. Error handling: Always handle the return codes from FDS functions to ensure that operations like writing and deleting are successful.

Conclusion

The FDS library in the nRF52832 simplifies the use of flash memory by providing functions for saving, deleting, and updating data. It abstracts the complexities of flash memory management, allowing you to focus on the functionality of your application. Understanding how to use FDS efficiently, along with triggering garbage collection, is essential for maintaining the longevity and reliability of your device's flash memory.

The post Using Flash Data Storage (FDS) in the nRF52832 appeared first on Teach Me Microcontrollers!.