UART CLI unresponsive after upgrading OSLite firmware on Ubiswitch to v1.0.0

BotBlox Hardware
1

This topic was migrated from the BotBlox ticketing system after being summarised and anonymized.

Problem:

Customer upgraded a UbiSwitch running BloxOsLite from v0.4.2 to v1.0.0 using the MCUmgr firmware update process. After the upgrade, network switching functionality continued to work, but the UART CLI became completely unresponsive. Downgrading back to v0.4.2 did not restore CLI functionality.

Answer:

Root cause was a bug in the MCUBoot bootloader used by older BloxOsLite releases. The bug incorrectly calculated the maximum allowable application size during MCUmgr upgrades, causing the v1.0.0 image to be improperly handled. The issue was not caused by BloxOsLite itself.

The workaround was to flash v1.0.0 directly using ST-Link or J-Link rather than MCUmgr. A later version of MCUBoot contains a fix for this issue.

The conversation:

Initial ticket:

I updated BloxOsLite on a Ubiswitch from v0.4.2 to v1.0.0. The update seemed to work. I’m able to get a network connection across it, but I’ve lost all comms from the UART CLI. Additionally, after downgrading back to v0.4.2, I still don’t have comms.

This was my update procedure:

Use mcumgr-client version v0.0.7.
Reboot the Ubiswitch
Immediately after, run “mcumgr-client.exe -v -d list”
Run “mcumgr-client.exe -b 115200 -v --mtu 256 -d upload ubiswitch_rev_b_v1.0.0\app_dfu.bin”
let this complete
Run “mcumgr-client.exe -v -d reset”
Reboot the Ubiswitch
Test network connection through the switch
Through UART CLI, send “help”
No response…
This procedure was repeated for the downgrade back to v0.4.2.

I understand that v1.0.0 is a breaking change (Releases · botblox/bloxoslite-releases · GitHub). To what capacity is this a breaking change, besides updated commands? And is it expected to impact the CLI?

Aaron’s response:

From debugging today, I discovered the core issue.

It seems that the `mcuboot` bootloader (commit a4eda30f5b0cfd0cf15512be9dcd559239dbfc91), which is used on our zephyr fork branch `dsa-extended-3.6.0` (see west.yml) has a bug where it will interpret the size of an application in a bootable slot as being larger than it actually is. This is due to the `boot_status_entry_sz` function in `bootutil_misc.c` giving the amount of space required for a single swap operation (the trailer used at the end of the image). However the UbiSwitch is in single application boot mode so this trailer doesn’t apply. The function makes no distinction though.

This issue has arisen because the v1.0.0 BloxOsLite release is simply large enough to trigger the size limit failure where previous updates did not. This is a bug with the mcuboot bootloader, not specifically our application code. It is still our problem to fix though…

Solution:
The user must flash with the latest v1.0.0 over STLink/Jlink rather than using the MCUmgr updater for this release. I think we can get away with this on account of this being a breaking change.

In future:

  • I should make sure to test MCUmgr updates in new releases with bootloaders released from old releases to make sure we don’t get issues like this surfacing again. Either that, or we need to find a way to automate that process.

Other notes:

(TS2509-0014)