Firmware upgrade with otmonitor not working

[mvn23]

When trying to upgrade the firmware on my gateway through otmonitor I'm running into the following:
Using the GUI, I can load the file, but as soon as I press "Program" the application stops responding. The only output on the console is this one line when loading the file:

Code: Select all

$ ./otmonitor
readfw /home/milan/Downloads/gateway-5.8.hex

Using the command line I get some more useful output:

Code: Select all

$ ./otmonitor --upgrade=gateway-5.8.hex 
Current firmware version: 4.0a9
readfw gateway-5.8.hex
can't read "upgrade::fwversion": no such variable
    while executing
"puts stderr "Target firmware version: $upgrade::fwversion""
    (file "/home/milan/Downloads/otmonitor/otmonitor.tcl" line 2707)
    invoked from within
"source /home/milan/Downloads/otmonitor/otmonitor.tcl"
    ("uplevel" body line 1)
    invoked from within
"uplevel #0 [list source [file join /home/milan/Downloads/otmonitor $file]]"
    (procedure "include" line 2)
    invoked from within
"include otmonitor.tcl"
    (file "/home/milan/Downloads/otmonitor/main.tcl" line 13)

It also seems to misidentify my current firmware version, which should read "5.5"
I tried to upgrade to different versions with the same result, apart from the fact that trying to upgrade to version 5.6 or 5.7 DOES give the correct value for the current firmware version.
I am using otmonitor-x64 6.5 from the 13th of March 2023.
The firmware I am trying to flash - v5.8 - has the following sha256 checksum:

Code: Select all

2e5d0103c849bc92e20f3a7694e014c6246d2f5c5bf1706d0c8fcf16aae50672  gateway-5.8.hex

I am using the P16F88 version and I am connecting via ethernet using a USR-TCP232 module.

[hvxl]

How do you mean, it stops responding? The code should not be doing any blocking operations, The GUI will not allow you to abort a running upgrade, because that might brick the OTGW. But if it fails to reset the OTGW, a "Cancel" button is provided to stop the upgrade while OTmonitor is waiting for you to manually reset the OTGW.

Some bug crept into the feature to upgrade the firmware from the command line, which nobody seemed to use. I have fixed those. You can get an updated version of OTmonitor from the otmonitor github actions page. I believe github requires you to be logged in to be able to download the artifacts. If you don't have a github login, let me know which version you need. I'll post it here, or find some other way to get it to you.

[mvn23]

When I click "Program", the button remains pushed in (see screenshot) and the entire GUI becomes unresponsive. I can only close the application with ctrl-c on the command line (or with `kill` I guess, but I haven't tried that). This behavior persists in the latest version from github.

Screenshot_2024-08-23_17-08-11.png (39.68 KiB) Viewed 2824 times

It also seems that no attempt is made to reset the gateway. The traffic to and from the gateway only shows the normal protocol messages (see

otmonitor-pcap.zip

(1.3 KiB) Downloaded 87 times

).


When using the command line on the new version of otmonitor, the error is gone. It correctly identifies the current firmware version and the new version, but after that nothing happens and I have to use ctrl-c to stop the process:

Code: Select all

$ ./otmonitor-x64 --upgrade=gateway-5.8.hex 
Current firmware version: 5.5
Target firmware version: 5.8
^C

In this case I can see several `PR=A` commands and their responses on the wire, but no attempt to reset the gateway is made:

otmonitor-cli-pcap.zip

(1.72 KiB) Downloaded 82 times

[hvxl]

Thank you for the very useful debug information. However I'm still baffled. There isn't all that much happening between the last output report you get when doing the upgrade from the command line ("Target firmware version: 5.8") and the next one I expect after that ("Switching gateway to self-programming mode"). Even knowing the general area to look for something that may be blocking, I'm unable to spot it. So, to narrow it down further, I made a debug version of otmonitor that reports in more detail what it is doing in that part of the process. Can you try that version and report what output you get?

[mvn23]

Thanks for the effort, it helped me make some progress. I also found that it is likely related to the setup I'm using, more on that later on in this post.

First things first, I tried the debug version, both through the GUI and from the command line. The output was the following:
GUI:

Code: Select all

$ ./otmonitor-x64 
In loadfw (cmd = ::gui::loadfw)
Checking the firmware: 0x158a & 0x3fff == 0x158a
Checking the firmware: 0x2700 & 0x3e00 == 0x2600
All checks passed
Locking the connection to the OTGW
Performing initialization
Configuring the device
^C

CLI:

Code: Select all

$ ./otmonitor-x64 --upgrade=gateway-5.8.hex 
Current firmware version: 5.5
Target firmware version: 5.8
Calling the loadfw proc
In loadfw (cmd = ::flash)
Checking the firmware: 0x158a & 0x3fff == 0x158a
Checking the firmware: 0x2700 & 0x3e00 == 0x2600
All checks passed
Locking the connection to the OTGW
Performing initialization
Configuring the device
^C

Since I have successfully upgraded the firmware before without any issues, I was starting to doubt the sanity of my setup (and my own as well a little bit).
I am away from home at the moment, so I am connecting through a VPN to my home network (hence the different subnets in the pcap files). While this normally works just as well as being physically connected to my home network, I wanted to see if it made a difference in this case.
I decided to spin up an lxc in the same subnet as the gateway and try to upgrade the firmware from there. Lo and behold, the upgrade process continued:

Code: Select all

# ./otmonitor-x64 -f otmonitor.conf --upgrade=gateway-5.8.hex
Current firmware version: 4.0a9
Target firmware version: 5.8
Calling the loadfw proc
In loadfw (cmd = ::flash)
Checking the firmware: 0x158a & 0x3fff == 0x158a
Checking the firmware: 0x2700 & 0x3e00 == 0x2600
All checks passed
Locking the connection to the OTGW
Performing initialization
Configuring the device
Channel configuration:
    -blocking = 0
    -buffering = none
    -buffersize = 4096
    -encoding = binary
    -eofchar = {} {}
    -translation = lf lf
    -peername = 192.168.22.20 192.168.22.20 8802
    -sockname = 192.168.22.159 localhost 44645
Starting the upgrade
Switching gateway to self-programming mode
Please manually reset the OpenTherm Gateway
^C

Of course I am unable to reset the gateway manually at the moment, so I will have to retry that later on when I'm back home.

[hvxl]

Right. Then it must be the part where the channel configuration is saved. A side-effect of doing that is that it tries to perform a reverse lookup of the remote IP address. It probably has trouble doing that in your setup. It should eventually time out, but that may take a while. However, as that saved channel configuration is never used again, it is totally unnecessary to save it in the first place. I have removed the commands in the latest build.

As your gateway is working properly, it should not be necessary to manually reset it to do an upgrade. I did notice that in your latest try it reports the wrong current firmware version again. That is very strange. This seems like there is some kind of communication problem.

But anyway, the latest version of otmonitor should now hopefully work fine with your VPN connection.

[mvn23]

That last version works like a charm!

Code: Select all

$ ./otmonitor-x64 --upgrade=gateway-5.8.hex 
Current firmware version: 5.5
Target firmware version: 5.8
Switching gateway to self-programming mode
Bootloader version 1.1: F00-FFF
Firmware download succeeded - 0 retries

Thanks again for your efforts!