Add TARGET_STMBLUE #9491

ntoni92 · 2019-01-24T16:04:50Z

Description

This pull request contains files necessary to the execution of Mbed-OS 5.11 over STM BlueNRG2 SoC. This porting includes USTICKER, GPIO, UART and BLE Cordio stack.
Mbed OS 5.11 works on BlueNRG2 only without RTOS (SRAM is not enough). The porting has been tested with ARM BLE HRM example, modified to use a shared queue and public address. It has been compiled with GCC_ARM with -Og option, otherwise code size exceeds flash size. In this configuration the use of standard printf is not allowed.

Pull request type

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

Reviewers

@donatieng
@pan-
@avilei
@apalmieriGH

…, it requires mbed shared queue. Signed-off-by: ntoni92 <antonio.orlandoo@hotmail.it>

ciarmcom · 2019-01-24T18:00:38Z

@ntoni92, thank you for your changes.
@donatieng @pan- @ARMmbed/mbed-os-maintainers @ARMmbed/mbed-os-tools please review.

bridadan · 2019-01-24T23:20:05Z

tools/profiles/custom_bnrg2.json

+        "ld": ["-Wl,--gc-sections", "-Wl,--wrap,main", "-Wl,--wrap,_malloc_r",
+               "-Wl,--wrap,_free_r", "-Wl,--wrap,_realloc_r", "-Wl,--wrap,_memalign_r",
+               "-Wl,--wrap,_calloc_r", "-Wl,--wrap,exit", "-Wl,--wrap,atexit",
+               "-Wl,-n"]


I always look for ways to avoid adding another profile when possible. Since this is for debugging, would it be overly intrusive to change the -O0 to -Og in the main debug.json? @deepikabhavnani or @c1728p9 may be able to educate me a bit more.

That would be a dream for many use cases (even if the real deal would be custom settings per file/folder!).
I think @kjbracey-arm must know when it is wrong.

I dont understand why this is being added. We provide 3 default profiles. If any of these 3 is not sufficient, issue should be raised, not adding a new one.

pan- · 2019-01-25T11:15:42Z

targets/TARGET_STMBLUE/DTM_libraries/BlueNrgHCIDriver.cpp

+    	DTM_StackInit();
+    	////stacktick queueing, the dispatch loop will be initialized after the initialization
+    	////inside main
+    	_eventQueue = mbed_event_queue();


It feels inefficient to pass the default event queue here: If the application doesn't use it like it is the case in all ble examples then you pay for two event queues.
I need some time to think of a way of hooking an undefined recurring event in the Cordio port.

Hi @pan-, rather than in the Cordio it could be better to hook the stack tick inside the dispatch loop of the event queue. I've started studying sleep and deep sleep capabilities of BlueNRG2, discovering that StackTick is also mandatory to get permission from controller to enter sleep mode.

From my understanding BTLE_StackTick has to be called at every system-wakeup to keep up the 500ppm accuracy. There is an integration point in the sleep function.

Going back to attaching it to the default event queue; it is wrong: mbed_event_queue creates a separate thread to that will dispatch events. This is not good resources wise; users must be able to execute their application on a single thread.

BLE API itself doesn't assume the existence of an event queue of any sort: The application must register a callback that will signal the application that BLE must process. That signal can be tied to any type of event queue, a loop, ... It is up to the application.

I'd like to extend the HCI driver as such:

Expose a function that can be called by the driver to signal their is work to do.

Expose a virtual function that process driver events and that can be overridden by the driver. It would be called whenever the bluetooth subsystem is processed.

// In CordioHCIDriver declaration // invoke the private virtual function do_process_events(); void process_events(); // to call by the driver whenever there is an event. void signal_events_to_process(); private: // by default event processing does nothing virtual void do_process_events() {}

In the ST driver this can be use as follow:

virtual void initialise() { /* Stack Initialization */ DTM_StackInit(); // setup local Ticker for BTLE_StackTick _ticker.attach(mbed::callback(this, signal_events_to_process), 10000 /*us*/); } virtual void do_process_events() { BTLE_StackTick(); }

@donatieng @paul-szczepanek-arm What do you think ?

Sounds reasonable, don't see why that precludes the option of automatic handling done on a passed in queue.

@pan- BTLE_StackTick performs the whole link layer and radio processing, it shall be called repeatedly to ensure the correct BLE controller operation (among the others to keep the 500 ppm accuracy, but it is not sufficient to call this signal only once after wakeup). Your proposed approach could be, in my opinion, ideal to ensure the correct processing and at the same time hide this mechanism to the application, with the actual BlueNRG2 controller library implementation.

Concerning the event queue, I had to modify the HRM example to use also there the pointed by the return pointer of mbed_event_queue, by changing with

static EventQueue* event_queue = mbed_event_queue();

tested) sleep. Deepsleep is tricky.

deepikabhavnani · 2019-01-31T17:35:05Z

@ntoni92 - New target is adding libraries targets/TARGET_STMBLUE/cryptolib/libcrypto.a and targets/TARGET_STMBLUE/Bluetooth_LE/library/libbluenrg1_stack.a, please share more details on the need and compatibility with ARMC6 and IAR8.

CC @SenRamakri @0xc0170

cmonr · 2019-01-31T21:13:58Z

@ntoni92 Please take a look at the Travis CI failures.

0xc0170 · 2019-02-04T16:38:42Z

targets/targets.json

+    "STEVAL_IDB008V2": {
+        "inherits": ["BLUENRG2"],
+        "extra_labels_add": ["BLUENRG2"],
+        "release_versions": ["5"],


There's mention about size limitation (withour RTOS ), but adding here version 5? Can you elaborate please

@cmonr thank you, it seems that I've violated something about the hierarchy in the target.json file. I'll fix and update on my next commit.

@0xc0170 about the size limitation, it is not feasible to use the Mbed OS 5 RTOS feature, but from what I've understood, since version 5.6 event queue feature (and thus code examples based on it) is available in non-RTOS solutions too.

Together with @avilei and @donatieng decided to develop the non-RTOS solution on Mbed 5.

0xc0170 · 2019-02-04T16:39:50Z

...GET_STMBLUE/TARGET_BLUENRG2/TARGET_STEVAL_IDB008V2/device/TOOLCHAIN_GCC_ARM/BlueNRG2_old.txt

@@ -0,0 +1,336 @@
+ /*******************************************************************************


.txt file? Is this used anywhere? there are few .txt files (linker scripts)

@0xc0170 I apologize, it's a commit error. I was using it while refactoring the correct linker script file. I'll eliminate on the next commit.

0xc0170 · 2019-02-04T16:40:25Z

targets/TARGET_STMBLUE/Bluetooth_LE/src/stack_dle_api_stubs.c

@@ -0,0 +1,34 @@
+#include "stack_user_cfg.h"


missing license header file, please add (including SPDX identifier)

0xc0170 · 2019-02-04T16:40:55Z

targets/TARGET_STMBLUE/Bluetooth_LE/src/stack_dle_api_stubs.c

+
+#ifdef CONTROLLER_DATA_LENGTH_EXTENSION_ENABLED
+#if (CONTROLLER_DATA_LENGTH_EXTENSION_ENABLED == 0)
+


Comment for library/libbluenrg1_stack.a - needs to include readme and license (PBL), please add

@0xc0170 Concerning library/libbluenrg1_stack.a, it implements what is declared and documented in inc/*. These are the official library and official documentation from Stmicroelectronics BlueNRG DK version 3.0.0.
About licensing, I should ask my tutor @avilei since I don't know anything about this.

For license, see https://os.mbed.com/docs/mbed-os/latest/contributing/license.html

…d IAR toolchains (linker scripts not ready) - start sleep support.

… code size by using GCC_ARM with -O0

…ayer

…LA0068, SLA0044)

ntoni92 · 2019-03-11T15:14:02Z

Note, #9571 - might have implications for new targets. Please review (there's design document, and targets updated, if any questions, let us know). In any case, please reply to this comment if this change is already done or when completed.

Hi @0xc0170 and @deepikabhavnani,
I've added license information and updated to the suggested memory model.
In addition, I've added support to ARMc6 toolchain. It compiles successfully, but I'm facing some issues with the project exporter and mbed CLI:

mbed compile from CLI does not link the static library libbluenrg1_stack.a and there is a fail (undefined symbols);
mbed export on uvision6 works, but only after a manually static library insertion (it should be done automatically in my opinion) and remove and re-add BlueNRG-2 CMSIS pack, otherwise there are some errors.

Please review.

Many thanks.

0xc0170 · 2019-03-11T15:56:55Z

@0xc0170 With respect to the static library (libbluenrg1_stack.a), is it feasible to publish it with its original license (SLA0068 from STMicroelectronics), instead of PBL?

PBL as licensing guide suggests. SLA0068 is not permissive license to my understanding.

Regarding an example from Nordic license: what was done was done, we can't change that at the moment. Our license guide is the one to be followed.

0xc0170 · 2019-03-11T15:58:07Z

mbed compile from CLI does not link the static library libbluenrg1_stack.a and there is a fail (undefined symbols);

.ar for armcc

adbridge · 2019-03-27T14:56:36Z

@ntoni92 is this ready for re-review ?

cmonr · 2019-03-27T18:49:44Z

@adbridge I think we're waiting on a resolution to the license.

ntoni92 · 2019-03-28T13:18:13Z

Hi @adbridge @cmonr, exactly! My supervisor is still waiting on a resolution from ST legal office about the PBL-SLA compatibility issue. Concerning the porting, I've completed the SPI driver, I'll merge soon. BTLE_StackTick (and correlated LL synchronization) is still pending (a callback registration is required at user level in the current BLE examples). In any case, I'm leaving the project from next week, for any further detail about licensing please refer to my supervisor @avilei.

pan- · 2019-03-28T15:29:31Z

@paul-szczepanek-arm We should run test on these.

adbridge · 2019-04-26T12:15:41Z

If there are no further updates on this in the next few days I am proposing to close this until such time as updates are available.

adbridge · 2019-05-01T11:46:04Z

@ntoni92 please re-open this PR once there are updates available.

ntoni92 added 3 commits January 24, 2019 12:40

Added TARGET_STMBLUE and BlueNRG2

e918624

First working version of BlueNRG2-Cordio tested with HRM app. No RTOS…

516ac21

…, it requires mbed shared queue. Signed-off-by: ntoni92 <antonio.orlandoo@hotmail.it>

Added target BlueNRG2 to targets.json

c77d6cc

ciarmcom requested review from donatieng, pan- and a team January 24, 2019 18:00

ciarmcom added the needs: review label Jan 24, 2019

bridadan reviewed Jan 24, 2019

View reviewed changes

pan- reviewed Jan 25, 2019

View reviewed changes

Minor modification in BSS section initialization

64eddb6

0xc0170 added the scope: new-target label Jan 28, 2019

ntoni92 added 4 commits January 28, 2019 15:00

Fixed Static Random Address generation and initialization

b24863d

Simplified Cordio RESET FSM (less number of states).

e40b86e

Removed unused libraries. Imported sleep_api. Implemented (not yet

a51dc3f

tested) sleep. Deepsleep is tricky.

Errata corrige of previous commit.

ab3968e

cmonr added needs: work and removed needs: review labels Jan 30, 2019

0xc0170 reviewed Feb 4, 2019

View reviewed changes

ntoni92 added 5 commits February 5, 2019 14:45

Fixed device_name in targets.json - removed informations about ARM an…

aeae168

…d IAR toolchains (linker scripts not ready) - start sleep support.

Removed custom profile, but debug mode is not available due to a huge…

31838c1

… code size by using GCC_ARM with -O0

DTM name refactoring

66c75c9

CLI correctly reports BlueNRG2 stack .text occupation.

3f40e5c

Added BTLE_StackTick wrapper to avoid mbed_event_queue in transport l…

0887553

…ayer

ntoni92 added 8 commits March 8, 2019 10:27

Fixed random address generation - defined serial library symbols

441b3ca

Added missing symbols in pinmap. (issued in ARMc6 compiler)

6fc549c

ARMc6 memory aligned but not tested

75ae503

Starting adding SPI support

8207df8

Starting adding SPI support (adding in targets.json)

0bd8e3e

Added licence headers (Apache 2.0 & SLA0068) - added license files (S…

0ac7b7a

…LA0068, SLA0044)

Updated License information.

1c9f37e

SPI not ready, removed definition in targets.json.

5ba5b42

updated CMSIS device_name

93794f6

ntoni92 added 10 commits March 13, 2019 11:13

CR in liberty v2 license

0e20e11

compiler __weak redefined for ARMc6

229a1ef

Added IAR 8.32 support

8c53b88

updated iar8 linker script

a716762

updated SLA0044

78e329a

removed cryptolib (controller basic configuration)

00c8114

Starting SPI support

16db902

Working SPI master. Slave implemented but not tested.

e9fad95

Starting I2C support

95d9f00

I2C to be implemented.

ba01bea

merge spi develop

64ff41f

adbridge closed this May 1, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add TARGET_STMBLUE #9491

Add TARGET_STMBLUE #9491

ntoni92 commented Jan 24, 2019

ciarmcom commented Jan 24, 2019

bridadan Jan 24, 2019

pan- Jan 25, 2019

0xc0170 Feb 4, 2019

pan- Jan 25, 2019

ntoni92 Jan 31, 2019

pan- Jan 31, 2019

paul-szczepanek-arm Feb 1, 2019 •

edited

Loading

ntoni92 Feb 4, 2019

deepikabhavnani commented Jan 31, 2019

cmonr commented Jan 31, 2019

0xc0170 Feb 4, 2019

ntoni92 Feb 4, 2019

0xc0170 Feb 4, 2019

ntoni92 Feb 4, 2019

0xc0170 Feb 4, 2019

0xc0170 Feb 4, 2019

ntoni92 Feb 4, 2019

0xc0170 Feb 20, 2019

ntoni92 commented Mar 11, 2019

0xc0170 commented Mar 11, 2019

0xc0170 commented Mar 11, 2019

adbridge commented Mar 27, 2019

cmonr commented Mar 27, 2019

ntoni92 commented Mar 28, 2019

pan- commented Mar 28, 2019

adbridge commented Apr 26, 2019

adbridge commented May 1, 2019

		@@ -0,0 +1,336 @@
		/*******************************************************************************


		#ifdef CONTROLLER_DATA_LENGTH_EXTENSION_ENABLED
		#if (CONTROLLER_DATA_LENGTH_EXTENSION_ENABLED == 0)

Add TARGET_STMBLUE #9491

Add TARGET_STMBLUE #9491

Conversation

ntoni92 commented Jan 24, 2019

Description

Pull request type

Reviewers

ciarmcom commented Jan 24, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

paul-szczepanek-arm Feb 1, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

deepikabhavnani commented Jan 31, 2019

cmonr commented Jan 31, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ntoni92 commented Mar 11, 2019

0xc0170 commented Mar 11, 2019

0xc0170 commented Mar 11, 2019

adbridge commented Mar 27, 2019

cmonr commented Mar 27, 2019

ntoni92 commented Mar 28, 2019

pan- commented Mar 28, 2019

adbridge commented Apr 26, 2019

adbridge commented May 1, 2019

paul-szczepanek-arm Feb 1, 2019 •

edited

Loading