I had the same error with the ‘v0.11.1_hello_world_RED.elf.dfu.bin’ in section 3. I don’t know that it’s the same problem, but I downloaded and was able to update the mote with ‘bm_mote_v1.0-hello_world.elf.dfu.bin’ found on the forum.
According to the documentation error 8 can be caused by trying to update before the spotter has initilized, but I don’t think this is my problem.
I assume your computer is connected with a USB cable to Spotter, not the dev kit. Correct?
What’s the full bridge dfu command you’re issuing?
What output do each of the following 3 Spotter commands give?
bm topo
bm info 0
ls
Additionally the full console output starting from boot up until a little past the error would be helpful. You could paste it at https://gist.github.com/ or a similar site and then put a link to the gist in a comment here.
Error 8 is “aborted” which can have various causes. The full list of errors is here in bm_dfu.h in case it’s helpful context.
Share some of that, and we’ll be better able to help.
I see in your original comment that you’re trying to program recent firmware, v0.11.1. That version is incompatible with what your bridge is currently running, which is reported as v0.4.0 in the gist.
As of v0.11.0 there was a breaking change with any versions before. You can learn more about that in the release notes.
In order to put v0.11.1 on your dev kit and have it work, you’ll first need to update your bridge. Once that’s successfully updated, you’ll need to update your Spotter firmware.
The clearest instructions I can offer for that are in the CircuitPython guide — just follow steps one and two to update the Bridge and Spotter, and then ignore the rest.
I did find that information about error 8 so was careful about giving it at least two minutes to initialize. I don’t think that’s the problem that I’m having, but I do have a question about the initialization.
Unless it needs to reboot or some other unusual situation, does the initialization happen when I first power the spotter or when I open a serial connection to the spotter or both?
@kucewicz the initialization happens whenever the Bridge processor (essentially a Bristlemouth Mote inside of the Spotter) reboots. This will happen when Spotter powers on or resets, but there are a few other slim cases where the Bridge will reset independently. (Not having to worry about this constraint anymore is one of the many good reasons to update to v0.11).
Do you have access to the USB port of the module you’re updating? The simplest approach is to:
Separately update the Spotter Bridge and Main processors per the instructions @zachary linked to in the previous post.
Coincidentally, we’re putting the final touches on a “bootstrapping” (how to successfully update an entire system across incompatible BM protocol versions) guide as we speak, and we’ll be publishing that next week.
If you don’t have direct access to your Dev Kit / Module’s Mote USB port, the details in this upcoming guide will explain how to do this. It’s a cumbersome process in v0, but it is doable and definitely worth it to get all the latest improvements in v0.11.
I have updated the bridge firmware, but now I am having problems updating the Spotter firmware. If it matters, I am running MacOS Monterey, version 12.6.5 on a Dual-Core Intel I7.
When I run ‘spotter-flash-upload’, this is what the opened terminal shows. I have checked by running ‘pip list’ that pyserial v3.5 in installed.
Last login: Mon Aug 12 13:34:18 on ttys001
The default interactive shell is now zsh.
To update your account to use zsh, please run chsh -s /bin/zsh.
We just discovered this issue with the intel mac installer the other day. We’ve found and fixed the issue for future builds. I’ll post a fixed installer for v2.15.1 today or tomorrow and link to it from this topic. Sorry you got bit by that.
I went through the process of updating the spotter and the bridge, but I think I did something wrong because I’m having a lot of problems right now. I’m wondering if I used the id of the spotter rather than the id of bridge when updating the bridge.
If I understand ‘bridge test’ properly, it’s telling me its id is the same as the spotter.
When I run ‘bm topo’ on the mote, I get:
(root)4e768373dd4f80aa
When I run ‘bm topo’ on the spotter, I get:
Bristlemouth toplogy: e6efd2fed740cfb9
When I run ‘bridge test’ on the spotter, I get:
2024-08-14T22:04:42.406Z [BRIDGE] [INFO] Requesting self test
2024-08-14T22:04:42.406Z [BRIDGE] [DEBUG] Self test attempts remaining: 3
2024-08-14T22:04:42.406Z [BRIDGE] [DEBUG] Self test request sent
2024-08-14T22:04:42.414Z [BRIDGE] [INFO] Self test result from e6efd2fed740cfb9 - 1
2024-08-14T22:04:42.414Z [BRIDGE] [INFO] Self test successful
The bridge is a circuit board inside the Spotter hull that functions as Spotter’s Bristlemouth node. The bridge firmware is Bristlemouth firmware, and it has a node ID. Spotter, as a product does a bunch of non-Bristlemouth things, and the main circuit board for those purposes does not have a Bristlemouth node ID. When you run bm topo from Spotter, it basically proxies that message to the bridge. Make sense?
So while you may be having other problems, everything you describe in that last message is 100% expected.
So first, your Spotter is updated to v2.15.1 and your Bridge is updated to v0.11.1. Congrats! Now for the other node, the log says error 12 which is unknown node ID. In this case, I’m pretty sure that means it’s on some version before the breaking change in v0.11.0.
If you have access to the USB port of the module, then updating that way (rather than using the SD card) will by far be the easiest thing. After you do this once, then the SD card method will work fine for future updates.
If you don’t have access to the USB port, then it’s still doable, but you’ll have to downgrade Spotter and Bridge, set a configuration on the module, get it upgraded, then when it disappears from the network, you can update Spotter and Bridge. This is all explained in more detail in the firmware management guide that we’re releasing next week.
You’re talking about the USB connection on the Development Board, correct? If so, I do have access that.
I’ll try you’re suggestion tomorrow. I’ve been reluctant to try USB DFU for fear of bricking the mote, but my board version is new enough that it shouldn’t be an issue.
The work is partly done. I’m working with the rest of the team to get links updated in all the places… Even though you don’t need it anymore, I will still notify this topic when the fixed installers are posted.
The USB DFU worked, but now I’m having a different problem. Everything seems fine for a few minutes, and then the mote stops working. Zack Johnson was just here. I didn’t want to spend our time troubleshooting, but he thought it might have to do with the spotter’s power management.
Here’s the spotter’s console when it stops:
2024-08-15T20:42:15.859Z [BRIDGE_SYS] [INFO] Sample enabled 1
Sample Duration: 310 s
Sample Interval: 1800 s
Subsample enabled: 0
Subsample Duration: 30 s
Subsample Interval: 60 s
Alignment Interval: 300 s
2024-08-15T20:42:15.863Z [BRIDGE_SYS] [INFO] Using RTC timebase
2024-08-15T20:42:15.871Z [BRIDGE_SYS] [INFO] Bridge State Init Complete
2024-08-15T20:42:15.875Z [BRIDGE_SYS] [INFO] Bridge bus power: 0
2024-08-15T20:42:15.882Z [BRIDGE_SYS] [INFO] Controller task will wait 1065000 ms
2024-08-15T20:42:26.785Z [BRIDGE_SYS] [INFO] Neighbor 4e768373dd4f80aa lost
Here’s the mote’s console with it stops:
bm port0 down
— exit —
Exception in thread rx:
Traceback (most recent call last):
File “/Users/John/miniconda3/envs/bristlemouth/lib/python3.10/site-packages/serial/serialposix.py”, line 575, in read
buf = os.read(self.fd, size - len(read))
OSError: [Errno 6] Device not configured
Great. Yes, that’s all expected, and you can change the behavior to keep the mote always powered on.
In a real deployment environment, we have to be frugal with our power budget, so the bridge has a power controller that manages sampling cadences. However, when we’re developing in the lab, it’s annoying to have the mote suddenly powered off.
In the Spotter console, your log indicates a 310 second sample starting every 30 minutes (1800 seconds). You configure the power controller using a few configurations on the system partition of the bridge.
If you want to keep the mote always powered on, issue these 2 commands in the spotter USB console:
bm cfg set 0 s u bridgePowerControllerEnabled 0
bm cfg commit 0 s
You can find these commands in the RS232 Sensor Guide, and you can find more about configuring the specific timing for deployment in Guide 5. Just search either page for “bridgePowerController”.
We just discovered this issue with the intel mac installer the other day. We’ve found and fixed the issue for future builds. I’ll post a fixed installer for v2.15.1 today or tomorrow and link to it from this topic. Sorry you got bit by that.
With a little luck, it’ll all be smooth sailing from tomorrow!