Success: 0 err:6

I’m trying to build and flash the hello_world application to a Bristlemouth Dev Kit using DFU, but running into issues during both the CMake configuration step and the DFU flashing process. Here’s a breakdown of what I’ve done and where I’m stuck.
System Info:

  • Host OS: Windows with WSL (Ubuntu)
  • DFU Utility: dfu-util 0.11
  • Device detected correctly:
  • Found DFU: [0483:df11] … name=“@Internal Flash” …
    Serial=“205F38754D30”
  • DFU Issue:
    I’m using this command
    ''bridge dfu v0.11.1_hello_world_RED.elf.dfu.bin 3b9294c112b32c9d 120000 force''
    Note: the range I tried was 120000- 240000 force- error still kept on appearing

Build Issue:

To build the firmware, I followed this process:

cd bm_protocol
mkdir -p cmake-build/hello_world
cd cmake-build/hello_world
cmake ../../applications/hello_world

But I get this error:

CMake Error: The source directory "/home/vera/bm_protocol/applications/hello_world" does not exist.

Main Questions:

  1. Where is the actual source directory for the hello_world application supposed to be?
    Is it possible the applications/hello_world directory wasn’t cloned properly as part of a submodule?
  2. How do I ensure the Node is “online” and accepting DFU updates during flashing?
    I suspect the Node may not be in the correct mode for DFU even though it shows up in dfu-util --list.

Any help is appreciated!

Ah interesting… okay so let’s try:

For #1 – Usually if I’ve not been doing much for a while or if I want to confirm I’m working on the right version I run

git checkout v0.6.0 < or whatever version I’m targeting (usually just use whatever the guide is tagged as at the top)

Then:

git submodule update --init

Then:

conda env update -f environment.yml

You could also try deleting the cmake-build folder for your application and retrying these steps.

For #2:

As far as I know, running dfu-util --list and seeing the Found DFU… is the way to make sure the mote is in bootloader mode and recognized by dfu-util.

If neither of these suggestions help:

Hey there could be a few things going on. First question – are you on Guide 4, “Testing your…” step #6?

If so can you please post in a screenshot of your session starting with the the mkdir step (you’ll need to delete the original folder or create a new one).

Thanks so much good luck~
Z

Regarding question 1, Guide 4 under the heading “Testing the dev environment”, step 6, lists this cmake command:

cmake ../.. -DCMAKE_TOOLCHAIN_FILE=../../cmake/arm-none-eabi-gcc.cmake -DBSP=bm_mote_v1.0 -DCMAKE_BUILD_TYPE=Debug -DCMAKE_APP_TYPE=BMDK -DAPP=hello_world -G "Unix Makefiles"

The path in the cmake command is simply the root of the repo ../.. but the APP cache entry is hello_world. Hope that helps!

Regarding question 2, I totally concur with Zack J — use dfu-util --list to check.

1 Like

Version v0.11.1 of the bm_protocol repo on Linux. I’ve set up my conda environment and successfully built the hello_world app.

Manually flashing the .dfu.bin file using the bridge dfu command results in
sql

Update finished: 3 success: 0 err:6

However, I still encounter these issues:
Running make dfu_flash in cmake-build/hello_world fails with

make: *** No rule to make target 'dfu_flash'. Stop.
(bristlemouth) vera@LAPTOP-K8ER7VMC:~/bm_protocol$ dfu-util --list
dfu-util 0.11

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2021 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

Found DFU: [0483:df11] ver=0200, devnum=8, cfg=1, intf=0, path="1-1", alt=2, name="@OTP Memory   /0x0BFA0000/01*512 e", serial="205F38754D30"
Found DFU: [0483:df11] ver=0200, devnum=8, cfg=1, intf=0, path="1-1", alt=1, name="@Option Bytes   /0x40022040/01*64 e", serial="205F38754D30"
Found DFU: [0483:df11] ver=0200, devnum=8, cfg=1, intf=0, path="1-1", alt=0, name="@Internal Flash   /0x08000000/256*08Kg", serial="205F38754D30"
cd ~/code/bm_protocol - make sure that Conda is activated.

Used: “”'conda env update -f environment.yml

Output when checking what is inside the folder:

(bristlemouth) vera@LAPTOP-K8ER7VMC:~/code/bm_protocol$ ls
BuildOptions.cmake  ENV_SETUP.md  cmake        environment.yml     img_1.png  test
CMakeLists.txt      LICENSE       cmake-build  environment_ci.yml  img_2.png  tools
DEVELOPER.md        README.md     docs         img.png             src
(bristlemouth) vera@LAPTOP-K8ER7VMC:~/code/bm_protocol$

Now we are going to remove the CMake file to see if that was the problem

Following Guide 4:

(bristlemouth) vera@LAPTOP-K8ER7VMC:~$ cd ~/code
(bristlemouth) vera@LAPTOP-K8ER7VMC:~/code$ git clone  https://github.com/bristlemouth/bm_protocol.git
fatal: destination path 'bm_protocol' already exists and is not an empty directory.
(bristlemouth) vera@LAPTOP-K8ER7VMC:~/code$ cd bm_protocol
(bristlemouth) vera@LAPTOP-K8ER7VMC:~/code/bm_protocol$ git checkout v0.11.1
M       src/third_party/lwip
HEAD is now at 595e774 chore: update bm_serial submodule to v0.11.1 (#150)
(bristlemouth) vera@LAPTOP-K8ER7VMC:~/code/bm_protocol$ git submodule update --init

Setting up the dev environment

Well I changed the environment

conda create -n bristlemouth
WARNING: A conda environment already exists at '/home/vera/miniconda3/envs/bristlemouth'
Remove existing environment?
This will remove ALL directories contained within this specified prefix directory, including any other conda environments.
 (y/[n])? y
Channels:
 - defaults
Platform: linux-64
Collecting package metadata (repodata.json): done
Solving environment: done

Package Plan

environment location: /home/vera/miniconda3/envs/bristlemouth
Proceed ([y]/n)? y
Downloading and Extracting Packages:
Preparing transaction: done
Verifying transaction: done
Executing transaction: done

To activate this environment, use

$ conda activate bristlemouth

To deactivate an active environment, use

$ conda deactivate

I honestly believe it was building in the wrong environment:

To activate this environment, use

$ conda activate /home/vera/miniconda3/envs/bristlemouth

This was not what the guide was telling me to have, I will see if the rest will work.

(bristlemouth) vera@LAPTOP-K8ER7VMC:~/code/bm_protocol$ git submodule update --init
(bristlemouth) vera@LAPTOP-K8ER7VMC:~/code/bm_protocol$ mkdir cmake-build
(bristlemouth) vera@LAPTOP-K8ER7VMC:~/code/bm_protocol$ cd cmake-build
(bristlemouth) vera@LAPTOP-K8ER7VMC:~/code/bm_protocol/cmake-build$ mkdir hello_world
(bristlemouth) vera@LAPTOP-K8ER7VMC:~/code/bm_protocol/cmake-build$ cd hello_world
(bristlemouth) vera@LAPTOP-K8ER7VMC:~/code/bm_protocol/cmake-build/hello_world$ cmake ../.. -DCMAKE_TOOLCHAIN_FILE=../../cmake/arm-none-eabi-gcc.cmake -DBSP=bm_mote_v1.0 -DCMAKE_BUILD_TYPE=Debug -DCMAKE_APP_TYPE=BMDK -DAPP=hello_world -G "Unix Makefiles"

That outcome matches the guide: Build files have been written to:

/home/vera/code/bm_protocol/cmake-build/hello_world
/home/vera/miniconda3/envs/bristlemouth/arm-none-eabi-gcc/bin/../lib/gcc/arm-none-eabi/13.2.1/../../../../arm-none-eabi/bin/ld: warning: bm_mote_v1.0-hello_world-dbg.elf has a LOAD segment with RWX permissions
   text    data     bss     dec     hex filename
 227056    1872  456878  685806   a76ee bm_mote_v1.0-hello_world-dbg.elf
Creating MCUBoot image
[100%] Built target bm_mote_v1.0-hello_world-dbg.elf

Going back to Guide 3 to see if problem is fixed:

Following steps
Information from Spotter:
v0.11.1_hello_world_RED.elf.dfu.bin

Information from Dev kit:
Node ID: 3b9294c112b32c9d

bridge dfu v0.11.1_hello_world_RED.elf.dfu.bin 3b9294c112b32c9d 120000 force
Didn’t work:

Node 3 update status: 0, 6
Update finished: 3 success: 0 err:6
Transitioning to state: idle

Updates over USB DFU
After running bootloader
Traceback (most recent call last):

File "/home/vera/miniconda3/lib/python3.13/threading.py", line 1041, in _bootstrap_inner
  self.run()
  ~~~~~~~~^^
File "/home/vera/miniconda3/lib/python3.13/threading.py", line 992, in run
  self._target(*self._args, **self._kwargs)
  ~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/vera/miniconda3/lib/python3.13/site-packages/serial/tools/miniterm.py", line 499, in reader
  data = self.serial.read(self.serial.in_waiting or 1)
File "/home/vera/miniconda3/lib/python3.13/site-packages/serial/serialposix.py", line 595, in read
  raise SerialException(
      'device reports readiness to read but returned no data '
      '(device disconnected or multiple access on port?)')
serial.serialutil.SerialException: device reports readiness to read but returned no data (device disconnected or multiple access on port?)
# Verify if the processor was successfully placed in DFU bootloader
(base) vera@LAPTOP-K8ER7VMC:~/bm_protocol$ dfu-util --list
dfu-util 0.11

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2021 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

Found DFU: [0483:df11] ver=0200, devnum=11, cfg=1, intf=0, path="1-1", alt=2, name="@OTP Memory   /0x0BFA0000/01*512 e", serial="205F38754D30"
Found DFU: [0483:df11] ver=0200, devnum=11, cfg=1, intf=0, path="1-1", alt=1, name="@Option Bytes   /0x40022040/01*64 e", serial="205F38754D30"
Found DFU: [0483:df11] ver=0200, devnum=11, cfg=1, intf=0, path="1-1", alt=0, name="@Internal Flash   /0x08000000/256*08Kg", serial="205F38754D30"

From your application’s build directory, build with the make dfu_flash command. This will build and then flash using USB DFU, which will take a couple of minutes.

vera@LAPTOP-K8ER7VMC:~/bm_protocol$ cd cmake-build
(base) vera@LAPTOP-K8ER7VMC:~/bm_protocol/cmake-build$  cd hello_world
(base) vera@LAPTOP-K8ER7VMC:~/bm_protocol/cmake-build/hello_world$ make dfu_flash
make: *** No rule to make target 'dfu_flash'.  Stop.

Outcome: make: *** No rule to make target ‘dfu_flash’. Stop.

I tried it with:

(bristlemouth) vera@LAPTOP-K8ER7VMC:~/code/bm_protocol/cmake-build/hello_world

(bristlemouth) vera@LAPTOP-K8ER7VMC:~/code/bm_protocol/cmake-build/hello_world$  make dfu_flash
[ 25%] Built target lwipcore
[ 25%] Built target linkerscript
[ 25%] Generating version.c, _version.c, version_string
-- git version: v0.11.1-dirty
[ 25%] Building C object src/CMakeFiles/bm_mote_v1.0-hello_world-dbg.elf.dir/version.c.obj
[ 25%] Linking CXX executable bm_mote_v1.0-hello_world-dbg.elf
/home/vera/miniconda3/envs/bristlemouth/arm-none-eabi-gcc/bin/../lib/gcc/arm-none-eabi/13.2.1/../../../../arm-none-eabi/bin/ld: warning: bm_mote_v1.0-hello_world-dbg.elf has a LOAD segment with RWX permissions
   text    data     bss     dec     hex filename
 227056    1872  456878  685806   a76ee bm_mote_v1.0-hello_world-dbg.elf
Creating MCUBoot image
[100%] Built target bm_mote_v1.0-hello_world-dbg.elf
dfu-util 0.11

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2021 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

dfu-util: Warning: Invalid DFU suffix signature
dfu-util: A valid DFU suffix will be required in a future dfu-util release
dfu-util: No DFU capable USB device available
[100%] Built target dfu_flash

From what the guide has mentioned:

If your Dev Kit processor is not in DFU bootloader mode and connected to your computer, you will still see [100%] Built target dfu_flash at the end of the script, but will not see the Erase and Download progress bars

That is what happened^

I tried to continue the guide but no luck.

(bristlemouth) vera@LAPTOP-K8ER7VMC:~/code/bm_protocol/cmake-build/hello_world$ dfu-util -d 0483:df11 -a 0 -s
 0x08000000:leave -D PATH/TO/YOUR_APP.elf.unified.bin
dfu-util 0.11

Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2021 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/

dfu-util: Could not open file PATH/TO/YOUR_APP.elf.unified.bin for reading: No such file or directory
``

Hello @Everardo !

err: 6 tells me that the update is timing out. This can happen when going from <=v0.9.0 to >=v0.10.0. There is a breaking change between v0.9.0 and v0.10.0 that requires a few additional steps to make sure the update successfully completes, otherwise a final ACK will never be recieved and we will get the timeout error.

What version is your Dev kit board currently on? You can find this out by connecting to the devkits usb, opening a terminal and using pyserial-miniterm (or other similar interface such as putty) to type info to the devkit. There will be some version information printed out that will tell you what version the board is currently on.

If you are on v0.9.0(or earlier versions) then I can provide additional steps to updating through the BM ecosystem. Alternatively, you can continue using the dfu-util or make dfu_flash method for updating.

It looks like right here Success: 0 err:6 - #4 by Everardo that the make dfu_flash command worked! However, the device was not in its bootloader. If the device is put into bootloader and it is then reset, it will exit the bootloader and needs to be put back into it. So I would suggest trying this again.

If that still doesn’t work then, here Success: 0 err:6 - #4 by Everardo, it looks like you were again very close. You just need to change PATH/TO/YOUR_APP to the actual path to the .unified.bin. It looks like for you that would be something like: ~/code/bm_protocol/cmake-build/hello_world/src/bm_mote_v1.0-hello_world-dbg.elf.unified.bin. Again the dev kit needs to be put into bootloader before running this command and it cannot be reset between being put into bootloader and running the dfu-util command.

Hope this helps and let us know if you have any more questions!

Best,
Victor

1 Like

Hey Victor, thank you for your response! I did up just changing my path, and everything else went smoothly.

1 Like