[NUCLEO_F411RE]: Some BLE examples doesn't work with the X-NUCLEO BLE shield
pan- opened this issue · 33 comments
- Description: The following BLE examples doesn't work on the NUCLEO_F411RE with the ST shield:
- BLE_BatteryLevel
- BLE_Button
- BLE_EddystoneObserver
- BLE_EddystoneService
- BLE_GapButton
- BLE_HeartRate
- BLE_LED
- BLE_LEDBlinker
- BLE_Thermometer
The cause of the failure is the use of an LED and the SPI1 in the same application. Even if the board define 4 LED, only 1 LED is actually accessible to the programmer and the LED line is shared with the clock line of the SPI1. Using both at the same time will cause failure regarding SPI communication and in this case prevent the application to actually work.
- Workaround: Remove the code related to the LED (including the declaration!), it is only use to show that the board is alive.
@apalmieriGH While the X_NUCLEO_IDB0XA1 warn about the Arduino connector, the F411RE page doesn't indicate that the LED can't be used if SPI1 is used at the same time.
I've found another issue regarding pin mapping of F411 and F401. In the datasheet, they are identical but they are declared differently in mbed.
Any update for this issue? we test the BLE_HeartRate_IDB0XA1, generate the bin by compiling with online compiler, found it work well. no LED1 and SPI1 conflict issue be found as your description. But faild when use the mbed-os-example-ble-xxx.
So, would like to know if it is really HW issue or it belong to SW issues since mbed-os 2 work well?
Actually we got a project by using X_NUCLEO_IDB0XA1 + STM32F401RE + mbed os 5.4, hope you guys can help to find the root cause, and fix it then.
Best Regards,
Xinbai
How do you test your mbed-os-example-ble-xxx? And what mbed-os-example-ble-xxx?
I had problem too using the mbed-os-ble-Thermometer. The Nordic app in Android expect to receive a "Indication" but the mbed-os-.... send a"Notification" it work making some changes in the HealthThermometerService.h.
I am using the same device as yours X_NUCLEO_IDB0XA1 + STM32F401RE.
Do not know if this could help.
jean-marc
Hello :-)
I use mbed on-line compiler.
Excellent Xinbai........ Great stuff.
The mbed-os on revision says tag:mbed-os-5.4.2 since I updated it recently... But never tried to compile and flash again.
You are right this revision does not work...
I revert back to 5.3 and it works.
Thank you Xinbai :+1
Post Scriptum: If this does help others as well. The revision 5.4.2 works on Nordic nRF52DK.
jean-marc
@liuxinbai The bug described here is specific to the NUCLEO_F411RE and it's IO mapping in mbed OS. I would be surprised if the mbed OS 2 example work. On the other hand, the NUCLEO_F401RE is not impacted by this shared I/O issue.
@liuxinbai @jmjobin I've found two bugs affecting the X_NUCLEO_IDB0XA1 under mbed OS 5.4:
- The link to the ST library is outdated, I'm not sure of how it happens, I've merged an update of this reference one month ago (#54) and somehow it was reverted.
- Mbed OS 5.4 has improved I/O throughput on STM boards. The side effect is an incorrect reset sequence of the X_NUCLEO_IDB0XA1 module (it is happening too fast).
We're working to deliver a fix to both of these issues in a timely manner.
Ready to test it :-)
@liuxinbai @jmjobin the problem encountered should be fixed now.
I tested now and still not OK... But strangely the OS rev. is still 5.4.2
What did you fix? Maybe I am not making the correct update!
@jmjobin Could you detail your setup: compiler used, example tested, sniffer used and revision of the example, mbed OS and at shield library ?
The reference to mbed OS has been updated to 5.4.2, previously these examples were using mbed os 5.4.1 and a bug has been fixed in the ST BLUENRG library. This library has been updated as well.
@pan Using the on-line compiler and IDE.
Previously the os-mbed was already denominated 5.4.2 please refer to my above message 6 days old. I mentioned this rev already. Surprise that the revision has the same number after your corrections.
My app is inspired from the example mbed-os-example-ble-Thermometer to build my own modified version. Modified basically the "main.cpp" and modified the HealthThermometerService.h for the notification.
All works fine with my nRF52DK and for NUCLEO_F401 need the version 5.3.6
@pan. I do not understand you so well sorry... Will try to answer.
When I looked at the mbed-os 6 days ago it mentioned the same rev number as today.
- Right click on mbed-os and ask for revision -> result = the last release is 5.4.2 as 6 days ago.
- Yes I did manually update the mbed-os. I go on the mbed-os and right click "update".
- No I did not update ST shield library, should I do this too?
I usually do not update the full package to keep my changes in the main.cpp
@jmjobin Thanks for your answer.
When I looked at the mbed-os 6 days ago it mentioned the same rev number as today.
Yes I did manually update the mbed-os. I go on the mbed-os and right click "update".
If you updated mbed os in your project then it makes sense that your revision was mbed OS 5.4.2 but these examples never referenced 5.4.2 until yesterday.
No I did not update ST shield library, should I do this too?
Yes you must update the ST shield library to get the fix.
I hope it is clear enough.
@pan- OK I updated the full example and it worked. I will have to reembed my main.cpp.
Thank you.
Jean-Marc
@pan I am so sorry I did not noticed the 2 different "pan". Will be more careful :-)
@pan- worked! Thank you. Would like to know the root cause, beside the modification in BlueNRGDevice::reset you mentioned, what wrong is in previous mbed OS version before 5.4.2?
Nothing is wrong in mbed OS 5.4.x but configuration and manipulation of GPIOs on NUCLEO based targets is has been improved and is is now faster than before. As a side effect, it exposed that the reset procedure was not respecting the expected timings.
Hi @pan-
My env : Nucleo F091RC + IDB05A1
I downloaded this project and trying to use BLE_HEARTRATE project
I made the changes suggested for nucleo boards with arduino connectors.
- override the target with settings
- Disable LED as a workaround.
mbed-os-example-ble/BLE_HeartRate$ git diff
diff --git a/BLE_HeartRate/mbed_app.json b/BLE_HeartRate/mbed_app.json
index 73e8c3c..441f631 100644
--- a/BLE_HeartRate/mbed_app.json
+++ b/BLE_HeartRate/mbed_app.json
@@ -8,6 +8,11 @@
"NUCLEO_F401RE": {
"target.features_add": ["BLE"],
"target.extra_labels_add": ["ST_BLUENRG"]
+ },
+ "NUCLEO_F091RC": {
+ "target.features_add": ["BLE"],
+ "target.extra_labels_add": ["ST_BLUENRG"],
+ "target.macros_add": ["IDB0XA1_D13_PATCH"]
}
}
}
diff --git a/BLE_HeartRate/source/main.cpp b/BLE_HeartRate/source/main.cpp
index bced96e..7e3c851 100644
--- a/BLE_HeartRate/source/main.cpp
+++ b/BLE_HeartRate/source/main.cpp
@@ -20,7 +20,7 @@
#include "ble/Gap.h"
#include "ble/services/HeartRateService.h"
-DigitalOut led1(LED1, 1);
+//DigitalOut led1(LED1, 1);
const static char DEVICE_NAME[] = "HRM";
static const uint16_t uuid16_list[] = {GattService::UUID_HEART_RATE_SERVICE};
@@ -50,7 +50,7 @@ void updateSensorValue() {
void periodicCallback(void)
{
- led1 = !led1; /* Do blinky on LED1 while we're waiting for BLE events */
+// led1 = !led1; /* Do blinky on LED1 while we're waiting for BLE events */
if (BLE::Instance().getGapState().connected) {
eventQueue.call(updateSensorValue);I have built and flashed the bin file but my stm32 profiles application does not show list this profile.
I am following the instructions here
ps: I am very new to BLE related programming.
@Binary-Nerd as you can see in the library page, the NUCLEO-F091RC is not included in the list of boards requiring the compatibility patch.
@apalmieriGH
I thought it is required for all the nucleo boards.
I removed the patch and checked. Same result. I am not able to see the HeartRate profile listed on the iphone app.
On the library page, it is mentioned
For X-NUCLEO-IDB05A1 this patch consists in removing zero resistor R4 and instead soldering zero resistor R6.
As i am using IDB05A1, Do i need to solder something?
@pan- @apalmieriGH
First i would like to know if the combination of NUCLEO_F091RC + IDB05A1 is supported by mbed or not.
If it is supported, according to my understanding, the latest mbed-os without any changes shoul work just fine. Am i correct?
@Binary-Nerd
I confirm that the NUCLEO F091RC is supported, no patch is required on the X-NUCLEO-IDB05A1 and the latest mbed-os-example-ble work fine once you have updated the mbed_app.json with the "NUCLEO_F091RC" label as you did.
no patch is required
Thank you. So, I understand IDB0XA1_D13_PATCH patch is not required for F091RC. Please correct me if I understood it wrongly.
the latest mbed-os-example-ble work fine once you have updated the mbed_app.json with the "NUCLEO_F091RC" label as you did.
Since the patch is not required, I added the following to my json
diff --git a/BLE_HeartRate/mbed_app.json b/BLE_HeartRate/mbed_app.json
index 73e8c3c..ea9f234 100644
--- a/BLE_HeartRate/mbed_app.json
+++ b/BLE_HeartRate/mbed_app.json
@@ -8,6 +8,10 @@
"NUCLEO_F401RE": {
"target.features_add": ["BLE"],
"target.extra_labels_add": ["ST_BLUENRG"]
+ },
+ "NUCLEO_F091RC": {
+ "target.features_add": ["BLE"],
+ "target.extra_labels_add": ["ST_BLUENRG"]
}
}
}
After this, i hope no more changes are required.
Testing procedure :
mbed compilecp ./BUILD/NUCLEO_F091RC/GCC_ARM/BLE_HeartRate.bin /media/mypc/NODE_F091RC/
Once the nucleo boots up and the LED starts blinking, I am opening my stm32profiles application and scanning for the devices. I am expecting to see some heartrate profile being listed after scan.
But the scan result is empty as of now.
If it is working for you, I believe I am doing something wrong. I am trying to figure it out. If you see any issues with what I wrote above, kindly let me know.
Thank you very much!
@Binary-Nerd
Did you update the FW of your X-NUCLEO-IDB05A1 as recommended here?
@apalmieriGH
It turned that the problem is with the IDB05A1 i have. With another one, it works just fine.
I tried updating the firmware of the IDB05A1 that was not working. firmware update fails with error code of 3. I will look into it later.
Thanks for assistance.
ARM Internal Ref: MBOTRIAGE-493
This issue can be closed based on the previous comments. Should be resolved