I bought four of your products, (2)x Adafruit Feather nRF52832 and (2)x Adafruit Feather nRF52840 Express, respectively. I’m not new to programming but I’m new to this. It's very exciting the projects we can do with this technology, especially using BLE abilities!
I successfully implemented a simple program that advertises a random generated number using the environmental sensing service and uv index characteristic. It worked fine but then when I revisited it a few weeks later I ran into some issues.
The code is as follow:
Code: Select all
#include <bluefruit.h>
uint8_t uvindexvalue = 0x0;
#define UUID16_SVC_ENVIRONMENTAL_SENSING 0x181A
#define UUID16_CHR_UV_INDEX 0x2A76
BLEService environmental_sensing_service = BLEService(UUID16_SVC_ENVIRONMENTAL_SENSING);
BLECharacteristic uv_index_characteristic = BLECharacteristic(UUID16_CHR_UV_INDEX);
void setup() {
Serial.begin(115200);
delay(500);
Serial.println("Start!");
Bluefruit.begin();
Bluefruit.setName("Palm");
setupESService();
startAvd();
}
void loop() {
uvindexvalue = random(0, 11);
Serial.print("UV Index: ");
Serial.println(uvindexvalue);
if (uv_index_characteristic.indicate(&uvindexvalue, sizeof(uvindexvalue))) {
Serial.print("Updated UV Index: ");
Serial.println(uvindexvalue);
}
else {
Serial.println("UV Index Indicate not set");
}
delay(1000);
}
void startAvd(void) {
Bluefruit.Advertising.addService(environmental_sensing_service);
Bluefruit.Advertising.addFlags(BLE_GAP_ADV_FLAGS_LE_ONLY_GENERAL_DISC_MODE);
Bluefruit.Advertising.addTxPower();
Bluefruit.Advertising.addName();
Bluefruit.Advertising.restartOnDisconnect(true);
Bluefruit.Advertising.setInterval(32, 244);
Bluefruit.Advertising.setFastTimeout(30);
Bluefruit.Advertising.start(0);
}
void setupESService(void) {
environmental_sensing_service.begin();
uv_index_characteristic.setProperties(CHR_PROPS_INDICATE);
uv_index_characteristic.setPermission(SECMODE_OPEN, SECMODE_NO_ACCESS);
uv_index_characteristic.setFixedLen(1);
uv_index_characteristic.begin();
uv_index_characteristic.write(&uvindexvalue, sizeof(uvindexvalue));
}
On January 22th It was working perfectly. I saved the code right away in a safe place since I was planning to put it all together with other elements, once I solved challenges separately.
On February 6th, I started putting it all together. I usually retest each part one by one, not only to be sure that everything is ok but also to refresh my memory on the projects… and surprisingly this one is not working anymore. It started to display the message “UV Index Indicate not set”, which means it was not successful executing the characteristic indicate action.
So the first question I tried to answer was: “is there any chance that the device got damaged somehow in the process?”. I have another nRF52832 as a backup, it was new and I have never used it before. Updated the bootloader like I did with the previous one and like Adafruit presents at https://learn.adafruit.com/bluefruit-nr ... bootloader , it seemed the guide is a little bit outdated but I was able to follow along. After that I flashed the code and got the same message. I also asked a friend to do the same, new and clean device, he got the same message. I also tested another part of the project, an nRF52832 advertising and a nRF52840 detecting its RSSI, it works perfectly. So I believe that the device is not damaged, as it would also seem the chance of three devices being damaged is low.
Next question was: “Why is it not indicating successfully in the code, is there a chance that something in the Adafruit API has changed, Arduino IDE updated it in the background and some configurations are missing?“ I started digging the code, I went to the folder C:\Users\\AppData\Local\Arduino15\packages\adafruit\hardware\nrf52\1.3.0\libraries\Bluefruit 52Lib\src and read the code at BLECharacteristic.cpp.
I also noticed that only bluefruit.h had a later modified date - February 3rd for bluefruit.h and the remaining files January 12th, accordingly.
I’m not aware of any tools that can help debug this so I’m using the old fashion debug technique of printing out values, with the help of Serial.print.
In the BLECharacteristic.cpp, at BLECharacteristic::indicate (https://github.com/adafruit/Adafruit_nR ... 52Lib/src/
BLECharacteristic.cpp at line 894)
Step 1) I added the following print just to be sure that I was in the right place:
Code: Select all
bool BLECharacteristic::indicate(const void* data, uint16_t len)
{
Serial.print("abc ");
Serial.println(BLE_CONN_HANDLE_INVALID);
return indicate(BLE_CONN_HANDLE_INVALID, data, len);
Step 2) Next at line 844:
Code: Select all
bool BLECharacteristic::indicate(uint16_t conn_hdl, const void* data, uint16_t len)
{
Serial.print("abc: ");
Serial.println(_properties.indicate);
VERIFY( _properties.indicate );
Step 3) We already know from step 1) that it will fall in the if statement where it tests: conn_hdl == BLE_CONN_HANDLE_INVALID
So it do this: conn_hdl = Bluefruit.connHandle();
Just to be sure I added the following at bluefruit.cpp (https://github.com/adafruit/Adafruit_nR ... 52Lib/src/
bluefruit.cpp at line 643)
Code: Select all
uint16_t AdafruitBluefruit::connHandle(void)
{
Serial.print("I was here! ");
Serial.println(_conn_hdl);
return _conn_hdl;
So we have a new question: “why _conn_hdl has this value and when it becomes like that?”
At the moment I can try to dig more and try to find an answer to the above question… But it doesn’t feel like I will find any answer or at least one with a meaning for my limited knowledge about the subject. And also… I had this working a few days ago.
So Adafruit Team, I was wondering if there was any chance that this problem can be related somehow with Adafruit api or even Nordic api, some update that added some kind of an extra step to setting things up? I also noticed those red messages present in several pages of Adafruit guide which made me wonder.
Also do you have any suggestion/advice on how to fix this? Or to find some clues to help solve the problem?
In advance thank you for your time Adafruit Team!