SparkFun Forums 

Where electronics enthusiasts find answers.

#202843
I am having some issues with a newly purchased SparkFun Pro nRF52840 Mini, specifically around getting adafruit-nrfutil working to program an application and getting the bootloader to work properly. I've attempted to document all the issues I'm having with this newly purchased chip.

The issues I'm having:

1. Unable to flash chip
2. RST/PIN 13 not working as expected.
3. USB mass-storage not working

More details for each issue are listed as follows. I've attempted to be as thorough as possible with descriptions.

1. The first issue I'm having is that adafruit-nrfutil can't flash an application.

I've tried flashing a custom program on both a Windows 10 (1809) and Linux (Ubuntu 18.04) machine and see the same issue on both platforms. On both platforms I'm using adafruit-nrfutil dfu serial to flash the application. Both platforms output the following error:
Code: Select all
No data received on serial port. Not able to proceed.
The device immediately goes into DFU mode when I plug it in (blue pin 7 immediately starts blinking). The double reset method doesn't seem to change anything (however RST+PIN13 puts the device in some mode other than DFU, see issue #2).

I've provided output from both systems as reference:

Linux

The command on Linux is as follows:
Code: Select all
$ adafruit-nrfutil --verbose dfu serial --package _build/dfu-package.zip -p /dev/ttyACM0 -b 115200 --singlebank --touch 1200
And the output:
Code: Select all
adafruit-nrfutil --verbose dfu serial --package _build/dfu-package.zip -p /dev/ttyACM0 -b 115200 --singlebank --touch 1200
Upgrading target on /dev/ttyACM0 with DFU package /home/<user>/Projects/nrf52/pbrick/boards/sparkfun-pro-mini/s140/armgcc/_build/dfu-package.zip. Flow control is disabled, Single bank, Touch 1200
Touched serial port /dev/ttyACM0
Opened serial port /dev/ttyACM0
Starting DFU upgrade of type 4, SoftDevice size: 0, bootloader size: 0, application size: 68200
Sending DFU start packet
Timed out waiting for acknowledgement from device.

Failed to upgrade target. Error is: No data received on serial port. Not able to proceed.
Traceback (most recent call last):
  File "/home/<user>/.local/lib/python3.6/site-packages/nordicsemi/__main__.py", line 294, in serial
    dfu.dfu_send_images()
  File "/home/<user>/.local/lib/python3.6/site-packages/nordicsemi/dfu/dfu.py", line 235, in dfu_send_images
    self._dfu_send_image(HexType.APPLICATION, self.manifest.application)
  File "/home/<user>/.local/lib/python3.6/site-packages/nordicsemi/dfu/dfu.py", line 200, in _dfu_send_image
    application_size)
  File "/home/<user>/.local/lib/python3.6/site-packages/nordicsemi/dfu/dfu_transport_serial.py", line 179, in send_start_dfu
    self.send_packet(packet)
  File "/home/<user>/.local/lib/python3.6/site-packages/nordicsemi/dfu/dfu_transport_serial.py", line 243, in send_packet
    ack = self.get_ack_nr()
  File "/home/<user>/.local/lib/python3.6/site-packages/nordicsemi/dfu/dfu_transport_serial.py", line 282, in get_ack_nr
    raise NordicSemiException("No data received on serial port. Not able to proceed.")
nordicsemi.exceptions.NordicSemiException: No data received on serial port. Not able to proceed.

Possible causes:
- Selected Bootloader version does not match the one on Bluefruit device.
    Please upgrade the Bootloader or select correct version in Tools->Bootloader.
- Baud rate must be 115200, Flow control must be off.
- Target is not in DFU mode. Ground DFU pin and RESET and release both to enter DFU mode.
Windows 10

The command on Windows is identical to the Linux command.
Code: Select all
adafruit-nrfutil.exe --verbose dfu serial -pkg dfu-package.zip -p COM3 -b 115200 --singlebank --touch 1200
The output is as follows:
Code: Select all
Upgrading target on COM3 with DFU package D:\Downloads\dfu-package.zip. Flow control is disabled, Single bank, Touch 1200
Touched serial port COM3
Opened serial port COM3
Starting DFU upgrade of type 4, SoftDevice size: 0, bootloader size: 0, application size: 68200
Sending DFU start packet
Timed out waiting for acknowledgement from device.

Failed to upgrade target. Error is: No data received on serial port. Not able to proceed.
Traceback (most recent call last):
  File "nordicsemi\__main__.py", line 294, in serial
  File "nordicsemi\dfu\dfu.py", line 235, in dfu_send_images
  File "nordicsemi\dfu\dfu.py", line 200, in _dfu_send_image
  File "nordicsemi\dfu\dfu_transport_serial.py", line 179, in send_start_dfu
  File "nordicsemi\dfu\dfu_transport_serial.py", line 243, in send_packet
  File "nordicsemi\dfu\dfu_transport_serial.py", line 282, in get_ack_nr
nordicsemi.exceptions.NordicSemiException: No data received on serial port. Not able to proceed.

Possible causes:
- Selected Bootloader version does not match the one on Bluefruit device.
    Please upgrade the Bootloader or select correct version in Tools->Bootloader.
- Baud rate must be 115200, Flow control must be off.
- Target is not in DFU mode. Ground DFU pin and RESET and release both to enter DFU mode.
2. Reset behavior not working as expected.

The instructions at https://learn.sparkfun.com/tutorials/sp ... bootloader outline the two reset methods to enter the bootloader for this device which I am following.

When I initially plug in the device, it appears to be in DFU mode (LED PIN7 is blinking blue). Both reset methods don't appear to be working as expected, but this may be because I'm already in DFU mode. If this behavior is expected please let me know.

- The double reset method (double tapping RST twice) doesn't seem to do anything. On other nRF52 chips I own, doing a reset (even when the board is in bootloader mode), causing the device to power off then go back into bootloader mode. Double pressing the RST twice doesn't appear to do anything. Again, this may be expected, it's just different than every other nRF52 chip I've seen.
- The PIN 13 + RST method takes the device out of DFU mode, and I can't get it back into DFU mode without a power cycle. Specifically, pressing PIN 13 by itself while in DFU mode causes PIN 7 to stop blinking. PIN 7 flashes once briefly then the chip goes dead with the exception of the red power LED on the USB mini port. Once I'm in this state, the only way to get back to DFU mode is to do a full power cycle of the device. PIN13 + RST or the double RST tap don't return the device to DFU mode.

3. USB device mass-storage issues.

On the stock bootloader, I'm supposedly able to upload uf2 files directly to the chip, however on both Windows 10 and Linux the USB mass-storage device doesn't appear to initialize properly.

On Windows 10, the device shows up but immediately prompts to be formatted. I can see the disk, however it shows up as an unformatted volume. Nothing I've read about the Adafruit nRF52 bootloader indicates I should need to manually format the device. My understanding from the documentation is that the device should be pre-formatted and have a NRF52BOOT label.

On Linux, the device gets detected but the disk never shows up as a removable USB drive. dmesg output seems to indicator there's something wrong with the filesystem. dmesg output is as follows:
Code: Select all
[33638.086551] usb 5-4: new full-speed USB device number 84 using xhci_hcd
[33638.236406] usb 5-4: New USB device found, idVendor=239a, idProduct=8029, bcdDevice= 1.00
[33638.236409] usb 5-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[33638.236411] usb 5-4: Product: Bluefruit nRF52840
[33638.236412] usb 5-4: Manufacturer: Adafruit Industries
[33638.236414] usb 5-4: SerialNumber: 52D9527575029108
[33638.247890] cdc_acm 5-4:1.0: ttyACM0: USB ACM device
[33638.248967] usb-storage 5-4:1.2: USB Mass Storage device detected
[33638.249185] scsi host9: usb-storage 5-4:1.2
[33639.255202] scsi host9: scsi scan: INQUIRY result too short (5), using 36
[33639.255208] scsi 9:0:0:0: Direct-Access     Adafruit Bluefruit nRF52  1.0  PQ: 0 ANSI: 2
[33639.255667] sd 9:0:0:0: Attached scsi generic sg3 type 0
[33639.256211] sd 9:0:0:0: [sdd] Very big device. Trying to use READ CAPACITY(16).
[33639.256500] sd 9:0:0:0: [sdd] physical block alignment offset: 3038083128
[33639.256503] sd 9:0:0:0: [sdd] Unsupported sector size 1097097574.
[33639.256509] sd 9:0:0:0: [sdd] 0 512-byte logical blocks: (0 B/0 B)
[33639.256521] sd 9:0:0:0: [sdd] 747384000-byte physical blocks
[33639.257269] sd 9:0:0:0: [sdd] Write Protect is off
[33639.257273] sd 9:0:0:0: [sdd] Mode Sense: 03 00 00 00
[33639.257545] sd 9:0:0:0: [sdd] No Caching mode page found
[33639.257554] sd 9:0:0:0: [sdd] Assuming drive cache: write through
[33639.257566] sd 9:0:0:0: [sdd] Optimal transfer size 0 bytes < PAGE_SIZE (4096 bytes)
[33639.258874] sd 9:0:0:0: [sdd] Very big device. Trying to use READ CAPACITY(16).
[33639.259484] sd 9:0:0:0: [sdd] Unsupported sector size 1097097574.
[33639.260134] sd 9:0:0:0: [sdd] Attached SCSI removable disk
For thoroughness, if I attempt to mount the disk I get the following error:
Code: Select all
$ sudo mount /dev/sdd /mnt/sparkfun-pro-mini/
mount: /mnt/sparkfun-pro-mini: can't read superblock on /dev/sdd.
-----------------------------------------

The chip definitely does not appear to be working as expected. My speculative guess is that either the bootloader is corrupt or there's some issue with the internal circuitry. The lack of volume label on Windows and PIN13/RST issue have me leaning towards a problem with the bootloader.

I would appreciate any help with trying to get this chip working or to do an RMA to see if maybe I just got a bad chip. I currently don't have access to a J-Link I can use to try to program the chip with nrfjprog.

Please let me know if you require any further information from me.

Thanks for your help!
#202878
Hi,

Following up because I was able to get access to a J-Link programmer to work on this some more, I'm still facing flashing issues though.

The problem definitely appears to be bootloader related. I'm guessing the chip was damaged in shipping.

Since the bootloader doesn't seem to be actually published anywhere (the product page just links directly to the Adafruit nRF52 Bootloader) and the board definition file seems incomplete for the bootloader I went ahead and forked the Adafruit nRF52 bootloader and tried to re-engineer what the settings should be as best I could (https://github.com/charlesportwoodii/Ad ... 840_mini.h).

With the J-Link I was able to flash the nRF52 bootloader with the modifications I made (I had to do it through the GPIO pins though as J-Link refused to do it over the 10 2x5 pins on the back). That seemed to fix all the initial issues I was having: I can now flash the device, double tap RST works, and the device shows up as USB mass storage now. The only issue that isn't solved yet is PIN13 + RST, which still puts the device in a mode _other_ than DFU and the application (tested by installing blinky app - if the blinky app is running and I do PIN13 + RST PIN7 flashes once, then there's nothing). This is less of an issue now that RST double tap works, but still doesn't align what's listed in the documentation.


However I'm still not out of the woods yet. While I'm able to flash programs (blinky app works just fine) I can't get anything with BLE to work. At the moment I can't even get the device to advertise the ble_app_blinky program.

My guess at the moment is that either the Soft Device that is flashed with the bootloader isn't working, or there's something wrong with the chip's BLE capabilities. Given that I can flash the Adafruit nRF52 Bootloader to a mdk-usb-dongle and get BLE working, and given that the bootloader header for this board just sets some pin-outs I'm leading towards an issue with the chip itself.

For reference, logs for the various things I've attempted are as follows:

Bootloader flash logs from adafruit-nrfutil (working on MacOS today as opposed to Windows or Linux)
Code: Select all
LD sparkfun_pro_nrf52840_mini_bootloader-0.2.10-4-ga6a47b9-dirty-nosd.out

   text    data     bss     dec     hex filename
  28524     348   22190   51062    c776 _build-sparkfun_pro_nrf52840_mini/sparkfun_pro_nrf52840_mini_bootloader-0.2.10-4-ga6a47b9-dirty-nosd.out

CR sparkfun_pro_nrf52840_mini_bootloader-0.2.10-4-ga6a47b9-dirty-nosd.hex
CR sparkfun_pro_nrf52840_mini_bootloader-0.2.10-4-ga6a47b9-dirty_s140_6.1.1.hex
Zip created at _build-sparkfun_pro_nrf52840_mini/sparkfun_pro_nrf52840_mini_bootloader-0.2.10-4-ga6a47b9-dirty_s140_6.1.1.zip
adafruit-nrfutil --verbose dfu serial --package _build-sparkfun_pro_nrf52840_mini/sparkfun_pro_nrf52840_mini_bootloader-0.2.10-4-ga6a47b9-dirty_s140_6.1.1.zip -p /dev/tty.usbmodem1431401 -b 115200 --singlebank --touch 1200
Upgrading target on /dev/tty.usbmodem1431401 with DFU package /Users/charlesportwoodii/Projects/personal/Adafruit_nRF52_Bootloader/_build-sparkfun_pro_nrf52840_mini/sparkfun_pro_nrf52840_mini_bootloader-0.2.10-4-ga6a47b9-dirty_s140_6.1.1.zip. Flow control is disabled, Single bank, Touch 1200
Touched serial port /dev/tty.usbmodem1431401
Opened serial port /dev/tty.usbmodem1431401
Starting DFU upgrade of type 3, SoftDevice size: 151016, bootloader size: 28864, application size: 0
Sending DFU start packet
Sending DFU init packet
Sending firmware file
########################################
########################################
########################################
########################################
########################################
########################################
########################################
########################################
################################
Activating new firmware

DFU upgrade took 19.115657091140747s
Device programmed.
Flashing ble_app_blinky:
Code: Select all
Flashing: _build/nrf52840_xxaa.hex
adafruit-nrfutil --verbose dfu serial --package _build/dfu-package.zip -p /dev/tty.usbmodem1431401 -b 115200 --singlebank --touch 1200
Upgrading target on /dev/tty.usbmodem1431401 with DFU package /Users/charlesportwoodii/Projects/nrf_sdk/15.3.0/examples/ble_peripheral/ble_app_blinky/sparkfun_pro_mini/s140/armgcc/_build/dfu-package.zip. Flow control is disabled, Single bank, Touch 1200
Touched serial port /dev/tty.usbmodem1431401
Opened serial port /dev/tty.usbmodem1431401
Starting DFU upgrade of type 4, SoftDevice size: 0, bootloader size: 0, application size: 27532
Sending DFU start packet
Sending DFU init packet
Sending firmware file
########################################
##############
Activating new firmware

DFU upgrade took 2.11122989654541s
Device programmed.
I've also attached the bootloader I flashed and the ble_app_blinky which followed the instructions outlined in https://learn.sparkfun.com/tutorials/nr ... e-nrf5-sdk.

Please let me know if there is any insight that can be provided as to why I can't get this chip to function properly with BLE.

I'm pretty sure the bootloader and soft-device are flashed correctly, but it would be extremely beneficial to have access to the stock bootloader hex/zip to see if that solves the problem. There may be additional changes I am not aware of with the bootloader that are needed to get this device to work. Otherwise I'm still looking at a non-functional chip.

Thanks for your help.
You do not have the required permissions to view the files attached to this post.
#202928
I spent some more time last evening digging through the Nordic S140 documentation and seem to have identified the problem.

The nRF52840 Advanced Development Guide for this board states that the FLASH and RAM regions should be setup as follows:
Code: Select all
MEMORY
{
  FLASH (rx) : ORIGIN = 0x26000, LENGTH = 0xce000
  RAM (rwx) :  ORIGIN = 0x20000000, LENGTH = 0x40000
}
However the S140 6.1.1 Soft Device documentation (which this board is suppose to be flashed with out-of-the-box) has a minimum RAM start address of 0x20001628. The conflicting RAM regions were preventing the SoftDevice from initializing properly.

Once I adjusted the RAM region everything started working. I haven't run it through SEGGER yet to determine if it's optimal or not, but it works.

--------------------------------------------------------

So, as a final summary for anyone who may stumble upon this and get a badly flashed chip upon arrival here's what I did to fix it:

1. The chip I received either had a bad flash, or the bootloader flashed to it was less than "heavily based upon" the Adafruit nRF52 Bootloader per the documentation.

Build my fork of the Adafruit nRF52 Bootloader and flash it to the device with a J-Link device. SEGGER has a J-Link Mini EDU for $20 USD that'll do the job.

Use the 10 (2x5) pin debugger points on the back of the device or manually connect the pins to a breakout board to do the flashing (I used a SWD breakout from Adafruit). Use the following mapping if you're not using the 10 pin on the back of the device.

JLINK => Board
--------------------
vREF => v3.3
GND => GND
RST => RST
SWIO => IO (bottom of board)
CLK => CLK (bottom of board)


You'll need nrfjprog from the nRF52 Command Line Tools to perform the flashing. Once you've flashed the Adafruit nRF52 Bootloader you can use adafruit-nrfutil moving forward to re-flash the bootloader, and can ditch the J-Link.

After building the bootloader, flash it using the following command:
Code: Select all
nrfjprog --program sparkfun_pro_nrf52840_mini_bootloader.hex --chiperase -f nrf52 --reset
I'll work on getting this merged into the main Adafruit nRF52 Bootloader repo so that it's "officially" supported.

2. For your application, adjust your linker's (.ld file) memory regions as follows:
Code: Select all
MEMORY
{
  FLASH (rx) : ORIGIN = 0x26000, LENGTH = 0xda000
  RAM (rwx) :  ORIGIN = 0x200022e0, LENGTH = 0x3dd20
}
--------------------------------------------------------

My recommendations for Sparkfun:

1. Adjust the recommended memory regions in the nRF52840 Advanced Development Guide to align better with the S140 6.1.1 Soft Device.

2. Publish the actual bootloader hex and source code rather than linking to the Adafruit Bootloader itself, or once this board is "officially" supported by the Adafruit nRF52 Bootloader just flash that as stock.


I'm a disappointed this board didn't just work out of the box. I'm sure this is just a one-off issue and I'm willing to give Sparkfun the benefit of the doubt since I've had badly flashed chips directly from Nordic as well. Hopefully if anyone else runs into the same problem as I did they won't need to spend several days trying to figure all this out again.
#202930
Hi Charles,

Thanks for posting all of this as I am sure it will come in handy for other users running into similar issues. In regards to the board you received, it definitely sounds like a potential issue with how the board was programmed and tested prior to shipping so if you can send me a private message with your order information, we would be happy to figure out some way to reimburse you for the malfunctioning Pro nRF52840 Mini you received.

We will also let our Engineering team know about the potential issues regarding the SDK development guide and we will look into that to see what fixes we can implement.
#203340
Hello Charles,
as I also own this board I would like to update the boot loader, but I haven't installed the Nordic SDK. Could you please provide the pre compiled hex file, e.g. under releases of your fork.
Thanks and regards
Ralf
#203358
@elral,

This is more of a recovery solution in the instance the provided bootloader doesn't work out of the box rather than an upgrade. I'd recommend sticking to the stock bootloader if yours works.

I'm not really looking to maintain a fork of Adafruit's bootloader in the long term or provide support for their bootloader. You don't need the nRF52 SDK installed, just follow the instructions on the Adafruit Bootloader's page to get build your own variant.
#204193
I am also seeing this issue. I haven't had trouble with the bootloader, but the ram allocation in the advanced guide doesn't work for the ble blinky example. It did work for the basic blinky example, though.

It works if I leave the default memory allocation:
MEMORY
{
FLASH (rx) : ORIGIN = 0x26000, LENGTH = 0xda000
RAM (rwx) : ORIGIN = 0x200022e0, LENGTH = 0x3dd20
}

However, the allocation given in the tutorial causes it to not work:
MEMORY
{
FLASH (rx) : ORIGIN = 0x26000, LENGTH = 0xce000
RAM (rwx) : ORIGIN = 0x20000000, LENGTH = 0x40000
}
#205072
TS-Mark wrote: Wed Apr 03, 2019 8:48 am Hi Charles,

Thanks for posting all of this as I am sure it will come in handy for other users running into similar issues. In regards to the board you received, it definitely sounds like a potential issue with how the board was programmed and tested prior to shipping so if you can send me a private message with your order information, we would be happy to figure out some way to reimburse you for the malfunctioning Pro nRF52840 Mini you received.

We will also let our Engineering team know about the potential issues regarding the SDK development guide and we will look into that to see what fixes we can implement.
First, I'm really glad the OP took the time to outline all of these issues. As I was searching for answers of my own, I was dreading having to write all of that myself since I am so novice. I initially thought I was doing something wrong...

I just purchased 2 of these boards, where as one seemed to work like most of the tutorial outlined, the second exhibits all of the symptoms outlined in this post. Before finding this post, I went ahead and purchased 2 more since I need 3 working ones for my project anyways. Sidebar --- @TS-Mark - Can I RMA the one that doesn't work for a refund/working spare?

The only other issue I am having, is with the Sparkfun variant of the adafruit feather boards that the tutorials had me install. With the Sparkfun variant selected, I try to compile/upload the blinky example from the tutorial and it gives an error of "Serial not declared in this scope" and suggests using Serial1. However after making that change it just causes a cascade of other errors in the bluefruit code. I'm fairly novice at all of this and couldn't find anything in the header files that stuck out to me. Am I missing something simple?? I tried the same thing on both Windows and Mac, both with fresh installs of Arduino IDE and Adafruit nRF52 boards.

Instead I just used that Nordic nRF52840DK (PCA 10056) board profile and it uploaded with no issues. From the tutorial, it didn't sound like it was going to cause many issues down the road, so I just went with it.
#205104
@charlesportwoodii - First, I apologize that our Pro NRF52840 Mini did not work out of the box and that you had to find a work around. Secondly, thank you so much for providing the details involved with the workaround. I have forwarded this topic over to our engineers and the solution will be prioritized soon.

@elral our forum users are certainly not obligated to maintain any kind of support for our products. Should our engineers make updates it will be in the product's GitHub repo. I would advise you keep an eye on it for now.

@TNichols if you would like to set a return up for your product you may fill an RMA ticket out and we will get the ticket processed as soon as possible. Please provide a link to this topic in the body of the return ticket.
https://www.sparkfun.com/returns
#205170
I encountered the same problem as TNichols found. Selecting Nordic nRF52840DK (PCA 10056) is a temporary workaround solution to get my serial and led to work. It would be a problem if I needed to use the resources listed below. Update fixes are needed. Thank you.

(This list shows what makes Sparkfun board different from Nordic nRF52840DK (PCA 10056) board. So, it seems to be important for the community to get an update soon.)
Hardware Serial (Serial1) to pins 17 (TX) and 15 (RX) to match the Arduino Pro Mini pinout
I2C to pins to 8 (SDA) and 11 (SCL). Important if you're using the qwiic connector.
SPI to pins 31 (MISO), 3 (MOSI), 30 (SCK) – again matches the Arduino Pro Mini pinout.
Built-in LED (LED_BUILTIN) to pin 7
#205356
I need a copy of the bootloader asap. This must already exist for manufacturing. I recently corrupted my bootloader - I was trying to hack a way to load the SoftDevice S340 for ANT+.

I have now bought a Nodrdic Semiconductor nRF52840 DK and a SEGGER J-LINK to help unbrick my Sparkfun board (This isn’t the first time that I wished I had a J-LINK). What was a low cost bluetooth development system is now significantly more expensive!

Jack