BLE: update Cordio link layer to 19.2 #10272

paul-szczepanek-arm · 2019-03-29T10:56:23Z

Description

This depends on an updated Nordic SDK to version 15:
#9999

This updates the cordio link layer to 19.2 the release notes for which are here:
https://github.com/ARMmbed/CordioBLE-Controller-Stable/blob/master/controller/cordio_link_readme.md

Pull request type

[ ] Fix
[ ] Refactor
[ ] Target update
[x] Functionality change
[ ] Docs update
[ ] Test update
[ ] Breaking change

Reviewers

@pan-

Release Notes

Updates cordio link layer, doesn't change user facing API.

…feature defines

- top level files ported from TARGET_NORDIC/TARGET_NRF5x/ Also addressed: - fixed linking issue for gcc - added support for nRF52-DK builds, but reverted to using nRF52840 sdk_config.h (must be updated) - introduced "RTC" to targets.json (might need to be removed eventually)

Also addressed: - removed dependency on legacy config (excluded apply_old_config.h) - removed legacy pwm and saadc headers - Arm Compiler 5 linking issue (a band-aid for now... needs to be properly addressed for peripheral sharing) - added missing header in SoftDevice file

- Missed some NRFX defines that needed to changed - Set PWM base clock to 125kHz (needs to be reverted back to 1 MHz) - Updated sdk_config.h for nRF52_DK builds - Brought in updates from PR7779 (fix for nRF52 PWM issues)

Enable UART interfaces to enable serial debug prints.

Using the nrfx_get_irq_number only works with the handle. Since we know the IRQ numbers for UART0, RTC2 and EGU0, use them directly.

- Use new NRFX header file - Fix nRF52832 linker script/ld files (hardcoded addresses for now) - Temporarily remove DEVICE_TRNG for nRF52832 (which broke the build) - Improve serial_putc() fix so we don't rely on "extra" functions

- Added legacy nrf_drv_rng.c as there is no merit in fully adopting nrfx_rng.c - Added nrf_queue library component - Removed apply_old_config.h (unused for some time now) - Updated sdk_config.h for queue and RNG support for nRF52832 - Brought back RNG into targets.json for nRF52832 Note: nRF52840 still uses CryptoCell 310 for TRNG

When the SoftDevice (SD) is enabled we need to set the app_offset to 0x26000 to make room for the SoftDevice. If we let the build tools self-manage this, MBED_APP_START is coming out at 0x25000 which is not correct for the Nordic 15.0 SDK. The app_offset value is translated to MBED_APP_START by the build infrastructure. We were hard coding MBED_APP_START in the scatter and ld files as a temporary measure while testing. This now sets it properly if the SD is being brought in.

Ensure that vector table gets initialized properly. The table that we initialize in startup_nrf52840.S gets wiped out as the section is declared as noinit. Fix this by implementing the weak function mbed_sdk_init that inits the vector table.

* Remove NRF_SDH_CLOCK parameters from mbed_lib.json * Bring in QSPI for nRF52840 * Migrate legacy QSPI driver to SDK v15 (nrfx_qspi.h) * Remove outdated comment in i2c_api.c

The 15.0 SDK doesn't support the nRF51 so it must continue to use the legacy NRF drivers. Thus the original common_rtc.c, gpio_api.c and us_ticker.c are restored and placed under TARGET_NRF5x/TARGET_NRF51. Likewise the modified common_rtc.c, gpio_api.c and us_ticker.c are moved to TARGET_NRF5x/TARGET_NRF52 so they are excluded from nRF51 builds.

nRF5x PinNames.h never utilized PORT_SHIFT so removed for clarity after user commented on it.

- Add MBR, NONE and OTA SoftDevice build options for S132 and S140 - Add S112 SoftDevice (single build option) - Some folder restructuring in TARGET_SOFTDEVICE_COMMON was required

This reverts commit 3d2fa53. This was a breaking change for the "MBR" and "NONE" builds. After testing it was also determined that copying the vector table a second time wasn't required for the "FULL" build.

* Update TARGET_NRF5x/README.md to improve "Changing SoftDevice" section and added section on NRF52840 CryptoCell310 Support * Update the file list in TARGET_SDK_15_0/TARGET_SOFTDEVICE_COMMON/README.md * Add missing CR-LF to Nordic-provided SDK file * Rename a header file in the TARGET_SOFTDEVICE_S112 tree

- Brought in new nrfx APIs - Brought in PPI additions - Removed dead code for RTC

pan- · 2019-04-01T07:50:29Z

@NirSonnenschein The astyle issues found are not part of this PR; it is in the esp driver.

pan-

Thanks for the change @paul-szczepanek-arm . I think some point can be improved and there's a serious breakage of existing targets with the non release of the data buffer. Other than that I feel like the driver itself would benefit from a good cleanup.

I'd like to see configuration flags for roles (1 and 2).

features/FEATURE_BLE/targets/TARGET_CORDIO_LL/mbed_lib.json

...s/FEATURE_BLE/targets/TARGET_NORDIC/TARGET_NORDIC_CORDIO/TARGET_NRF5x/NRFCordioHCIDriver.cpp

features/FEATURE_BLE/targets/TARGET_NORDIC/TARGET_NORDIC_CORDIO/TARGET_NRF5x/mbed_lib.json

..._BLE/targets/TARGET_NORDIC/TARGET_NORDIC_CORDIO/TARGET_NRF5x/NRFCordioHCITransportDriver.cpp

features/FEATURE_BLE/targets/TARGET_CORDIO_LL/stack_adaptation/fake_lhci_drv.h

pan- · 2019-04-01T08:12:13Z

features/FEATURE_BLE/targets/TARGET_CORDIO_LL/stack/controller/sources/common/chci/chci_tr.c

@@ -401,6 +401,8 @@ static void chciTrWrite(uint8_t prot, uint8_t type, uint16_t len, uint8_t *pData
  PalSysSetBusy();
 #else
  FakeChciTrWrite(prot, type, len, pData);
+  chciTrCb.wrBufComp = TRUE;


what's the impact of servicing immediately ? Why are we not checking the return of FakeChciTrWrite ?

We service immediately because there is nothing else to run ChciTrService() and what is the point in waiting? We are the only ones producing writes.

The is no point checking the return since there is no way to handle error. The packet is just lost. There are no error codes in cordio - it assumes every function always works.

Thanks for the clarification about servicing immediately the request. Could you check with the Cordio team if this change can be upstreamed ?

The is no point checking the return since there is no way to handle error.

I think there is a point, we should release the memory but I might be wrong.

Let me correct myself:
The data is in an rx buffer on the receiving end. The data is assumed to be send/copied when called and the WSF message will be freed at the end (failed packets are in effect dropped).

I'll make a jira ticket to upstream the service call

pan- · 2019-04-01T08:14:57Z

...EATURE_BLE/targets/TARGET_NORDIC/TARGET_NORDIC_CORDIO/TARGET_NRF5x/stack/sources/pal_timer.c

@@ -25,9 +25,9 @@
 * Notes:
 *
 *    This is timer driver dedicated to scheduler, an interrupt will be triggered to do scheduler task
- *    when timer hits compare value. Timer1 is used here.
+ *    when timer hits compare value. TIMER2 is used here.


can we ping the cordio team about this ? It would be nice if the timer used was selectable at compile time. Also, IIRC correctly we cannot use TIMER0 because it is already used by the stack. is that correct ? We should notice the HAL team that TIMER2 is reserved; this is new.

pan- · 2019-04-01T08:21:31Z

...s/FEATURE_BLE/targets/TARGET_NORDIC/TARGET_NORDIC_CORDIO/TARGET_NRF5x/NRFCordioHCIDriver.cpp

-    #endif
-    /*stableModIdxTxSup*/         TRUE,
-    /*stableModIdxRxSup*/          TRUE
+/* Device */


Would it be possible to add relevant flags to the configuration:

maxAdvSets

maxAdvReports

maxExtAdvDataLen

defExtAdvDataFrag

maxScanReqRcvdEvt

maxExtScanDataLen

maxConn

phy2mSup

phyCodedSup

There might be more. Also, we may want to allow version 4 of bluetooth (btVer) for applications that don't use BT 5 features.

added config

features/FEATURE_BLE/targets/TARGET_CORDIO/stack_adaptation/hci_tr.c

0xc0170 · 2019-04-11T12:06:28Z

Second round of review opened 👍

0xc0170 · 2019-04-11T12:08:33Z

Dependency #9999 was closed - there was another PR also closed - what is the status there?

…with normal function

donatieng

Thanks @paul-szczepanek-arm, looks great.
One thing, we have a bit of a conflicting directory structure:

a config file (specific to the NRF52840_DK) here: TARGET_CORDIO_LL/TARGET_NRF52840_DK
other Nordic implementation code here: TARGET_NORDIC/TARGET_NORDIC_CORDIO/TARGET_NRF5x

Could we:

have everything under a single directory
have a default config file with conservative defaults (as you have)
one for the NRF52832 (not DK, the MCU)
one for the NRF52840 (not DK, the MCU)

adbridge · 2019-05-01T12:05:34Z

@paul-szczepanek-arm Looks like this now needs a rebase ?

yogeshk19 · 2019-05-05T03:12:06Z

@paul-szczepanek-arm - When is this going to be made available as a stable release? Is this slated for mbed-os-5.12.3 release?

paul-szczepanek-arm · 2019-05-08T08:56:09Z

Impossible rebase, new PR: #10542

paul-szczepanek-arm · 2019-05-08T08:57:46Z

@yogeshk19 I don't know, this still needs a couple days work to address Don's requested changes, @adbridge?

adbridge · 2019-05-08T10:14:28Z

@yogeshk19 as 5.12.3 will be released today this will not make it into that. It should now target 5.12.4

paul-szczepanek-arm · 2019-05-08T10:57:03Z

@donatieng I can move the config for DK but I don't have anything to put in the configs for NRF52832 and NRF52840. Only the DK requires extra config.

yogeshk19 · 2019-05-19T22:46:09Z

@adbridge I was wondering if this is on track for being rolled into 5.12.4? I am hoping this would help resolve #10321, as this issue is preventing us from testing a lot of our features.

Thanks,
Yogesh

TacoGrandeTX and others added 30 commits March 4, 2019 14:22

Baseline legacy build using 14.2 drivers.

890551a

Mods for baseline 15.0 support

a21e4e4

Bringing in Softdevice but excluding BLE feature and improvements in …

ed4799c

…feature defines

Updates to PWM for IOTDEV-1573

3b7432b

- Missed some NRFX defines that needed to changed - Set PWM base clock to 125kHz (needs to be reverted back to 1 MHz) - Updated sdk_config.h for nRF52_DK builds - Brought in updates from PR7779 (fix for nRF52 PWM issues)

serial_api: Fixes to compile with SDK15.0

8633087

serial_api: add changes to port from Softdevice 14.2 to 15.0

5643d71

Nordic sdk_config: Configure UART instances

cce4399

Enable UART interfaces to enable serial debug prints.

serial_api: Fix the interrupt registration for Nordic Serial Device

18d307d

Using the nrfx_get_irq_number only works with the handle. Since we know the IRQ numbers for UART0, RTC2 and EGU0, use them directly.

Updates for IOTDEV-1575 and nRF52_DK builds

5ebe9c9

- Use new NRFX header file - Fix nRF52832 linker script/ld files (hardcoded addresses for now) - Temporarily remove DEVICE_TRNG for nRF52832 (which broke the build) - Improve serial_putc() fix so we don't rely on "extra" functions

NRF52: spi_api: port from Softdevice 14.2 to 15.0

4a7027b

NRF52: i2c_api: port from Softdevice 14.2 to 15.0

6752ae7

NRF: enable PRS (Peripheral Resource Sharing) for NRF52832 and NRF52840

44ac5db

NRF52832: enable UART

8313a2d

nRF52832 needs NRFX_RNG_ENABLED to use the legacy driver

d613667

NRF52: Fix vector table

1987142

Ensure that vector table gets initialized properly. The table that we initialize in startup_nrf52840.S gets wiped out as the section is declared as noinit. Fix this by implementing the weak function mbed_sdk_init that inits the vector table.

Updates after rebase with Mbed master (circa OS v5.10.1)

2cffbd2

* Remove NRF_SDH_CLOCK parameters from mbed_lib.json * Bring in QSPI for nRF52840 * Migrate legacy QSPI driver to SDK v15 (nrfx_qspi.h) * Remove outdated comment in i2c_api.c

Remove dead #define PORT_SHIFT

31be9c3

nRF5x PinNames.h never utilized PORT_SHIFT so removed for clarity after user commented on it.

Add missing SoftDevice build support (MBR, NONE, OTA)

30308eb

- Add MBR, NONE and OTA SoftDevice build options for S132 and S140 - Add S112 SoftDevice (single build option) - Some folder restructuring in TARGET_SOFTDEVICE_COMMON was required

Revert "NRF52: Fix vector table"

2f730cf

This reverts commit 3d2fa53. This was a breaking change for the "MBR" and "NONE" builds. After testing it was also determined that copying the vector table a second time wasn't required for the "FULL" build.

Enabling NRFX_PPI_ENABLED for serial_api updates

b017717

Changes required for rebase:

cf680ba

- Brought in new nrfx APIs - Brought in PPI additions - Removed dead code for RTC

Set the PWM clock prescaler back to default (1MHz clock)

4638d8c

NRF52: serial: fix build warnings

75847c4

NRF52: Cleanup unused code

439ec68

pan- requested changes Apr 1, 2019

View reviewed changes

0xc0170 added needs: work and removed needs: review labels Apr 1, 2019

paul-szczepanek-arm added 3 commits April 1, 2019 15:49

review comments addressed

44ae526

zero copy HCI as a config option

900443c

configs in mbed json

19fce04

marcemmers mentioned this pull request Apr 5, 2019

nRF52840 Cordio stack has some unwanted GPIO control #10321

Closed

removed stray comma

d394961

0xc0170 added needs: review and removed needs: work labels Apr 9, 2019

remove usage of gpio and leds from nordic cordio LL as it interferes …

d04540b

…with normal function

0xc0170 added needs: work and removed needs: review labels Apr 18, 2019

0xc0170 removed the request for review from screamerbg April 18, 2019 12:26

license updated

f1f6c79

donatieng mentioned this pull request Apr 25, 2019

Update the Nordic nRF52 SDK 15 feature branch #10441

Merged

donatieng suggested changes Apr 25, 2019

View reviewed changes

adbridge force-pushed the feature-nrf52-sdk15 branch from dbd3879 to f28b82b Compare April 26, 2019 14:21

paul-szczepanek-arm closed this May 8, 2019

paul-szczepanek-arm mentioned this pull request May 8, 2019

BLE: update Cordio link layer to 19.2 #10542

Merged

BLE: update Cordio link layer to 19.2 #10272

BLE: update Cordio link layer to 19.2 #10272

Uh oh!

Conversation

paul-szczepanek-arm commented Mar 29, 2019

Description

Pull request type

Reviewers

Release Notes

Uh oh!

pan- commented Apr 1, 2019

Uh oh!

pan- left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

pan- Apr 1, 2019

Choose a reason for hiding this comment

Uh oh!

paul-szczepanek-arm Apr 1, 2019

Choose a reason for hiding this comment

Uh oh!

pan- Apr 1, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

paul-szczepanek-arm Apr 1, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

paul-szczepanek-arm Apr 1, 2019

Choose a reason for hiding this comment

Uh oh!

pan- Apr 1, 2019

Choose a reason for hiding this comment

Uh oh!

pan- Apr 1, 2019

Choose a reason for hiding this comment

Uh oh!

paul-szczepanek-arm Apr 2, 2019

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

0xc0170 commented Apr 11, 2019

Uh oh!

0xc0170 commented Apr 11, 2019

Uh oh!

donatieng left a comment

Choose a reason for hiding this comment

Uh oh!

adbridge commented May 1, 2019

Uh oh!

yogeshk19 commented May 5, 2019

Uh oh!

paul-szczepanek-arm commented May 8, 2019

Uh oh!

paul-szczepanek-arm commented May 8, 2019

Uh oh!

adbridge commented May 8, 2019

Uh oh!

paul-szczepanek-arm commented May 8, 2019

Uh oh!

yogeshk19 commented May 19, 2019

Uh oh!

Uh oh!

pan- Apr 1, 2019 •

edited

Loading

paul-szczepanek-arm Apr 1, 2019 •

edited

Loading