Bristlemouth double flashing red

Dev Kit Support
1

Hi,

Currently, the dev kit I’m working on is flashing red on both LEDs every couple of seconds. I achieved this by flashing what I would assume to be bad code via the bridge dfu command from the spotter buoy. Now, if I try to access the dev kit via the serial console I will get something along the lines of this -

INA232 Init
Retries remaining 2
MFG_ID: 5449
INA232 Init
Retries remaining 2
MFG_ID: 5449
Subscribing to Topic: spotter/utc-time
Exception in thread rx:
Traceback (most recent call last):
  File "C:\Program Files\WindowsApps\PythonSoftwareFoundation.Python.3.10_3.10.3056.0_x64__qbz5n2kfra8p0\lib\threading.py", line 1016, in _bootstrap_inner
    self.run()
  File "C:\Program Files\WindowsApps\PythonSoftwareFoundation.Python.3.10_3.10.3056.0_x64__qbz5n2kfra8p0\lib\threading.py", line 953, in run
    self._target(*self._args, **self._kwargs)
  File "C:\Users\mngre\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.10_qbz5n2kfra8p0\LocalCache\local-packages\Python310\site-packages\serial\tools\miniterm.py", line 499, in reader
    data = self.serial.read(self.serial.in_waiting or 1)
  File "C:\Users\mngre\AppData\Local\Packages\PythonSoftwareFoundation.Python.3.10_qbz5n2kfra8p0\LocalCache\local-packages\Python310\site-packages\serial\serialwin32.py", line 259, in in_waiting
    raise SerialException("ClearCommError failed ({!r})".format(ctypes.WinError()))
serial.serialutil.SerialException: ClearCommError failed (PermissionError(13, 'The device does not recognize the command.', None, 22))

Worth noting - this snapshot was grabbed via a windows machine, when trying to access it from a linux machine I would get something similar. I can share that as well.

If I were to plug the dev kit into the buoy and access the buoy console I would get something like this

178680t [BRIDGE_SYS] [INFO] Neighbor 29693d193822e7aa added
210653t [BRIDGE_SYS] [INFO] Neighbor 29693d193822e7aa added
219789t [BRIDGE_SYS] [INFO] Neighbor 29693d193822e7aa added

the 296- number is the dev kit’s node id.

If I were to try and utilize the bridge function again from the buoy (using a working binary) I would get this

File transferred, entering update phase.
Opening bm_mote_v0.5-serial_payload_guide-dbg.elf.dfu.bin
Node 29693d193822e7aa update status: 0, 6
Update finished: 29693d193822e7aa success: 0 err:6
Transitioning to state: idle

I’m not sure what the double flashing red is indicative of. The plan is to order the STLINK debugger alongside the tag connect piece to hopefully recover the mote.

I was wondering if anyone had any insight on what my issue might be and if this is a good way to approach it.

Henry

2

Hi @henry !

You are going down the right track by ordering an STLINK. The double red flashing sounds to me like the mote is stuck in a boot loop. Was the firmware that you flashed on to the device custom firmware? Or was it the firmware from the user guide?

You can try to serial into the device and quickly typing/copy-pasting in a bootloader command. If successful, you should be able to use dfu-util to update the device. You can use dfu-util -l to check if the device is available for a dfu-util update.

With the STLINK you will be able to flash the device as long as it is powered, so no need to serial in.

Best,
Victor

3

Hi Victor, thanks for the response!

I’m not having any luck sneaking in a bootloader message before it crashes, so I will wait on the STLINK.

As for the firmware, it was a very modified version of the user guide.

Thanks!
Henry

4

Hi @henry,

There’s one more way to get your dev kit into bootloader mode even if you can’t send the serial command: you hold the BOOT pin high at 3.3V when the device boots.

Our latest dev kits have buttons on the rectangular Bristlefin expander board to make this easier. If you’re lucky enough to have one of those, then hold down the boot button, tap the reset button, and the device should appear in dfu-util -l resutls.

I’m guessing that your Bristlefin doesn’t have buttons though. If that’s true, then you can remove the mote from the expander board to access the boot pin on TP33, on the same side of the board as the USB connector. If you can manage to supply 3.3V to TP33 while the device resets, then you should see it in bootloader mode. Otherwise, of course, that STLINK is on its way.

Cheers!
Zachary

5

Hi Zachary,

You were correct in guessing that I have a button-less mote. Fortunately, sending 3.3v to TP33 to put it in bootloader mode worked and I was able to flash new firmware. Thank you for your guidance!

Thank you!
Henry

2 Likes