BCF Frustrations

The BCF experience is by far the most frustrating part of working with Morse Micro. There’s no clear way to know what firmware version a given BCF is meant for, and getting one from a vendor is often a hassle. When trying to support multiple boards from different manufacturers, this quickly becomes unmanageable. Many vendors, like Seeed, have forked the OpenWRT repo without pinning the feed version, so builds eventually break and it’s unclear which BCF is included or compatible.

Morse Micro should make it easier to identify firmware, BCF compatibility and push vendors to publish their BCFs. If the tooling to generate them isn’t public, that makes the lack of access even more frustrating. Right now, the BCF situation feels opaque and fragile, and it’s the biggest thing keeping Morse Micro from broader adoption.

1 Like

I couldn’t agree more.

There’s a lot of work that’s been happening behind the scenes to improve this. Some of it is going to take a bit before it sees daylight, but one of the first steps will be launching in the next few days.

We’re going to add a morse-firmware repository with both the chip firmware (mm6108.bin, et al) and BCF files for our reference modules as well as production modules from our partners. We are probably going to launch with only one partner, so please do encourage your vendors to participate.

This repository will have branches for each Morse Micro firmware/Linux driver version, so you’ll be able to select a branch and know that the BCF is compatible.

There’s more coming, but we know this is a major pain point and we’re working on making things easier.

-Zandr

To follow up on this, we’ve published the morse-firmware repository. At present we have our own BCFs and Quectel’s there. If you’re using a module from another vendor, please encourage them to contribute their BCFs. I’ve been reaching out to our partners, but some encouragement from the end customer is most welcome.

-Zandr

Thanks for following up! Can you move the BCF’s to be tied to a particular firmware version? Maybe have a firmware version folder, beneath the vendor? I feel like having the BCF is half the battle.

Oh sorry I see, they are tags for different versions. This is great! I will reach out to Silex to see if they will add their BCFs. I think this will already help my project, I’m using an old version of the OpenWRT repo for both Silex and Seeed boards. The Seeed board uses Quectel chips, so I think I will be able to update to the latest!

1 Like

I think the branching strategy needs to be reevaluated, a folder structure would make more sense. Now all the files in the 1.15 branch, aren’t actually 1.15 BCFs.

The Seeed board currently is using a BCF called bcf_mf16858_fgh100mh_v6.3.0.bin. and is compatible with 1.12. I was hoping that bcf_fgh100mhaamd.bin in your repo would work with 1.14.1. But, it just keeps switching back to the default BCF. Any thoughts on what I can do? I have contacted both Seeed and Quectel with no luck. I would really like an update, I’m getting random disconnects from this older version, that I am not getting from my Silex boards running on 1.14.1.

Thanks for your help!

[   40.695734] morse_spi spi0.0: morse_of_probe: Reading gpio pins configuration from device tree
[   40.704622] uaccess char driver major number is 240
[   40.709640] morse_io: Device node '/dev/morse_io' created successfully
[   40.717112] morse_spi spi0.0: Loaded firmware from morse/mm6108.bin, size 430512, crc32 0xb25c264b
[   40.733668] morse_spi spi0.0: Loaded BCF from morse/bcf_fgh100mhaamd.bin, size 225687, crc32 0x44fe1966
[   41.247878] morse_spi spi0.0: Wrong file format
[   41.758373] morse_spi spi0.0: Wrong file format
[   42.279201] morse_spi spi0.0: Wrong file format
[   42.283860] morse_spi spi0.0: morse_firmware_init failed: -1
[   42.289638] morse_spi_probe failed. The driver has not been loaded!
[   42.295911] morse_spi: probe of spi0.0 failed with error -1

This is correct, however they are compatible with 1.15.
1.15 has backward compatibility to BCF version 8 (1.14 firmware) for the MM6108. (but not the upcoming MM8108)
The theory (and it’s possible I’ve made a mistake) is that the branch will have the latest compatible BCF that’s available for a given firmware revision.

This is from a Seeed board? The IoT SDKs (esp32 and arm) use a more compact format for the BCF.
The embedded platforms use .mbin files, rather than the .bin files in the morse-firmware repo.

There’s a Python script to convert them in the mm-iot-sdk, but as you’ve discovered, it was omitted from the esp32 repository. You can use the script in the arm sdk here: framework/tools/buildsystem/convert-bin-to-mbin.py

We’re discussing automatically converting all the BCFs in the repository to .mbin as well, but haven’t implemented that yet.

Interesting, so for my Silex board the BCF was for 1.14, and that should would with the latest as well? I’ve seen other posts saying using BCFs that don’t match firmware versions causes instability?

Yes, that error message was from the Seeed board. But, running on OpenWrt on a RPI4. The BCF supplied in the Seeed repo is located here: openwrt/bcf at mm/v23.05.3 · Wvirgil123/openwrt · GitHub .

Thanks for your help! I’m going to send you a DM as well.

I wrote a python script to look at some of the attributes in the BCF. I don’t think Seeed used the Quictel BCF.

ssm-user@:~/bcftest$ python3 bcf.py bcf_fgh100mabmd.bin
Type: ELF
- .board_config: 112 bytes | "ᆳ"
- .board_desc: 10 bytes | "mf08651_us"
- .build_ver: 25 bytes | "ec6cd6f 7934876 _Modified"
- regdoms: AU, CA, US
ssm-user@:~/bcftest$ python3 bcf.py bcf_mf16858_fgh100mh_v6.3.0.bin
Type: ELF
- .board_config: 124 bytes | "ᆳ "
- .board_desc: 6 bytes | "custom"
- .build_ver: 27 bytes | "d94b4c8 598ae0a26b_Modified"
- regdoms: AU, EU, IN, JP, KR, NZ, SG, US
1 Like

I’ll spare you the all the sordid history, but that particular BCF was a ‘stub’ that was created during development of a high-power reference design. Quectel picked up that work and ran with it to create their high-power module.
It has more issues that I care to count, and you’ll get much better results from bcf_fgh100mabmd.bin

Not instability, the driver will load or it won’t.

I will test more tomorrow, but I believe that worked! I’m so excited! Thanks again! I think I may have used wget incorrectly, and got an HTML page not the actual BCF before…