Important changes to forums

We’re making some changes to the Mbed forums. From 10th December 2019 all new discussions will take place on our new forum site. You can continue to reply to existing threads for the next two weeks. After that we will archive this forum so you can return to useful posts in the future.

[feature-nrf528xx] Nordic NRF52 series upgrade to SDK 14.2

This forum topic has been closed.

20 Apr 2018

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.

FeatureStatus
Sleep optimizationsNot started
RTC, Low Power Ticker, us Ticker reworkIn development
Serial driver optimizationsDone
PWM using new APIDone
Coexisting SPI and I2C driversDone
Pin map configurationDone
ADC uses new APIDone
Mbed BLE uses new Nordic BLE APIDone
Flash can be erased/written regardless of SoftDevice stateDone
Build application without SoftDeviceDone
TRNG uses new APIDone
Critical sections uses new APIDone
Update SDK to version 14.2Done

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.
02 Mar 2018

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

05 Mar 2018

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!

06 Mar 2018

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

06 Mar 2018

John Robeson wrote:

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.

08 Mar 2018

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!

08 Mar 2018

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?

08 Mar 2018

George Beckstein wrote:

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 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!

08 Mar 2018

Garrett LoVerde wrote:

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?

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.

08 Mar 2018

Marcus Chang wrote:

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.

08 Mar 2018

Marcus Chang wrote:

George Beckstein wrote:

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 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!

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

08 Mar 2018

George Beckstein wrote:

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!

17 Mar 2018

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

20 Mar 2018

John Robeson wrote:

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.

28 Mar 2018

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.

28 Mar 2018

John Robeson wrote:

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.

03 Apr 2018

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?

04 Apr 2018

Ian LoVerde wrote:

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
        }
    }
20 Apr 2018

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

20 Apr 2018

zhang jian wrote:

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.

You need to log in to post a reply