Thermometer in my office
Don’t you hate it when something that was working stops? You can safely bet that it’s because, somewhere along the way, something has been ‘improved’.
I needed to make a change to the code running on a couple of IoT room thermometers. These are built around the Adafruit Huzzah ESP8266 board (the non-Feather version). And they’ve been running flawlessly for months.
However, I recently changed the topology of my home network and the IP address of the intranet server they need to contact has changed.
‘Simple,’ I thought. ‘Just change the IP address in the code and re-flash the boards.’
‘Not so fast,’ replied fate.
You see, in the meantime, I had upgraded my copy of the Arduino IDE to version 1.8.10. That, it turns out, was a mistake.
Having made the change to the code – literally changing one character from ‘0’ to ‘1’ – I clicked the upload button and was treated to this outpouring of errors:
Arduino: 1.8.10 (Mac OS X), Board: "Adafruit Feather HUZZAH ESP8266, 80 MHz, Flash, Disabled, All SSL ciphers (most compatible), 4M (no SPIFFS), v2 Lower Memory, Disabled, None, All Flash Contents, 115200" panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x1440824] goroutine 1 [running]: github.com/arduino/arduino-cli/legacy/builder.ResolveLibrary(0xc000124c00, 0xc00032c2ff, 0x5, 0xc00032c2ff) /home/jenkins/workspace/arduino-builder-all-cross-cli-inception/src/github.com/arduino/arduino-cli/legacy/builder/resolve_library.go:64 +0x1d4 github.com/arduino/arduino-cli/legacy/builder.findIncludesUntilDone(0xc000124c00, 0xc0000762a0, 0x1578ca0, 0xc0000c94f0, 0xc00009cbb0, 0xc0002f0000, 0x0) /home/jenkins/workspace/arduino-builder-all-cross-cli-inception/src/github.com/arduino/arduino-cli/legacy/builder/container_find_includes.go:358 +0x3db github.com/arduino/arduino-cli/legacy/builder.(*ContainerFindIncludes).Run(0x1bacff0, 0xc000124c00, 0x1bacff0, 0x0) /home/jenkins/workspace/arduino-builder-all-cross-cli-inception/src/github.com/arduino/arduino-cli/legacy/builder/container_find_includes.go:152 +0x4e6 github.com/arduino/arduino-cli/legacy/builder.runCommands(0xc000124c00, 0xc0005d3c20, 0x20, 0x20, 0x401, 0x20300000000000, 0x50) /home/jenkins/workspace/arduino-builder-all-cross-cli-inception/src/github.com/arduino/arduino-cli/legacy/builder/builder.go:210 +0xdf github.com/arduino/arduino-cli/legacy/builder.(*Builder).Run(0xc0000ade70, 0xc000124c00, 0x1bacef0, 0xc000194020) /home/jenkins/workspace/arduino-builder-all-cross-cli-inception/src/github.com/arduino/arduino-cli/legacy/builder/builder.go:117 +0xd28 github.com/arduino/arduino-cli/legacy/builder.RunBuilder(...) /home/jenkins/workspace/arduino-builder-all-cross-cli-inception/src/github.com/arduino/arduino-cli/legacy/builder/builder.go:226 main.main() /home/jenkins/workspace/arduino-builder-all-cross-cli-inception/src/github.com/arduino/arduino-builder/main.go:398 +0x800 /Applications/Arduino.app/Contents/Java/arduino-builder returned 2 Error compiling for board Adafruit Feather HUZZAH ESP8266. This report would have more information with "Show verbose output during compilation" option enabled in File -> Preferences.
I’ve included the whole thing so that you can get a true sense of the horror. But the critical part of it is the error message:
panic: runtime error: invalid memory address or nil pointer dereference
You can see anguished references to this problem all across the interwebs – and not just with ESP8266 boards.
I tried re-installing libraries, re-installing boards, re-installing the Silicon Labs VCP drivers, even re-installing the Arduino IDE – but no dice.
Finally, I noticed a couple of references to people rolling back their version of the Arduino IDE to 1.8.9. Luckily, it’s still available. And yep, that cured that problem.
But now I had another one.
Updating fonts
The code still wouldn’t compile because the libraries I’d re-installed include TFT_eSPI, which is what I use to drive the display and get nice fonts.
I use a number of custom fonts and settings for this project. But these get erased every time the library is updated. Luckily, having worked this out a while back, I keep a copy of the custom files in a safe place. I copied those over et voila! Ça marche!
At least, the code compiles. But it won’t upload to the board.
Time out
The verbose information during upload was showing endless messages saying ‘timed out waiting for packet header’.
Back to the forums. Some people suggested holding down the ‘boot’ or ‘en’ (enable) button during the whole uploading process. The Huzzah doesn’t have either (at least, not labelled as such). It has ‘Reset’ and ‘GPIO0’.
Well, it’s got to be one or the other, right?
Nope. I tried flashing with first one button held down and then the other. Nada.
I noticed something strange, though. When given power, both boards would go into flash mode, with the red LED glowing dimly. Normally, you get that only after manually putting the board into that mode by holding the GPIO0 button and pressing Reset.
I tried a fresh Huzzah board and it flashed without an issue. So I figured that my earlier borked attempts at flashing had left these boards in an unusual state.
Finally, I tried flashing while holding down both buttons. At first, this seemed like it wasn’t going to work – I started getting the timeout messages again. But suddenly there was a burst of activity and the code starting uploading.
That was one board done. I tried again with the other. Same deal, but this time I held both buttons for a while (again getting the timeout messages) then released the Reset, while still holding down GPIO0. The code started loading and I continued holding down the button until it finished.
That was a hell of a lot of work to change one character in the code.