This feature has been merged to master and will be released in Mbed OS 5.9

New thread for discussing upcoming work for NRF52 based targets.

Introduction

The Nordic NRF52832 and NRF52840 currently use the older SDK version 11 and version 13, respectively. This makes it difficult to address issues reported against both MCUs and it prevents users from benefiting from new features and bug fixes in later SDKs and SoftDevices.

Goal

• Update SDK to version 14.2 and SoftDevice to version 5 for the NRF52.
• Update Mbed HAL implementation to take advantage of new SDK.
• Update workflow to use new Mbed tools and configurations.

Feature branch: https://github.com/ARMmbed/mbed-os/tree/feature-nrf528xx

Known limitations

• SPI module is incompatible with the Mbed HAL SPI slave API. SPISlave will be removed from all targets.
• RTC module is incompatible with new Mbed HAL RTC specification. RTC will be removed from all targets.
• EasyDMA can only read from RAM but Mbed HAL API allows users to pass buffers stored in flash.
• TWIS module might be incompatible with Mbed HAL API. Further investigation needed.

Affected targets

• DELTA_DFBM_NQ620
• MTB_UBLOX_NINA_B1
• NRF52_DK
• NRF52840_DK
• RBLAB_BLENANO2
• UBLOX_EVA_NINA
• UBLOX_EVK_NINA_B1
• VBLUNO52

Development Plan

For peripherals not mentioned in the plan below the old implementations will be used.

Building without a SoftDevice

Insert in mbed_app.json (replace S140 with S132 for that SoftDevice):

    "target_overrides": {
        "*": {
            "target.extra_labels_remove": ["SOFTDEVICE_COMMON", "SOFTDEVICE_S140"],
            "target.extra_labels_add": ["SOFTDEVICE_NONE"]
        }
    }

Edits

• 4/20/2018: Feature branch merged to master.
• 3/22/2018: Serial driver PR submitted.
• 3/15/2018: Sleep optimizations planned.
• 3/15/2018: Serial driver optimizations in development.
• 3/15/2018: PWM PR merged.
• 3/15/2018: SPI/I2C PR merged.
• 3/7/2018: PWM PR submitted.
• 3/7/2018: SPI/I2C PR submitted.
• 3/6/2018: Pinmap merged.
• 3/6/2018: ADC merged.
• 3/6/2018: BLE merged.

so at what point does it get merged to mbed-os master? at 100% completion? or simply 100% working?

I'm thinking when the feature branch is no longer lacking functionality found in the master branch. For example, BLE and PWM are not yet merged into the feature branch, so that functionality is missing.

I think we are getting close!

Is the FlashIAP supposed to be exposed yet in the feature branch or is it even supposed to be working yet? I had to import it with `mbed::FlashIAP`. and add `FLASH` to `device_has` in target.json

Yes, but as you noticed, it's not enabled on the NRF52832 yet.

I would like to make as few changes to target.json as possible (to avoid merge conflicts) until we are ready to merge to master. At that point we'll modify all the NRF52 targets to reflect the actual capabilities.

So at this point, since the RTC, Low Power Ticker, and us Ticker rework are in development I shouldn't expect the events library (and EventQueue) to function properly? My application uses BLE and depends on the EventQueue library to offload callbacks to the thread context (as most BLE examples suggest). Just need a sanity check while I continue to test with the new feature branch. Looks good so far!

I'm assuming this won't make mbed OS 5.8?

If not is it possible for it to make it into one of 5.8's patch releases?

I would expect the EventQueue to work with BLE. The feature branch is using the old timer implementations currently found on master, so you should get the same experience when using them.

If you do run into problems please let us know! Thank you!

We have not discussed internally what version we are aiming for yet. The feature branch is rebased with master quite regularly so you shouldn't be missing out on new features for too long.

Thanks!

Just won't feel comfortable using for production until this gets into an official OS release.

In that case, I haven't been able to connect to the device over BLE successfully while using the feature branch. The device is visibly advertising but when I try to connect the connection just times out.

EDIT: Could this issue I'm seeing be related to the recent PR #6308?

https://github.com/ARMmbed/mbed-os/pull/6308

From your comment there it looks like it is! Thank you for testing!

Can you describe a bit about the serial and sleep optimizations?

The serial driver is being rewritten to use UARTE/EasyDMA. This will enable the second UARTE on NRF52840 and give much better receive performance.

The sleep current when building with a SoftDevice is higher than what we would expect so something is not quite right. It also looks like we are doing something different than the SDK examples.

is porting to SDK 15 going to be a separate effort? I see that they offer compatible interfaces for SDK 14. Of course it might be good to just go all in on the nrfx versions.

It's going to be a separate effort. I think using it through the legacy API would make the actual version too opaque for our users.

Hi Marcus,

I'm working with the nrf52840 using mbed. I wanted to test some of the functionality of the feature branch, so I went ahead and updated my mbed-os to it. I'm really digging some of what I've seen, specifically the mentioning of the softdevice in the build output, as well as the reworks to I2C and SPI that I saw.

Unfortunately, there's one issue I'm having, and it seems to be that this branch is "overriding my override" of hardware flow control. I'm developing on a custom pcb, where we have no onboard debugger, and need hardware flow control disabled. In the past, eliminating hardware flow control was as simple as overriding it to 0 in my customtargets.json file, but it seems that no longer works. When I build the firmware, I get the following message over and over while building.

[Warning] mbed_config.h@42,0: "MBED_CONF_NORDIC_UART_HWFC" redefined

When I check the mbedconfig file, the value is set as a 1 after building, even though I should be overriding it in my customtargets.json.

Is there a new procedure for overriding macros on a custom board with this branch?

Hi Ian,

Glad to hear it is (mostly) working for you!

One of the last things I have to do before merging with master is cleaning up the targets in targets.json.

At the moment, you'll have to configure the value twice to get rid of the warning and make it stick:

    "target_overrides": {
        "*": {
            "target.uart_hwfc": 0,
            "nordic.uart-hwfc": 0
        }
    }

Hi Is there a plan to support the NRF52832 DFU/OTA feature?

Hi Zhang Jian,

The first firmware update feature we'll be supporting is Mbed Cloud.

I have not looked at what supporting the Nordic firmware update service requires so I don't know if that is something we can just do along the way or if it will have to be a separate task. If it is the latter, it is not something we have planned yet.

I'm moving the discussion over here now that this feature branch has been merged to master.