Adafruit Bluefruit doesn't advertise on Adafruit nRF52840 Feather Express

[charlesportwoodii]

ref: adafruit/Adafruit_nRF52_Bootloader#63 (comment)

I'd appreciate that. It might actually be working, but possibly I am missing a step. I downloaded your project and was able to build the bootloader hex file (I made no changes to the code) and flashed it using a JLink:

nrfjprog -e -f nrf52
nrfjprog -f nrf52 --program _build_mdk-usb-dongle/nrf52840_xxaa.hex
nrfjprog -f nrf52 --reset

But now the board "appears" to be bricked. None of the LED light up, no OTA DFU shows up when I scan for devices in NRF Toolbox. I can still recover the board by reflashing the Adafruit bootloader.

I then tried adding the hex file I exported from my Arduino, but it didn't seem to do anything at all.

nrfjprog --program sketch.ino.feather_nrf52840_express.hex  -f nrf52

[charlesportwoodii]

@dsteinman Moving this here since it's related to this bootloader instead of the Adafruit one.

A couple of things with the flash:

1. You need to flash the compiled board with the _s140 soft-device bundled with it. _build_mdk-usb-dongle/nrf52840_xxaa.hex doesn't contain the softdevice so it won't never start.

The Nordic Secure Bootloader can't start unless the soft device is present. If you've got one of the boards I've tested with on hand you can grab a pre-compiled hex from the releases page: https://github.com/charlesportwoodii/kaidyth_nrf52_bootloader/releases.

2. Which board are you using? Adafruit nRF52840 Feather Express? Or are you using a MDK USB Dongle?

3. I don't have an Adafruit nRF52840 Feather Express to test with at the moment but I can get one. The SparkFun Pro nRF52840 Mini board will probably be the best one to flash since it only has a single LED bound to 1,7.

If you flash this board you won't have any LED's since I don't have a board specific implementation for the Feather Express yet, but it should boot up and show up as Kaidyth DFU in the Nordic Connect iOS/Android app and as a new com/serial device on your computer for the USB interface.

Once you've verified the bootloader works you then need to flash the application. The Nordic Secure Bootloader needs a signed app zip. If you just flash the hex file the bootloader doesn't know the start address of the application and won't run it.

To generate that, you need to run the following command:

nrfutil pkg generate --hw-version 52 --application-version 1 --application /path/to/sketch.ino.feather_nrf52840_express.hex --sd-req 0xB6 --key-file /path/to/kaidyth_nrf52_bootloader/default_private.pem app_dfu_package.zip

Once you have an app_dfu_package.zip, you can either flash it over bluetooth from the NRF Connect app, or flash it over USB serial by running:

nrfutil dfu usb-serial --package /path/to/app_dfu_package.zip -p <serial_port>

On Linux <serial_port> will be /dev/ttyACMX, on MacOS it'll be /dev/cu.usbmodemxxxx and on Windows that'll be COMX, replace x with the actual usb device since it'll vary.

I only have a few of the chips on hand but can work on getting a Feather Express to try it out on and make the appropriate tweaks for. I have a few different applications running with this setup so this should all work.

Let me know if you have any issues with this. If the bootloader doesn't advertise then I'll need to make a custom definition for it to align the pins up.

[dsteinman]

Edit: Forget what I just wrote, looks like I've got it working. I had forgot the nrfjprog --reset -f nrf52 after trying the sparkfun firmware.

[dsteinman]

Okay, on the Adafruit board it looks like the Sparkfun firmware is at least loading correctly. Once I flash it and reset, I can see the Kaidyth DFU BLE device shows up in NRF Toolbox, and the /dev/cu.usbmodem device shows up on OSX. I can also perform the DFU update either mode - however in both cases the board now stuck/bricked in what looks like DFU mode. The BLE Device and USB are now gone, and both the Adafruit Neopixel (red only) and Red status LED are on. Resetting has to effect. If I hard reset only the Red status stays on and the Neopixel is now off.

[charlesportwoodii]

I'm looking to source a feather right now, Adafuit has them out of stock so I need to find another retailer who has one. Might take a few days to ship in.

At the moment, any firmware flashed to the 52840 feather in gonna "look" dead since the BSP lights aren't configured for that board. It should still advertise correctly though as you noted even if the bootloader LEDs don't work yet.

What are you flashing to the board? If you flash something and it stops advertising/showing the /dev/cu.usbmodem that means it's left bootloader mode and is running your application. The sparkfun bootloader has LEDs on pin 7 and 14, which on the feather map to a gpio pin instead of an actual LED, so any LEDs lighting up aren't coming from the bootloader.

If you do a double reset (double tap reset really quick) the board will go back into bootloader mode and you'll see the USB device/ble advertisement return.

If you're using Arduino, add some Serial.print somewhere in your code. That should trigger a new usb modem device to appear and you can debug your sketch on the board that way.

[dsteinman]

I really appreciate your help on this. I think it's close to working, or I have missed some simple step. Here are the exact commands I'm running, I can reproduce the problem every time.

nrfjprog -e -f nrf52
nrfjprog -f nrf52 --program sparkfun-pro-mini_bootloader-0.1.0_s140.hex
nrfjprog --reset -f nrf52

I created the dfu package just as you said:

rfutil pkg generate --hw-version 52 --application-version 1 --application mysketch.ino.feather_nrf52840_express.hex --sd-req 0xB6 --key-file default_private.pem app_dfu_package.zip

I can perform DFU over BLE, and the nrfutil dfu usb-serial .. command works as well. But once the DFU is finished the device is bricked. Resetting does nothing, I can't use Arduino's serial monitor to connect, and there's no /dev/cu.usbmodem device anymore, and no DFU BLE device is found. I don't even have Nordic's SDK installed so I don't exactly know how to debug what's going on here.

[charlesportwoodii]

@dsteinman Can you clarify a few things for me?

1. You're using a Adafruit nRF52840 Feather Express, right? Not a nRF52832?
2. If you double press the reset button quickly does the board go back into DFU mode as evident by BLE/USB modem re-appearing?
3. What sketch are you using? A Blufruit one? It sounds like the app is crashing somewhere. Could you upload the .ino here?
4. Are you able to create a simple serial sketch that just prints something to the serial out and monitor it using tio or screen to see if your app is even running?

My guess is that something in the app's bluetooth stack isn't happy, but I don't know enough about the board itself to know what the LED indicators mean.

I have a Feather on order and should have it maybe by this weekend to build out a dedicated definition for it.

[dsteinman]

You were right! Something in my sketch was causing the problem. I simplified it right down to just a Serial and LED sketch and everything worked as expected.

I was fairly quickly able to nail down exactly what part of the Arduino sketch that was the problem: Adafruit's Bluefruit library is not compatible, I presume because of the Nordic SDK or SoftDevice version mismatch.

Bluefruit.begin();

I guess until Adafruit catches up to the latest Nordic versions these libraries won't be usable with this bootloader.

[charlesportwoodii]

The Bluefruit Arduino libs don't actually touch anything with the Nordic SDK, they just interact with the soft device. Both this bootloader and the Adafruit one use s140 6.1.1, so if the sketch is hanging it's probably a RAM conflict between the softdevice and something else on the chip.

I did read something regarding the soft device and neopixel ram region conflicting: https://forums.adafruit.com/viewtopic.php?f=8&t=129210. It's possible that there's a ram conflict which causes the app to hang

Are you able to flash the Blufruit bleuart sketch bundled with the blufruit library as-is to the device and have it work?

Once I get a device I can check the RAM regions with SEGGER and see if anything is clashing.

[dsteinman]

Yeah I can run the Blufruit bleuart sketch when I upload using Arduino & Adafruit's bootloader, but with your bootloader and flashed with nrfutil then it's failing. Arduino is hanging when I open the Serial monitor.

[charlesportwoodii]

Okay, that's almost certainly a RAM conflict, start address issue, or uicr_bootloader_start_address setting that needs to be changed somewhere. This bootloader has a slightly different start address that Arduino doesn't like.

I don't know exactly how Arduino handles that but it's certainly a solvable problem. Once I get this device in particular I can debug it further on chip.

[dsteinman]

Okay, thanks again for doing this, I'll check it out again if you figure it out.

This is a really good project BTW, it fills a big a gap between Arduino and the Nordic SDK.

Your bootloader also worked with this web version of the Nordic OTA DFU: https://github.com/thegecko/web-bluetooth-dfu which was what I was really interesting in getting working.

[charlesportwoodii]

Glad to hear the web interface is working. I hadn't explicitly tested that yet.

Feather chip should arrive sometime this weekend for testing.

I played around with a few other boards I had to see if I could reproduce the crash. While I wasn't able to get the chip to advertise, I didn't see that it had crashed - everything within my void loop() (just toggling an LED back and forth) was working just fine. A memory region conflict would have triggered a hard crash so I'm not exactly sure why it isn't advertising. The Arduino stuff doesn't really care about the Nordic SDK used in the bootloader so I'm not sure what's happening.

I spent way too long tinkering with the Arduino variants though that I at this point I'm going to wait until I get an actual feather that has the variant.h already setup for me.

My next update won't be until after I get the chip and can play around with it actually.

[charlesportwoodii]

Feather arrived and I was able to play with it.

I've merged in a formal board definition with working LED's so you can check the status of the board. The red LED should be solid and the blue LED should blink while in DFU mode. As long as you're able to get back into DFU mode from anywhere via the double reset trick, the bootload itself is functionally fine.

Regarding the Bluefruit libraries...
I've racked my head against everything I can think of at the present. I've tried a couple of things:

• Tracing Bluefruit.cpp
• Modifying the linker settings
• Tracing the bootloader to make sure the app loads correctly
• Verified soft device versions match

As far as I can tell, the bootloader hands off to the application normally, then the Bluefruit library itself hangs.

My best guess at the moment is that something with usb/softdevice is handing at around Bluefruit.cpp#462. If I give the linker bad options it halts here as expected, but I can't seem to trace any further than that short of without a full fledged debugger for Arduino.

Unfortunately I can't seem to get SoftwareSerial to write to my uart serial breakout to see if it's solely a problem with the USB serial bus or if it's actually getting further on in the process but hanging somewhere else. I'm leaning towards a USB bus issue in bluefruit since I get log data with a bad linker address but don't when I'm using the default.

I'll obviously keep playing with it, but I suspect there's something wrong with the Bluefruit lib that is causing this interaction to be unhappy. This is actually my first time playing with Arduino so I might be missing something obvious when working through the Bluefruit libs. Their library might be tightly coupled to the bootloaders they have written, rather than being general enough to work with the Nordic Secure bootloader, which this also doesn't seem to work with.

[charlesportwoodii]

Looks like someone with the stock Nordic bootloader is also having the issue: adafruit/Adafruit_nRF52_Arduino#200 (comment). It looks like that issue was closed without resolution, so it looks like Adafruit just might not support it.

In that case you might be on your own either finding or writing a more standard nRF52 BLE library for Ardunio.

[dsteinman]

Thanks Charles, I appreciate the time you spent taking a look. At the very least we have a better idea what's going on.

I wouldn't have the time or skillset to write my own BLE library to replace Bluefruit, but I can't help but think there might be a lot of other people who might be in a similar situation as me - wanting to migrate away from Adafruit's bootloader but still use Arduino and Adafruit's BLE libraries. Perhaps it would be worthwhile opening a specific issue in "Adafruit_nRF52_Arduino" to raise awareness of your bootloader and that Bluefruit BLE issues might be able to be fixed.

[charlesportwoodii]

Sure. Just to clarify though this issue is related to the Nordic Secure Bootloader, which this is built off of. If you flash the example secure_dfu to the board you'd get the same error.

adafruit/Adafruit_nRF52_Arduino#200 (comment) seems to already raise the issue, and Adafruit doesn't seem to be putting any support into it.

I'm not able to rewrite their library at this time. I'm sure some people could use Arduino nRF52 BLE but I don't have the time right now to undertake that. Given this is an upstream issue I'm going to close this issue out. My advice would be to write your own app using the Nordic SDK for any BLE functionality you need, at least until Adafruit can support the secure bootloader.