adafruit / adafruit_nrf52_arduino Goto Github PK

Checking Bluefruit.connected() always returns true.

We need a throughput example that behaves identically to the nRF51 one to compare and have for support reasons.

https://github.com/adafruit/Adafruit_BluefruitLE_nRF51/blob/master/examples/throughput/throughput.ino

We might need to tweak the architecture string ... building something with Wire currently gives this warning:

WARNING: library Wire claims to run on [nRF5] architecture(s) and may be incompatible with your current board which runs on [Adafruit_nRF52_Arduino] architecture(s).

Sketch uses 4,476 bytes (2%) of program storage space. Maximum is 161,792 bytes.
```

By default, BLE and the nRF52 are limited to transmitting 20 bytes per packet, but there is a mechanism to transfer more data for higher throughput on supporting devices (on both ends of the connection).

An optional command should be added to the Bluefruit class to enable extended packets.

See the following thread for details: https://devzone.nordicsemi.com/question/95745/what-is-the-max-data-throughput-with-s132-v3/?answer=95750#post-id-95750

This should allow up to 244 bytes per transfer.

The nRF52 ADC can be configured to use an internal +/-0.6V ref or external VDD: http://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.nrf52832.ps.v1.1%2Fsaadc.html&cp=2_2_0_36_7&anchor=concept_kxz_4pp_qr

Make sure we can easily switch between references with the ADC code on the Arduino side, and check that the change actually works.

• Add a reasonably complete ADC example sketch where the user case set:
  • ADC Resolution (via analogReadResolution(14))
  • ADC reference (via analogReference)
• Add a helper function to wiring_analog_nRF52.c to set the Gain???
• Add a helper function to wiring_analog_nRF52.c to set the acquisition time?

Also ... set the default ADC parameters to the following:

• Internal Reference (+/-0.6V)
• Default gain 1/6 (0..3.6V range)
• 10-bit output
• 3us acquisition time

Current defaults aren't useful since the gain is hard coded to '1':

NRF_SAADC->CH[0].CONFIG = ((SAADC_CH_CONFIG_RESP_Bypass   << SAADC_CH_CONFIG_RESP_Pos)   & SAADC_CH_CONFIG_RESP_Msk)
                            | ((SAADC_CH_CONFIG_RESP_Bypass   << SAADC_CH_CONFIG_RESN_Pos)   & SAADC_CH_CONFIG_RESN_Msk)
                            | ((SAADC_CH_CONFIG_GAIN_Gain1    << SAADC_CH_CONFIG_GAIN_Pos)   & SAADC_CH_CONFIG_GAIN_Msk)
                            | ((saadcReference                << SAADC_CH_CONFIG_REFSEL_Pos) & SAADC_CH_CONFIG_REFSEL_Msk)
                            | ((SAADC_CH_CONFIG_TACQ_3us      << SAADC_CH_CONFIG_TACQ_Pos)   & SAADC_CH_CONFIG_TACQ_Msk)
                            | ((SAADC_CH_CONFIG_MODE_SE       << SAADC_CH_CONFIG_MODE_Pos)   & SAADC_CH_CONFIG_MODE_Msk);

See also #14

https://forums.adafruit.com/viewtopic.php?f=57&t=114270&p=572407#p572407

Some user asks for it. However, iOS may not support this (need double check)

When running HID with Debug level = 0, even bonded, macOS GUI still display the spinning icon. It does not affect the functionality and disappear when go back to system setting but kind of annoyance.

Issue does not happen when running with Debug level =1+

In terms of callbacks to make life easier for customers, we should have optional connected and disconnected callbacks as a minimum, which are easy to implement in peripheral mode since we only have one connection to worry about.

The more complicated question is how to handle GATT callbacks.

In the case of wrapper classes for things like BLE UART or HID Keyboard, this is easy since we can expose a callback specific to that class in the helper, but for user-defined GATT characteristics we'll need some sort of generic callback with a way to get the handle of the characteristic that caused the CB, etc.

• Add connectedcallback (peripheral mode)
• Add disconnected callback (peripheral mode), ideally including the reason (user disconnected, connection timed out, etc.)
• Add bleuart_rx callback (in the bleuart helper class)
• Define a generic gatt callback for user-defined characteristic changes, allowing easy access to the relevant characteristic data

Allow user to set/change passkey. Central must enter the correct PIN to pair
https://devzone.nordicsemi.com/question/122637/static-passkey-s132/

Flashing via nrfutil works fine from the Arduino when the Serial Monitor window isn't open, but fails if you keep Serial Monitor open during the flash process.

This has been confirmed on both OS X and Windows running Arduino 1.8.1 (the latest).

The most likely explanation is that when we flash, we reset the board via DTR, and then nrfutil starts flashing. The Serial Monitor then detects that the serial port re-enumerated, and tries to connect again to display data (and save users from manually reconnecting), and this is likely causing device corruption during the flash process.

Unfortunately, nrfutil is a black box, but at least the issue is repeatable meaning a solution can be found, but this will probably require some digging. Users should be able to keep Serial Monitor open, though, since this is normal behaviour for any other Arduino board.

Precondition: Bootloader must be updated to work with SD132 v5 as well

S132 v5 will give nrf52832 better throughput + broadcast

Hi!

Thank you for all the hard work, bluefruit is awesome.
I was wondering: Is there a plan to move to version 3.0.0 of the s132 sdk?
That version is supposed to suppose BLE packet length extension and thus increase the possible throughput by a lot.

Best

#31

By default, we should perhaps protect the bootloader and SD section of memory from being overwritten, since users can (and will) do stupid things with the OTA updater.

The Arduino IDE is safe without a JLink (etc.) connected, but you can update the bootloader and SD OTA, which I think we should only make possible once you have done a secret handshake like running a sketch the 'unprotects' those sections, making the user responsible for their actions.

There are mechanism to protect certain parts of flash, presumably for the nRF52 as well: https://devzone.nordicsemi.com/question/16414/protect-bootloader-from-overwriteerase/

https://developer.apple.com/library/content/qa/qa1931/_index.html

For discovering your accessory successfully

You must follow the general advertising guidelines in the Bluetooth Accessory Design Guidelines for Apple Products when constructing your advertising packets. A common mistake is to use improper advertising intervals, either due to misconfiguration or in order to save battery usage on the peripheral. Improper intervals are the most common reasons for your app to not be able to discover your accessory in the field, even though you may have observed discovery working properly in your tests.

The advertising interval of your peripheral affects the time to discovery and connect performance. Outside of ideal conditions, for example when your app is no longer active in the foreground, the time to discovery becomes longer. To maximize the probability of being discovered, the accessory must advertise at one of the listed intervals exactly.

The recommended advertising pattern and advertising intervals are:

• First, advertise at 20 ms intervals for at least 30 seconds
• If not discovered after 30 seconds, you may change to one of the following longer intervals: 152.5 ms, 211.25 ms, 318.75 ms, 417.5 ms, 546.25 ms, 760 ms, 852.5 ms, 1022.5 ms, 1285 ms

Important: These specific intervals are the ones to be used exactly! Even the slightest deviation from these actual intervals may dramatically increase your time to discovery.

Note: The above advertising intervals are only for non iBeacon BLE peripherals. For iBeacon advertising, you must follow the iBeacon Specifications, which you can find in the iBeacon for Developers page

https://developer.apple.com/library/content/documentation/CoreBluetooth/Reference/AppleMediaService_Reference/Specification/Specification.html

RSMB (Really Small Message Broker) https://github.com/eclipse/mosquitto.rsmb
MQTT-SN client https://github.com/eclipse/paho.mqtt-sn.embedded-c

Can be used to implement #25

there is bug with freeRTOS tick port in sdk 11. Need to inject fixes from sdk13 for freeRTOS port
https://devzone.nordicsemi.com/question/80413/freertos-tick-issue-on-nrf52-can-lead-to-lockups-sdk11/

Hello,

This variable definition
uint8_t custom_service_uuid[] = {0xa4, 0x95, 0xff, 0x20, 0xc5,0xb1,0x4b,0x44,0xb5,0x12,0x13,0x70,0xf0,0x2d,0x74,0xde};

Yields this transmitted UUID when compiled with the Adafruit Feather 32u4 library. This one matches the orientation of the UUID bytes on other BLE devices that I have programmed, such as the Light Blue Bean and the SensorTag.
Service UUID : A495FF20-C5B1-4B44-B512-1370F02D74DE

And this reversed transmitted UUID when compiled with the new Adafruit Bluefruit nrf52 library. This one is definitely reversing the bytes which yields an incorrect UUID.
Service UUID : DE742DF0-7013-12B5-444B-B1C520FF95A4

Please advise on when a fix will be applied, I am sure that this will impact others as well.

Best regards
John

to monitor task, memory and thread resource for high level debug level3+

https://www.segger.com/jlink-rtt.html

Control basic GPIO, execute command such as

• pinMode
• digitalWrite
• analogWrite
• analogRead
  Etc....

The VBAT resistor divider needs a helper function with the following AC config:

• Configure A7/P0.31 as an analog input
• Use internal (+/-0.6V) reference
• Set 1/5 gain (for 3.0V range)
• Set 12-bit output
• Convert the value returned to mV based on the resistor divider network, which has the following properties:

Maximum voltage: 4.2 V * (2 M/(0.8 M+2 M)) = 3 V
Minimum voltage: 2.7 V * (2 M/(0.8 M+2 M)) = 1.93 V
ADC value at 4.2 V - 12 bit setup: 3 V * (1/5) / 0.6 V * 4095 = 4095
ADC value at 2.7 V - 12 bit setup: 1.93 V * (1/5) / 0.6 V * 4095 = 2634
Usable ADC resolution - 12 bit setup: 4095 - 2634 = 1461
ADC output = 0.00102669 mV per LSB

For details on the VBAT/ADC design see this reference:

pynrfjprog only seems to work with 32-bit python ... it fails on 64 bit on Windows. For the moment we will put the Nordic binary tools directly in the repo (https://www.nordicsemi.com/eng/Products/Bluetooth-low-energy/nRF52832#Downloads) but other options might need to be considered.

Filing this issue until we find a solution to remove the Windows x64 binaries and convert the python tool to a x64 Windows binary, which will make things much simpler on Windows the running a binary tool.

digitalRead (wiring_digital.c) only works when the pin is configured as an input, but should also work checking the state of an output pin.

Code

The following code will always return '0' (low) even though the GPIO pin is clearly being toggled:

#include <Arduino.h>

const int baudrate = 115200;

void setup() {
  Serial.begin (baudrate);
  
  pinMode(PIN_LED2, OUTPUT);
}

void loop() {
  int val = 0;

  digitalWrite(PIN_LED2, HIGH);
  val = digitalRead(PIN_LED2);
  Serial.println(val, HEX);
  delay(500);

  digitalWrite(PIN_LED2, LOW);
  val = digitalRead(PIN_LED2);
  Serial.println(val, HEX);
  delay(500);
}

Issue

The nRF5x has separate NRF_GPIO->IN and NRF_GPIO->OUT registers. The current implementation of digitalRead assumes the pins is always configured as an input when we read it, but while this is true 95% of the time we should detect the pin mode and if it is an OUTPUT use the OUT register:

int digitalRead( uint32_t ulPin )
{
  if (ulPin >= PINS_COUNT) {
    return 0;
  }

  ulPin = g_ADigitalPinMap[ulPin];

  return ((NRF_GPIO->IN >> ulPin) & 1UL) ? HIGH : LOW ;
}

This is purely cosmetic but slipped past us in the 0.6.0 update. For 0.6.1, the following warnings need to be removed when compiling:

WARNING: library Wire claims to run on [Adafruit_nRF52_Arduino] architecture(s) and may be incompatible with your current board which runs on [nrf52] architecture(s).
WARNING: library SPI claims to run on [Adafruit_nRF52_Arduino] architecture(s) and may be incompatible with your current board which runs on [nrf52] architecture(s).
Sketch uses 51792 bytes (30%) of program storage space. Maximum is 167936 bytes.

Also, SRAM usage should be added to the output since this is often more critical than flash on a large chip like this.

The DIS service should be updated to make .setSerial and .setFirmwareRev internal/private.

• .setSerial should be populated with the unique device ID from the nRF52
• .setFirmwareRev should be populated with:
  • ARDUINO_BSP_VERSION
  • BOOTLOADER_VERSION
  • SD_NAME
  • SD_VERSION
  • For example, Firmware Version should be set to 0.2,0.5,S132,11.2, which uses 17 bytes

The following characteristics should remain public and accessible to end users, but with the following defaults values

• Model: Feather52
• Software Rev: --
• Hardware Rev: --
• Manufacturer: Adafruit Industries

New MCU famliy, we need to add its code for Neopixel, I poked around, but couldn't make any sense from the show() timing/delay nop function :(
https://github.com/adafruit/Adafruit_NeoPixel

• replace cprint with _write() _read() hooks

For simplicity sake nrfjprog and mergehex must be on the system path to enable bootloader flash support, but these should be included in the tools folder for public releases to avoid customers having to touch their system paths.

The required JLink tools are already installed on the system path when you run the Segger installer, so that is take care of.

Create a Central demo with a mailbox pattern where:

• The Central device maintains a 'Mailbox' server, with a single mailbox for each device address (1KB per mailbox?)
• Mailbox data can be persisted to NFFS files (one file per address) for recovery at startup
• The Central advertises itself with a specific 'Mailbox Server' UUID in the advertising packet
• Up to 7 links/mailboxes can be established
• Peripherals can check for any message(s) in their own mailbox
• Peripherals can scan for other mailboxes on the Central, and retrieve the following information:
  • Device address
  • Device Name
  • RSSI value if connected
  • Timestamp when the peripheral was last connected
• Peripherals can write messages to every mailbox (using a global address like FF:FF:FF:FF:FF:FF?) or to a specific mailbox (using a specific device address)

This allows a reasonably complete Central example, solving a practical problem and allowing for a very simple star network with point to point (1:1) and point to multi-point (1:all) exchanges, without getting overly complex, allowing simple BLE based sensor networks.

Two examples sketches are required for this demo:

• The Central mailbox server (mailbox_server or mailbox_central)
• The Peripheral mailbox client (mailbox_client or mailbox_peripheral)

When booting up, check the FRST button (P0.22) if it is in GND state, and if so perform the following actions:

• Erase any bonding information from the 28KB user flash area
• Erase the user sketch

For copyright reasons we can't have the bootloader code in this repo. It should be moved to https://github.com/adafruit/Adafruit_nRF52_Arduino_Bootloader which is private for now.

Make sure the bootloader functions against this schematic/pinout, and that the BSP in the repo is setup appropriately when Feather52 is selected.

PDF Link

Feather_Mynewt_BLE_REV-E.pdf

PNG Version

Board Layout

For convenience sake, the pinouts can be seen below:

• Internal pullups should be enabled on DFU and FRST at startup (and before sampling!)
• DFU GND , FRST HIGH = Enter SERIAL Bootloader
• DFU GND, FRST GND = Enter OTA Bootloader
• DFU HIGH, FRST LOW = Factory Reset

The silk on the FRST pin will be updated to indicate that the pad is dual usage, but this will be rarely used (Boot into OTA or factory reset), so I'm OK with only BOOTSERIAL being available on a 0.1" pin.

Just as a proof of concept, a BLE UART helper class should be added to test the radio out with the Bluefruit LE Connect apps. I don't know of Sandeeps BLE Peripheral lib is the right long term solution, so a simple purely in house (simple) BLE example would be good to get people started.

I am trying to modify BLEuart example

I Have a question, Why is the cmdMessenger message over BLE Separating each character on a new line?
I hope the cmdMessage is sent as one "string" as in this case it is shorter than 20 bytes!!!
If not how should the code be changed?

I Have a question, Why is the cmdMessenger message over BLE Separating each character on a new line?
I hope the cmdMessage is sent as one "string" as in this case it is shorter than 20 bytes!!!
If not how should the code be changed?

Result 1 with
CmdMessenger cmdMessenger = CmdMessenger(Serial);
rest same as below...

Result 2
Code extract

#include <bluefruit.h>
#include "BNO055.h"
#include <CmdMessenger.h> // CmdMessenger
#include <SPI.h>
#include <Wire.h>
...
// BLE Service
BLEDis bledis;
BLEUart bleuart;
BLEBas blebas;
...
CmdMessenger cmdMessenger = CmdMessenger(bleuart);

short Q0 = mySensor.quat.q0;
short Q1 = mySensor.quat.q1;
short Q2 = mySensor.quat.q2;
short Q3 = mySensor.quat.q3;

cmdMessenger.printLfCr(true);

Serial.println("IMU Print");
bleuart.println("IMU Print");

cmdMessenger.sendCmdStart(kQuarternionSend);
cmdMessenger.sendCmdBinArg(Q0);
cmdMessenger.sendCmdBinArg(Q1);
cmdMessenger.sendCmdBinArg(Q2);
cmdMessenger.sendCmdBinArg(Q3);
cmdMessenger.sendCmdEnd();

Result 1 on serial Monitor
IMU Print
2,//,//,//,//;

Result 2 on nRF UART 2.0

RX: IMU Print
RX:
RX: 2
RX: ,
RX: /
RX:
RX: /
RX:
RX: ,
RX: /
RX:
RX: /
RX:
RX: ,
RX: /
RX:
RX: /
RX:
RX: ,
RX: /
RX:
RX: /
RX:
RX: ;
RX:

ISSUE: Several Arduino library uses malloc which is not thread-safe, this could lead to heap corruption.

implement thread safe malloc() using __malloc_lock() __malloc_unlock() with recursive mutex. Note: may need to upgrade toolchain to gcc 6 2017q1

reference

• https://answers.launchpad.net/gcc-arm-embedded/+question/229509
• https://developer.mbed.org/users/AdamGreen/notebook/newlib-nano/
• https://github.com/spark/firmware/issues/826

related topic
https://devzone.nordicsemi.com/question/101658/windows-10-driver-error-when-connecting-hid-device/

since iPhone support this, it could be useful to retrieve time from iOS device

We will need an CLI tool on OSX/Linux to perform OTA with native bluetooth controller.

The simplest possible example should be added just as a proof of concept that central mode works:

• Listen for any advertising devices in range
• When an advertising packet is detected, print the following on a single line in the Serial Monitor:
  • Timestamp
  • Device address
  • RSSI
  • Advertising packet contents

This allows users to setup several devices in beacon type mode for a test scenario without too much work or effort, and allows us to test the Central part of SD132 before release.

For better bond management, use central name and/or with mac addr

https://forums.adafruit.com/viewtopic.php?f=57&t=114274