Binary Recompile for 5.0.6

[nomakewan]

We received a report that after flashing 5.0.6 to all devices, music playback stopped working. After consulting with a user who reported this and advising them to flash 5.0.5 on their wand and pack but leave 5.0.6 on their attenuator, normal functionality was restored. Based on the source code diffs between 5.0.5 and 5.0.6 on this repo, there shouldn't have been any differences in the firmware for the non-Attenuator devices.

This PR recompiles the binaries for all devices based on the current source code available on the repo as of V5.0.6.

[nomakewan]

For clarification, my development environment I use to compile these is as follows:

Arduino IDE 1.8.19

Arduino AVR Boards 1.8.6
Expressif Systems esp32 2.0.11

ArduinoJson by Benoit Blanchon 7.0.4
AsyncTCP by dvarrel 1.1.4
CRC32 by Christopher Baker 2.0.0
digitalWriteFast by Watterott, Armin Joachimsmeyer 1.2.0
ElegantOTA by Ayush Sharma 3.1.1
ESP Async WebServer by Mathieu Carbou 2.9.5
ezButton by ArduinoGetStarted.com 1.0.4
FastLED by Daniel Garcia 3.6.0
Ramp by Sylvain Garnavault 0.6.1
SafeString by Matthew Ford 4.1.31
SerialTransfer by PowerBroker2 3.1.3
simple ht16k33 by Peter Sjoberg 1.0.2
Switch by Albert van Dalen 1.2.4

Perhaps by looking at my environment versus the other environments a reason for the diffs after compilation may become apparent (though it may not explain the sudden loss of music functionality reported by the user).

Further note that for the "Reset" firmware for the ESP32, all I did was uncomment the line //#define RESET_AP_SETTINGS and recompile. If there are additional steps required for compile the reset firmware, please let me know.

[DustinGrau]

That's curious, as when I did the recompile I ended up seeing that the pack and wand .hex files got recompiled, despite my not doing anything to that code. If any of the libraries were not present, the compilation would've failed on either the Git build (which is just a sanity check) or the local compile script. You can run the same by installing the ArduinoCLI and run the compile.sh from either a Linux/Mac environment, or via Cygwin on Windows.

[DustinGrau]

I've re-checked my libraries to ensure everything is present, and performed a recompile. The Git client shows no differences on the pack/wand binaries from what's already in the /main repository, so that should be enough to conclude there's no changes. I don't know why your recompiled versions are coming up as different though.

I'd like to avoid pushing another fix if it's not necessary--do we know for certain that the binaries were corrupt or invalid? I know I pushed the latest code to my pack when I had tested, though I didn't update the wand from 5.0.5. Though come to think of it, I tend to compile and push via ArduinoIDE not the binaries. Still, if what I rebuild is binary-same to the main repo I don't see what the recompile would be doing different.

How did the user's issue present? I saw the user who had a music issue but figured out the cause was just human error (most likely).

[DustinGrau]

Tried one more compile on another machine, same result (binaries are the same).

[nomakewan]

I've re-checked my libraries to ensure everything is present, and performed a recompile. The Git client shows no differences on the pack/wand binaries from what's already in the /main repository, so that should be enough to conclude there's no changes. I don't know why your recompiled versions are coming up as different though.

I'd like to avoid pushing another fix if it's not necessary--do we know for certain that the binaries were corrupt or invalid? I know I pushed the latest code to my pack when I had tested, though I didn't update the wand from 5.0.5. Though come to think of it, I tend to compile and push via ArduinoIDE not the binaries. Still, if what I rebuild is binary-same to the main repo I don't see what the recompile would be doing different.

How did the user's issue present? I saw the user who had a music issue but figured out the cause was just human error (most likely).

The issue presented with the user flashing 5.0.6 (from the GPStar website) to all three devices and having no music show up in either the Attenuator webpage or the wand menu. They had previously flashed 5.0.5 to the wand and pack but had not yet built their Attenuator, and music had worked fine (via the wand menu). I asked them to flash 5.0.5 from the GPStar website to their pack and wand and leave the Attenuator on 5.0.6, and this resolved their issue. Music appeared on the Attenuator webpage, and worked via the wand menu.

[DustinGrau]

I did realize that what I likely didn't check was loading the binaries directly using the flasher tool. When I update I tend to live-compile and flash via the ArduinoIDE. I've just refreshed all 3 devices with the shipped binaries with no issues--all sounds and music work, and the tracks are shown in the dropdown on the web UI. It's unclear what might have happened to that user or why they had to seemingly mix and match firmware but it doesn't seem like that should be the norm.

[nomakewan]

I agree it should not be the norm, yes. I'll mark this as draft for now and investigate. I don't use the command line tools to create the binaries--I use the "Export compiled binary" function in the Arduino IDE to create the binaries.

I will put together a cygwin environment and see what happens when I run the compile.sh script. At the very least I can see that there are two more steps when it comes to making the ESP32 "Reset" firmware which were not immediately apparent, so that could explain the multi-kB loss of filesize.

[nomakewan]

Okay. After figuring out that the stupid Github Desktop screwed up line endings in the compile.sh file, I got the cygwin compile to work. And indeed, compiling via arduino-cli gives completely different results to compiling via the Arduino IDE's "Export compiled Binary" function. However, both the IDE and CLI agree with program size, at least:

The verbose compilation output of the IDE also confirms that the all of the board and library versions used match between the IDE and arduino-cli. In fact, the output from arduino-cli shows that it's using the exact same libraries that the IDE is using, from the exact same directories on my computer. And yet despite using the same libraries and same board definitions and coming up with the same values for program space and global variable RAM usage...the actual compiled binaries differ between what is generated via arduino-cli and what is generated via the IDE.

I'm at a loss.

[DustinGrau]

Yeah the CLI is pretty cool, it just reuses what's downloaded by the IDE which makes management easy. I also wouldn't have expected the verbosity to affect the image size, so at least you were able to find the differences. And now you'll be able to compile everything headless :)

[nomakewan]

After retargeting main and running the shell script, the results are that my arduino-cli compiled binaries still show differences between the binaries currently on the repo for 5.0.6 and the freshly-compiled binaries using arduino-cli. I do notice, however that the differences between the arduino-cli output and what currently exists on the repo appear to be single-byte changes (for example, a 3 becoming a 5, a C becoming a D, a 4 becoming a 6, etc).

So I'm afraid I'm still at a loss, here. Neither my IDE nor arduino-cli output match the compiles on main, and my IDE and arduino-cli output do not match one another, either.

[DustinGrau]

Both of my compile environments are Mac and produced the same output. I haven't tried my spare Windows machine, but honestly I wouldn't worry about it. I've been using these same systems to compile these binaries for almost a year now consistently, so as long as it's a clean compile with the right libraries it's never caused an issue. I can't explain 1 user case, though I wouldn't worry since it had a workaround. We can save the recompile for a true change in the future as I'm sure there will be another update soon enough.

[nomakewan]

Fair enough. I will save this investigation for some future date should it become a bigger problem. Closing.