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?
After each iteration of the procedure, I rebooted the UbiSwitch and ran the mcumgr-client “list” command. it appears that there are no images loaded after both updates.
Thank you for your bug report. I’ve successfully replicated this bug in my lab and found the root cause.
Simply put, the issue was with the older bootloaders released on the previous versions (<0.4.2), which had a bug regarding validating the image stored during boot. Hence, you see no images when you query the bootloader after flashing v1.0.0, and it doesn’t boot to v1.0.0.
This is already fixed in the bootloader that comes along with the v1.0.0 release, along with many other stability improvements. However, it does mean that MCUmgr updates using older bootloaders will likely not boot the newer versions released so far. Note that newer UbiSwitches ordered will have this latest bootloader installed as well.
The solution is to update the bootloader, and I’ve added documentation on how to do that with an STLink debug probe (you can use other debug probes as well). See here
I apologize for the inconvenience. Hopefully, this gives you a way forward!
@aaron You’ve shared a link to the private notion site, not the public one. It is also in the Github release notes.
And I’d strongly suggest adding a section about the physical setup while connecting the SWD probe - it is not trivial (i.e. whether the baseboard and heatsink should be connected, where to apply power and so on).
It’s been released publicly now. I’ve added those details regarding power on, heatsink, and photos for identifying the relevant SWD programmer header on the board. Let me know if you have issues.
@aaron really appreciate you diagnosing this issue. I suspected it was related to the bootloader but wanted to wait for your response. I’ll update the bootloader and then app with v1.0.0 and will let you know how it goes.
I tried following the instructions here Notion to flash the latest bootloader but I can’t seem to connect to the uC. I’m powering the Ubiswitch module with 24V via the Baseboard Mini on J16, with the UART interface connected as well (although not necessary). We’re holding the 6-pin debug connecter on J9. I tried multiples of both JLink and STLink programmers which can connect to other devices, using STM32CubeProgrammer and JFlash Lite. I tried a Ubiswitch module that was bricked earlier via the faulty update to v1.0.0, as well as one that is perfectly functional.
None of these cases seem to work… Each of the pins on the 10-pin to 6-pin cable has continuity through either side.
Here’s the output from STM32CubeProgrammer when trying to connect via JLink. It shows a target voltage of 0V. I do see LED’s on the Ubiswitch itself though. But it seems like a power issue.
Showing a 0V on the programmer implies there’s probably something simple going wrong. At a minimum you should read 3.3V on the programmer when connected to a powered UbiSwitch.
Can you create a drawing of how your programmer is connected to the SWD pins on UbiSwitch Module? A photo would help too.
I was able to update our Ubiswitch+ large SFP baseboard successfully just following the manual. I just updated the bootloader first and then updated the app via DFU.
I think you need to look at the pinout of the Tag-connect cable you are using, and see how that maps the signals from the J-link into the 6 pin header. That needs to match the pinout that the UbiSwitch expects on it’s 6 pin header.
Page 15.
Worst case use a multimeter to check that first (with the power off)
Ah I see. After double checking, the cable that I’m using is specifically for an Atmel-ICE which does have a different mapping. Will order the proper one for J-Link .
I was able to flash the new bootloader on one of the bricked switches using the recommended JLink 6-pin cables. Looks like app v1.0.0 was loaded afterward.
FYI here’s the bootup logs after that. The “header crc mismatch”, “Cannot read port configuration from database” prints, and other error-ish prints are consistent after reboots. Also flashed app_standalone.hex and still got these prints. I’m not sure if these are problematic. Looks like the persisted vlan configuration still exists according to “conf vlan”.
I: Expected switch chip found
I: Switch chip probe successful
I: BloxOsLite: v1.0.0+0
ubiswitch:~$ I: EEPROM ports db migration from version 2 to version 3
I: Expected switch chip found
I: Switch chip probe successful
I: BloxOsLite: v1.0.0+0
ubiswitch:~$ W: Header crc mismatch
E: DB migration failed
I: Initializing DSA switch ports
I: Get LAG configuration from database
I: Header is empty, no configuration
sI: No LAG configuration in database
I: Get port configuration from database
W: Header crc mismatch
E: Cannot read port configuration from database: -22
I: Get VLAN configuration from database
I: VLAN configuration found in database
I: VLAN configuration applied
.