Flashing nRF52840 results in "Device Busy" after SoftDevice is flashed

[msebas]

Hello,

I have a nRF52840 and am unable to flash an application to it. I am trying to flash the "examples/ble_peripheral/ble_app_blinky/hex/ble_app_blinky_pca10059_s140.hex" file of the nRF5 SDK 17.0.2, after trying to flash various other applications. Strangely it is possible to flash the device using applications without a soft device like the nRF BLE Sniffer file sniffer_nrf52840dongle_nrf52840_4.0.0.hex.

The os is an openSUSE Leap 15.2 linux with a 5.3.18-lp152.87-default kernel.

On top if trying to flash "ble_app_blinky_pca10059_s140.hex" after the Error it shows the SoftDevice Section as required (see screenshot), even if there was a application without SoftDevice present on the device. So it seems like at least a part get flashed as requested.

Is there any suggestion where I would be able to continue looking for the error?

Below is the log and a screenshot of the programmer after the error occured.

Kind regards and thanks.

The relevant log:

23:21:21.637

Using USB SDFU protocol to communicate with target

23:21:21.641

Protocol Version: 1 found

23:21:21.641

Hardware: 52840 found

23:21:21.643

Firmware: Bootloader found

23:21:21.643

Firmware: SoftDevice found

23:21:21.646

SoftDevice detected, id 0x100 (S140 v7.2.0)

23:21:24.922

Does not need to be reloaded: /home/Sebastian/workspace/Arduino/nRF_SDK/DeviceDownload/nRF5_SDK_17.0.2_d674dde/examples/ble_peripheral/ble_app_blinky/hex/ble_app_blinky_pca10059_s140.hex

23:21:24.923

SdReq for SoftDevice is set as 0x00.

23:21:24.924

Hash is generated by SHA256

23:21:24.924

Hash is generated by SHA256

23:21:24.926

Performing DFU. This may take a few seconds

23:21:24.931

DFU procedure starts. This may take a few seconds.

23:21:33.312

DFU for SoftDevice completed successfully!

23:21:33.312

1 dfu package(s) left.

23:21:33.312

Waiting for device

23:21:33.411

DFU procedure starts. This may take a few seconds.

23:21:33.511

DFU failed: Error: Das Gerät oder die Ressource ist belegt, cannot open /dev/ttyACM0

23:21:33.513

Device not found due to failure during DFU

A Screenshot

[Amanda Hsieh]

Hi, 

The examples/ble_peripheral/ble_app_blinky/hex/ble_app_blinky_pca10059_s140.hex combines with Softdevice as the log indicates SoftDevice detected, id 0x103 (S112 v7.2.0). 

The device will reset when the upgrade completes and the dongle will no longer show up in nRF Connect unless the application used DFU Trigger Library is used, as it is no longer in DFU mode. You will get an error stating "Reopen device failed" in this case, and have to push the RESET button in order to make it show up in nRF Connect Programmer again.

You can use nRF Connect mobile app to check the device advertise "Nordic_Blinky" or not.  

Regards,
Amanda

[msebas]

Hello,

please excuse the long response time. I was quite busy with something else and the problem was much more complicated than expected.

Amanda Hsieh Thank you very much for the answer, it gave me the necessary hint: The device resets itself 2 time, once after the softdevice flash and once after the flash of the application.

For anyone who has a similar error:

The error was that the reset of the device after the flush of the softdevice triggered a third application (in my case ModemManager) to open the serial device-file /dev/ttyACM0 and block it for a few seconds. During that time the device was busy, so nRF Connect was unable to open it to flash the application to the device, resulting in the error message given above.

How to check for this and how to find out which application is blocking nRF Connect from opening the serial device:

Run in your bash the following code (you need inotify-tools installed and working, I did run it as root):

while true
do 
until inotifywait -q -e access -e modify -e open -e close /dev | grep ttyACM; do true; done
lsof /dev/ttyACM* 2>/dev/null
done

It outputs something like (after you tried to flash an application with softdevice)

/dev/ ACCESS ttyACM1
COMMAND     PID      USER   FD   TYPE DEVICE SIZE/OFF     NODE NAME
nrfconnec 24114 Sebastian   57uW  CHR  166,1      0t0 20117517 /dev/ttyACM1
/dev/ ACCESS ttyACM1
COMMAND     PID      USER   FD   TYPE DEVICE SIZE/OFF     NODE NAME
nrfconnec 24114 Sebastian   57uW  CHR  166,1      0t0 20117517 /dev/ttyACM1
/dev/ ACCESS ttyACM1
.......................
/dev/ ACCESS ttyACM1
COMMAND     PID      USER   FD   TYPE DEVICE SIZE/OFF     NODE NAME
nrfconnec 24114 Sebastian   57uW  CHR  166,1      0t0 20117517 /dev/ttyACM1
/dev/ ACCESS ttyACM1
/dev/ OPEN ttyACM1
COMMAND    PID USER   FD   TYPE DEVICE SIZE/OFF     NODE NAME
ModemMana 2668 root    9u   CHR  166,1      0t0 20118427 /dev/ttyACM1
/dev/ MODIFY ttyACM1
COMMAND    PID USER   FD   TYPE DEVICE SIZE/OFF     NODE NAME
ModemMana 2668 root    9u   CHR  166,1      0t0 20118427 /dev/ttyACM1
/dev/ MODIFY ttyACM1
COMMAND    PID USER   FD   TYPE DEVICE SIZE/OFF     NODE NAME
ModemMana 2668 root    9u   CHR  166,1      0t0 20118427 /dev/ttyACM1
/dev/ CLOSE_WRITE,CLOSE ttyACM1
COMMAND    PID USER   FD   TYPE DEVICE SIZE/OFF     NODE NAME
ModemMana 2668 root    9u   CHR  166,1      0t0 20118427 /dev/ttyACM1
/dev/ MODIFY ttyACM1
COMMAND    PID USER   FD   TYPE DEVICE SIZE/OFF     NODE NAME
ModemMana 2668 root    9u   CHR  166,1      0t0 20118427 /dev/ttyACM1
/dev/ CLOSE_WRITE,CLOSE ttyACM1

telling you which process is bulling the poor nRF Connect by stealing the serial device. After that it was simple. Stop the corresponding service and anything is fine...

Hope this helps someone, it took me quite some time to figure out what exactly was happening.