Flashing the controller on linux / fedora

Hi guys, for anyone interested in my documentation of flashing the controller on fedora this is essentially how I did it.

You wont need to follow this if you’re using a debian as nodemcu has a package available from github that Stuart has linked to

Stuarts documentation calls for nodemcu flasher and they only support apple and windows, even compiling the source code trys to make a dmg so…and esphomeflasher ui wont supply the necessary options to flash.

Im running fedora 36? or 35, esphomeflasher is available from the repositories, it contains esptool. Since the nodemcu ui actually uses the esptool to flash we can simply input the command without the dependencies of the nodemcu stuff.

sudo dnf install esphomeflasher

(or esphome-flasher)

Then we can go ahead and input the code that nodemcu inputs to the terminal which is visible in stuarts documentation page:

sudo esptool --port /dev/ttyUSB0 --baud 921600 --after no_reset write_flash --flash_mode dout 0x00000 /path/Controller/esp32-controller-firmware-complete.bin --erase-all

If you’re not running any other usb devices, you can just hit tab after /dev/USB and it will auto complete with the correct device, otherwise use

usb-devices

to decypher which dev it is you want to try and flash.

As Stuart said in a post above, “it wont work without that chip”. We wont get the white led flash on the controller board without the tca9534a chip.

Programming the modules

Avrdude is available from the repositories, and the configuration is located in /etc/avrdude/avrdude.conf

cd /etc/ardude/
sudo rm avrdude.conf 
sudo wget https://raw.githubusercontent.com/SpenceKonde/ATTinyCore/master/avr/avrdude.conf 

Yeah, esptool is very nice.
If you’re using Debian, though, you can’t use the version from their repository. (a) it’s old as heck, (b) it doesn’t include the new upload firmware (it’s loaded to RAM and controls the actual flashing) because it’s not open source and thus doesn’t fit Debian’s free software guidelines.

You can get a working esptool package via http://build.smurf.noris.de/pool/main/e/esptool/esptool_3.3-3_all.deb

yeah, im special and I run special linux so I need an rpm package because .debs arent good enough for me :stuck_out_tongue_winking_eye:

Also fedora only recently added it to the repositories, I think the youngest include was in F35 so its pretty new and shiny.

Well in this case the Fedora people are the ones who appear to have kept their sanity … while Debian has a non-free section, its esptool maintainer there just doesn’t seem to care. Bah.

I have a family member who devs at RH…so its basically, it doesnt matter how you use your system, each and everyone of us has to use it or we get mobbed by the others. But you’re right, it seems as if deb could do something about that.

How are you concluding the maintainer doesn’t care? The upgrade request bug report seems to suggest version 3 breaks things for some people. Could you help solve it? #983719 - esptool: Version 3.0 fixes critical bugs - Debian Bug report logs – https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983719

(It’s also worth remembering that non-free is not part of debian OS and even more voluntary than the main system. Few get paid to package there, even fewer than for the OS.)

@Smurfix
Let’s not risk starting a flame war. Don’t forget that many maintainers are doing it for the good of the community, they have day jobs and families like most people, and occasionally the voluntary effort has to come second.

1 Like

Caring is not really the word to us I think, as yeah,they don’t care. They have shut tonns to do and everyone wants something from them, and the have no time to get it done.

Well, the bugs in question has been open for more than one resp. two years now, with zero feedback from the maintainer; also, Debian still has esptoool 2.x while Upstream is at 3.3 by now.

Thus, I do not write this lightly and/or with intent to start a flame war, but “doesn’t seem to care” does look like an objectively true statement in this case. Fortunately the workaround is easy enough.

What maintainer feedback does it need? 3.x is reported to break stuff that worked in 2.x, so it looks pretty obvious that there would need to be a completely new package, maybe esptool3, to avoid breaking users’ systems.

And esptool3 is ineligible for inclusion because it is not fully free and open source. Someone packaged esptool 2 for use with debian, yet it seems that is not good enough for some people here who call them careless and insane but are not willing even to address the reasons and prefer to keep insulting. It is rather disappointing and demotivating. I would not be surprised to see a package removal request next instead of an upgrade if this is typical behaviour of esptool users. Then someone can start over trying to upload esptool3 and maybe that noris.de package gets a full checking.

Any reaction whatsoever. Silence in the face of documented problems with the package is a disservice to the people using it (or rather, trying to use it, as some ESP32s no longer work with v2). If the maintainer doesn’t want (or thinks that it is not possible) to move to v3 they can close the bug with WONTFIX or just add an appropriate comment to the bug.

No, v3 is not “ineligible for inclusion”. You can easily move the binary-only stuff to a separate package and push that to Debian’s “non-free” archive section. Heaps of firmware is shipped that way.

Anyway, I’d very much like to know what exactly the purported breakage from v2 to v3 is, because I sure haven’t experienced any (sorry but the Debian bug you referenced doesn’t count) – and I would like to discover whether that is a fundamental problem (that really should be addressed upstream, but might force a separate v3 package) or something that can be fixed by different command line arguments or other measures along these lines. Do you have a link?

Thank you @dru_rew1 for posting instructions to help Linux users use esptool.

I think the remaining thread comments have gone a little off topic, so lets get back to DIYBMS and helping improving the project, rather than explore the merits of different Linux distros and package variances.

Thanks all.

1 Like

Stuart, why don’t I just email you the text and we can remove this thread?

If you’ve got updated instructions, would be easier to submit those as a PR on github into the relevant project/repo.

Thanks.