Enabling Bluetooth-to-Cloud on the Renesas DA14695

This week we enabled internet uplink over Bluetooth for the Renesas DA14695. This approach uses Golioth’s Bluetooth-to-Cloud service which leverages a standard gateway device to read data from any Bluetooth hardware capable of using the Generic Attribute Profile (GATT), which is basically all Bluetooth devices.

With this setup, the gateway periodically scans for devices with a predetermined characteristic. When these devices connect to the gateway, they use Golioth’s Pouch protocol to package sensor (or any other data) and send it to the cloud. In addition to today’s Renesas device, we’ve already demonstrated this functionality with Nordic, STM, and NXP devices.

Using the DA14695 with Zephyr

While the Bluetooth-to-Cloud service doesn’t require that leaf nodes run Zephyr, we have built the first example applications on Zephyr. The first thing we need to do is get ready to build for the Renesas DA14695.

My device shipped with a jumper installed on J2 between pins 2-3. This runs the board in 5V mode, but I found that Zephyr applications like basic/blinky didn’t want to run (as if the clock was not running). This was resolved by moving the jumper to J3 between pins 1-2 which connects the chip to the 3.3V rail.

While the board includes Bluetooth support in Zephyr, it requires that you fetch the binary blob and turn on the Bluetooth peripheral in the devicetree. I also found that Bluetooth functionality required Zephyr 4.1.0 or later. First, let’s use west to grab the binary blob.

west blobs fetch hal_renesas

With the binary blobs in place, add an overlay file for this board to your project. Note that we are both turning on the Bluetooth peripheral, and add it as a “chosen” in the overlay file.

/ {
    chosen {
    zephyr,bt-hci = &bt_hci_da1469x;
  };
};

&bt_hci_da1469x {
  status = "okay";
};

Finally, to flash the device we need to install the eZFlashCLI which can be installed using pip.

pip install ezFlashCLI

If you want to test your Bluetooth functionality at this point, I recommending trying out Zephyr’s observer example. It simply scans for Bluetooth devices and reports their mac address in the serial console.

Building Golioth’s Bluetooth-to-Cloud Example

As shown in the video, there are a couple of tweaks we need to make to get the example code to build for this board:

1. Use Zephyr 4.1.0
2. Add the Renesas HAL libraries

Make sure you have already completed steps 1 and 2 for setting up a gateway in the Getting Started section of the BLE Private Access application. When you get to Step 3, follow the instructions to initialize and update the project. But pause at this point to edit the pouch/west.yml file as follows:

# Copyright (c) 2025 Golioth, Inc.
# SPDX-License-Identifier: Apache-2.0

manifest:
  version: 0.8

  projects:
    - name: zephyr
      revision: v4.1.0
      url: https://github.com/zephyrproject-rtos/zephyr
      west-commands: scripts/west-commands.yml
      import:
        path-prefix: deps
        name-allowlist:
          - zephyr
          - cmsis
          - hal_nordic
          - hal_renesas
          - mbedtls
          - mcuboot
          - segger
          - tfm-mcuboot
          - tinycrypt
          - trusted-firmware-m
          - zcbor

The lines highlighted above show the changes to this file. The Zephyr version was updated to 4.1.0 and the hal_renesas library was added to the name-allowlist.

Let’s update for these changes to take effect and also ensure we fetch the binary blob and install the flashing tool as discussed in the previous section.

west update
west blobs fetch hal_renesas
pip install ezFlashCLI

Next, copy the overlay file shown in the previous section to pouch/examples/ble_gatt/boards/da14695_dk_usb.overlay. We’re now ready to build and flash the application.

west build -p -b da14695_dk_usb pouch/examples/ble_gatt -- -DCONFIG_EXAMPLE_DEVICE_ID="REPLACEME"
west flash

The device will reboot and begin running. It’s worth mentioning that the build command above includes a REPLACEME placeholder that needs to be replaced with the Golioth DeviceID for this hardware. Without this, the cloud will not recognize this as a valid device when receiving data via the gateway.

Sending Actual Sensor Code

In the video we demonstrate going a step further by connecting a BME280 temperature, pressure, and humidity sensor up to the Renesas DA14695 so that we can send actual sensor data. It is actually quite simple to add data to the upload.

Let’s look at the pouch_event_handler() callback. You can see in this function we are packaging up some JSON code to send a (simulated) temperature value. This payload may be replaced with any valid JSON, just be sure to change both the JSON string and the length in the write API call.

static void pouch_event_handler(enum pouch_event event, void *ctx)
{
    if (POUCH_EVENT_SESSION_START == event)
    {
        pouch_uplink_entry_write(".s/sensor",
                                 POUCH_CONTENT_TYPE_JSON,
                                 "{"temp":22}",
                                 sizeof("{"temp":22}") - 1,
                                 K_FOREVER);
        pouch_uplink_close(K_FOREVER);
    }

    if (POUCH_EVENT_SESSION_END == event)
    {
        service_data[ARRAY_SIZE(service_data) - 1] = 0x00;
        k_work_schedule(&sync_request_work, K_SECONDS(SYNC_PERIOD_S));
    }
}

Your Bluetooth Devices On the Cloud, Right Now.

Golioth has already solved the complexity of transferring data from your Bluetooth fleet to the cloud. By installing a gateway device, you can automatically scan and upload that data at a cadence of your choosing. Take it for a spin today and let us know how it goes!