BloxOsLite RELEASED FOR UBISWITCH REV B

[aaron]

BloxOsLite Release for UbiSwitch is here!

Today, we announce the official launch of BloxOsLite, a lightweight new software designed to add VLANS, link aggregation, and other network management features to UbiSwitch. This will enable customers to use network management on the UbiSwitch.

Previously no network management was available on UbiSwitch

BloxOsLite addresses this challenge by offering an expanding suite of features, including:

• VLANs
• Link Aggregation (LAG)
• Port status/auto-negotiation

These features will help answer the most common customer requests for management that we get for the UbiSwitch meaning customers will no longer be required to reach out to us for custom-made firmware.

We are also working on more features to be released soon to BloxOsLite including QoS (Quality of Service stack) and much more. The firmware comes with a bootloader which you can use to upgrade the application over UART when deployed in the field, meaning that you won’t have to rely on flashing firmware over JTAG.

More to come in the future

BloxOsLite currently only runs on UbiSwitch revision B. We are currently developing new revisions of the SwitchBlox Industrial and GigaBlox Nano, which will be compatible with BloxOsLite.

We are aware that customers who want more advanced networking features, such as multicast querying or STP, BloxOsLite may not be the correct solution for you. However, we already have a plug-on board for SwitchBlox Rugged, called RuggedSOM, which you can try. Its software is still considered in beta and is features/bugs are being actively developed.

BloxOSLite Firmware Image Link
BloxOsLite Documentation Link

[peci1]

Congrats to the release! I’m glad to see you decided for MIT license. Can I already somehow access the sources? I’d like to get inspiration for our Rev A firmware if that’s possible.

[Tore]

Hi,

We seem to need your assistance getting the UbiSwitch CLI up running.

Using STLINK-V3SET we managed to download “zephyr.hex” and “zephyr.signed.confirmed.hex”, the latter file with option “Skip flash erase before programing” enabled. Both files downloaded and verified successfully.

Screendump from STM32 CubeProgrammer:

Then your instruction say: “Power cycle the board and wait for the boot LED to turn off. You are then able to open a serial console into the CLI over UART”.

What is the correct com port settings (baudrate, data bits, parity and stop bit)?

We also tried to use the mcumgr-client to download “zepyr.signed.confirmed.bin” but we ended with an Error: rc = 3

Screendump from cmd.exe running mcumgr-client:

Any idea what’s wrong?

Best, Tore

[aaron]

Hi,

On licensing, I apologize if I’ve added confusion with the licensing - I’ll clear it up here. We went with MIT licensing for the released binaries to dispel any hesitation to integrate our product into designs that may be sensitive to licensing. We wanted to encourage permissive use.
In terms of the source code, publicly releasing this isn’t something we feel good about doing for three key reasons. (1) Whilst we’re going to add features and fix bugs on BloxOsLite, accepting PRs from others isn’t something I feel I can manage at this stage (maybe that will change once we begin expanding the team). (2) We want to protect our hard work. Finally (3) we know that customers may want particular firmware created (indeed, that was what you’re asking for!), we actually already have an internal BSP layer that we’ve been using for customers up until now. Producing custom firmware is already something we can do. BloxOsLite makes this BSP layer pretty much irrelevant for most customer use cases going forward though.

As an aside, you mentioned UbiSwitch Rev A. This would be very unlikely to run any application similar to BloxOsLite (especially with a bootloader / built with the same framework as BloxOsLite). The MCU onboard is simply too small (flash and RAM). Instead, we’ve made use of the aforementioned internal BSP layer to create custom firmware, which has worked rather well for customers. If that isn’t suitable, I’m very happy to offer my suggestions as to what you can do and where to look to produce your firmware.

[aaron]

Hi Tore,

Thanks for the questions!

Re. UART - I’ve updated the docs with the relevant UART configuration - 115200 8N1 are the parameters (115200 bps, 8-bit characters, no parity check, 1 stop bit).

Regarding mcumgr-client usage, I’m curious about when you attempted to list the images, it sent an empty array back. You’re meant to get back the image hash.

response: {
  "images": [
    {
      "hash": [
       ...
      ],
      "slot": 0,
      "version": "0.1.0"
    }
  ]
}

Are you sure this board was programmed with the application in your earlier step in STM32CubeProgrammer? I didn’t need to select ‘Skip flash erase before programming’ for either the bootloader or the application.

[Tore]

Correct, my array is empty:

response: {
“images”:
}

I’ve programmed the two files, first zephyr.hex then zephyr.signed.confirmed.hex, which you updated two days ago. Their filenames are still not “bootloader.hex” and “app.hex” after I download the files (but this shouldn’t matter, should it?).

And yes, I did also try programming both files without selecting ‘Skip flash erase before programming’. But still, the array remains empty.

Also, erasing the STM32G07 Flash Memory before programming the two files didn’t help much.

Looking at the Flash memory listing inside STM32CubeProgrammer after programming the two files I find code in the following memory locations:

0x08000000 - 0x0800A327 (zephyr.hex)
0x08010000 - 0x0801AEFB (zephyr.signed.confirmed.hex)
0x0801FFE8 - 0x0801FFFF (?)

Here’s a link to my STM32G07 memory dump:

STM32G07 Flash Memory.bin

Hope this helps you figure out what’s wrong.

Best, Tore

[Tore]

Maybe there is something wrong with my option bytes and user settings:

Please verify my setup below:

Best, Tore

[aaron]

Hi Tore,

Your option byte settings look good to me.

I just tested with exactly your bin dump (so we have a like-for-like comparison) and still managed to list the image hash and perform an upgrade. So I’m thinking there may be an issue with using mcumgr-client on Windows (I swap between Linux and macOS during development myself). Even though its documentation does state it can work on Windows, it may be worth trying another MCUmgr client. One I’ve used before is mynewt-mcumgr-cli (see here). I’ll outline the steps below.

1. Install the tool (requires go>=1.18):

go install github.com/apache/mynewt-mcumgr-cli/mcumgr@latest

Else for go<1.1.8

go get github.com/apache/mynewt-mcumgr-cli/mcumgr

2. Add the serial connection profile. In your case,

mcumgr conn add serial0 type="serial" connstring="dev=COM5,baud=115200"

3. Perform the steps in the documentation to list the image hashs during boot up but with a new command.

mcumgr -c serial0 image list

4. Assuming you can verify that the image is already flashed from above, practice updating that image

mcumgr -c serial0 image upload -e app_dfu.bin

[Tore]

Yes, I will try installing another MCUmgr client to verify the image is correct.

Still, after programming the two hex files, “bootloader.hex” and “app.hex”, using the STM32CubeProgrammer.

How do I initiate or start the BloxOsLite CLI from my Tera Term terminal program (115200baud 8-n-1).

1. Should I expect some kind of CLI welcome message
2. Do I need to send some command to get the CLI prompth

Please advise

[Tore]

Here’s a screendump after I’ve installed through go>=1.18:

As you can see the “mcumgr -c serial0 image list” reply with:

Images:
Split status: N/A (0)

[Tore]

We use Windows and Tera Term.

Does my Tera Term setup seem correct?

[aaron]

@Tore

• Should I expect some kind of CLI welcome message
• Do I need to send some command to get the CLI prompth

You’ll get a boot banner and a command prompt automatically if you open a serial console and let it boot to the application

[aaron]

@Tore

Images:
Split status: N/A (0)

The only way I could replicate this is if I did not program the app.hex file with STM32CubeProgrammer but even in that scenario, I was still able to upload the app_dfu.bin to the image slot.

./mcumgr -c serial0 image list
Images:
 image=0 slot=0
    version: 0.1.0
    bootable: false
    flags:
    hash: 863ec8515ae5c7e885ab2b0f1a452531c6e19d2899c5e68e86463e156dd58e48
Split status: N/A (0)

I want to attempt this on Windows so I can rule out that this would be causing the issue first. I’ll get back to you with my results.

[aaron]

Hi Tore,

Just tried the same setup on Windows with STM32CubeProgrammer and Tera Term and I managed to boot the application and perform an upgrade so can rule out the operating system.

A couple of general things to check:

1. Have you tried this on only one UbiSwitch revision B? In order to rule out if this is due to a faulty board, if you have other UbiSwitch rev B, it would be good to try them.
2. Have you checked your USB-UART connection wiring? RX, TX and GND connected securely to the signals on UART header J18
3. You could leave the MCUmgr upgrades for now and just let the board boot after programming it to application (as would be the case normally if there were no upgrades). You can then open a serial console using Tera Term and use the application as normal. It would be good to get the MCUmgr upgrades working for your setup but at least it could unblock you in the short term.

[Tore]

Hi Aaron,

Good to hear this works with Windows. Unfortunately, this means I’m doing something wrong on my end. Hopefully we can sort out what this is in today’s afternoon meeting.

To answer your questions:

[Tore]

Dear Aaron,

Your “Flashing and Upgrading” instructions Target information says 128kB:

This, while mine Target information says only 64kB:

How could this be correct ?

Best, Tore

[Tore]

I’ve now verified the UbiSwitch STM32 device marking “G071K86” Flash memory size is 64kB.

Considering the fact that “app.hex” resides in the memory area above address 0x08010000, in other words above 64 kBytes, there is no room for “app.hex” on this 64kByte version of the chip.

I guess I need a UbiSwitch with the 128kBytes device version is required for this to work.

[aaron]

Hi Tore,

Thank you for bringing this up. It has occurred that the UbiSwitch that you received had the 64Kb MCU, rather than the 128Kb MCU as intended. We’re working to resolve this with the manufacturer but in the meantime, I’ve made a new release, v0.1.1, with new instructions on programming for 64Kb UbiSwitch.
Note that this only affects customers who have UbiSwitch with the 64Kb MCU who want to use BloxOsLite; all future UbiSwitch Rev B boards are going to have the 128Kb MCU and hence can follow the bringup outlined before.

Thanks,

Aaron