Bristlemouth Mote Not Recognized – Seeking Advice

Application Dev
1

Hey everyone,

I’ve been working with the Bristlemouth Dev Kit and recently received a second Bristlemouth Mote. Both are PCBA-000625-AD BM Mote v1.3.

I tested my code on the original mote, then removed it from the dev board to test the new one. Initially, I was able to upload the hello world code, but now:

  • No LEDs are flashing on the second mote.
  • It is not recognized by my computer.
  • It does not appear in lsusb or dfu-util --list when trying to enter DFU mode.

I verified my setup by testing the original mote, which still works fine and is detected normally. The USB cable and power source are also confirmed to be working.

Has anyone encountered a similar issue? Any suggestions on how to troubleshoot or recover the second mote? Appreciate any advice!

Thanks!

2

Hi @jaszylu, sorry you’re having that issue.

It sounds to me like when you flashed the new mote, something went wrong, and now the flash on the microcontroller doesn’t have a working application.

You can put even a completely blank STM32 from the factory into dfu-util mode by holding the BOOT pin high during power-up or reset. On the devkit breakout board you have, there should be BOOT and RESET buttons. You can hold down the BOOT button while you tap reset, and then the MCU should be in DFU mode, where you can use dfu-util.

When flashing with dfu-util in this state, you MUST use a “.unified.bin” — which has the MCUBoot bootloader placed at the base of flash, and then your application placed at a later address, all wrapped into one binary file.

You can download hello_world_debug-v0.12.2 from here, which will contain a unified binary with a development bootloader:

After that you can flash whatever you want over the application, but you need to make sure you don’t erase the MCUBoot bootlaoder.

If you’re building your own firmware, then make sure USE_BOOTLOADER=1 is part of your cmake cache entries. Without this flag, your app gets programmed at the base of flash, overwriting the bootloader, and generally not behaving as expected.

Assuming you are building with that cache entry, then make dfu_flash should do the right thing in your build folder.

If you’re using dfu-util directly, be sure the address you’re programming your .elf.dfu.bin file to is 0x0800C000 as seen here: bm_protocol/src/CMakeLists.txt at 51c4260af60afd2b30a1101e1383c820fab10617 · bristlemouth/bm_protocol · GitHub

Happy hacking!
Zachary

3

I tried to hold the boot button and rest during power up on different attempts and held boot while tapping rest and it is still not being recognized under the dfu-util list

4

One thing to try — please try the USB-C connection to the mote in both orientations. USB cables have many small variations that are poorly documented, and with certain cables, one orientation holds the mote in reset, while the other orientation works correctly.

5

Hello, I am a member of this project along with Jack. We have explored every possible variation in hardware setups for this mote and have thoroughly verified that these configurations function correctly on the original mote. Given this, I do not believe the issue lies with the hardware setup.

Please let me know if you have any other insights or suggestions.

6

Our best guess is that you’ve accidentally zapped the mote with a momentary wire to some unprotected spot on the board.

  • You told us that the motes are PCBA-000625-AD BM Mote v1.3. What revision is the orange, rectangular Bristlemouth Development Board?
  • When you power the mote using the 24V wall wart, is the processor next to the Bristlemouth logo hot to the touch?