Dev kit not transmitting data from SAMI after firmware updates

Dev Kit Support
1

Two of our Spotters were brought in from the field when their batteries failed. After swapping for new batteries, I updated all components of our systems (dev kits, bm soft module (temp sensor), bridge processor, and the main processor) to the latest firmware versions. We were operating on v2.15.1 for the Spotters so I did the upgrade to v2.15.6 and then v2.16.6.

Current versions are now:

  • Spotters: v2.16.6
  • Bridge: v0.13.10
  • BM Soft Modules: v0.13.10
  • Dev Kits: v0.13.10

Old versions were:

  • Spotters: v2.15.1
  • Bridge: v0.11.0
  • BM Soft Modules: v0.11.0
  • Dev Kits: v0.11.1

After performing all of these updates, I was testing the communication and data transmission of the systems outside with our SAMI pH sensors connected to the dev kits. The dev kits are off most of the time and will power on at the top of the hour for this data transmission, but none of the data from the SAMIs are actually being sent to the Spotters. I also checked the SD cards and there is no SAMI data on them.

I wondered if the custom firmware my predecessor wrote to have the SAMIs and Spotters communicate back in 2024 was somehow wiped from the system when I updated so I attempted to reflash this firmware onto the dev kit. I used:

bridge dfu 26_bm_mote_v1.0-hello_sami-dbg.elf.dfu.bin 0x2ce93224b4048d4a 120000 force

When I did this, it returned:

Update finished: 4aec48a5888e3977 success: 0 err:8

According to the guides, “If you see Update finished: 4aec48a5888e3977 success: 0 err:8**,** that means the DFU transaction was intentionally aborted. The most likely reason this happened is that you attempted the update onto a module that requires a signed image.”

So I have a few questions.

  1. Why is the SAMI data not being transmitted to the Spotter after the updates?
  2. Is reflashing the dev kit necessary? Or is the lack of transmission caused by something else?
  3. If reflashing is necessary, why am I getting err: 8 and how do I fix this?

Any help would be appreciated!

2

The errors that can result from a DFU are defined in the bm_core repo in bcmp/dfu.h.

In that list, the first item is number zero, and they count up from there. Error 8 is BmDfuErrAborted. When I look through the DFU code, the most likely reason I can see for an abort is that the maximum number of retries was exceeded. Have you tried the bridge dfu command again? There’s no harm in trying a few times.

Also I notice that in your bridge dfu command the node ID is 0x2ce93224b4048d4a, but in the “Update finished” log line you give node id 4aec48a5888e3977 which is the same one you quote from the guide. So I’m guessing 2ce93224b4048d4a is correct.

To diagnose whether the dev kit bootlaoder requires signed images, please connect to the dev kit with a USB cable and run the info command, and share the output here.

In order to avoid your firmware being overwritten by the installer, I strongly advise that you recompile the SAMI pH app with a meaningful name instead of editing the hello world app. The name for the app comes from the directory that contains the app within the bm_devkit directory. You could copy the hello_world directory with your working code and then rename the copy to something like sami_ph. Then when configuring the build with cmake set -DAPP=sami_ph or whatever you’ve chosen.

Those 2 “copy” and “cmake” instructions correspond to steps 1 and 5 under heading Create and build hello_world_guide_5.

I hope that helps! Let us know how it goes.