Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Passing command line arguments out of order can lead to spurious/misleading errors (ESPTOOL-127) #146

Open
forrestfiller opened this issue Nov 24, 2016 · 3 comments

Comments

@forrestfiller
Copy link

I'm less of an advanced user, apologies if this is too basic of a question:

I've been struggling for the past day with flashing my esp, as I'm unsure what they mean by address? I have used 0x00000 as well as 0x0 before my .bin file. Have a look at the enclosed screenshot. Thanks for your time.

  • OS: running VirtualBox on Sierra, using an Ubuntu 16 64-bit image
  • ESP2866 flash id: e0, 4016 ( which is a A25LQ032) "Huzzah" breakout from Adafruit Industries (chip id: 0x000e363a)
  • powered through my laptop's usb port, with a TTL/USB cable

virtualbox_ubuntu16_24_11_2016_10_00_46

@projectgus
Copy link
Contributor

This is a bad error message, so it's absolutely not your fault that it doesn't make sense. The esptool options have to passed in a certain order - a small number apply to "esptool" and some apply to the "write_flash" subcommand.

This is annoying, and I've been trying to think of a good way to fix it but at the moment esptool relies fairly heavily on python's built-in argument parsing support which is what does this.

You should find this argument order works (-b before write_flash, -p goes before write_flash also.)

esptool.py -b 74880 write_flash -fm dio -fs 4m -ff 80m 0x0 nodemcu-dev-13-modules-2016-11-24-01-56-58-integer.bin

(BTW, -fs 4m is only 4 megabits which is half a megabyte. If you have a huzzah you probably want -fs 32m for 32 megabits ie 4 megabytes. Or with esptool v1.2 or newer you can leave it blank and esptool will detect the actual flash size.)

Please let me know if this works for you. In any case, I'd like to keep this issue open as a reminder that the underly argument order problem needs to be taken care of (ideally, you should be able to put -b anywhere you like. Or, at minimum, the error message you should tell you what you did wrong.)

@projectgus projectgus changed the title Address - Binary pair issue Passing command line arguments out of order can leave to spurious/misleading errors Nov 24, 2016
@projectgus projectgus changed the title Passing command line arguments out of order can leave to spurious/misleading errors Passing command line arguments out of order can lead to spurious/misleading errors Nov 24, 2016
@projectgus projectgus added the bug label Nov 24, 2016
@forrestfiller
Copy link
Author

@projectgus Thanks very much, I was able to flash the unit correctly thanks to your thoughtful and helpful reply.

The reason I elect to flash with the minimal -fs 4m in lieu of your above recommendation (-fs 32m) is that I am attempting to follow along with this LoRaWanGateway repository. The author recommends keeping the image as small as possible: "...The LoRaWanGateway needs quite some RAM and processing power, so it it necessary to flash firmware that uses as little resources as possible. "

I wanted to share a little bit more about some of the issues I struggled with during my final attempts to flash the ESP8266:

  • Once I followed your above recommendations for syntax, etc., the flash command appeared to be successful. However, when I went to my serial monitor at the debug logging baud 74880, I found that I was getting gibberish (less responsive to my attempts to communicate via terminal, and a higher volume of gibberish than normal). I tried to do a reset with the buttons on the breakout board, and from that point forward I noted that the blue LED flashed nonstop whenever the ESP8266 was powered on. After doing a little research, it looked like perhaps when you are flashing a new version of the nodemcu, residual data from the previous version of nodemcu might be interfering. So I decided to start with a clean slate and I ran: sudo python esptool.py erase_flash and I was successful in erasing my board. It took me several attempts, with timeout errors, etc., but eventually (with some connecting/reconnecting of my USB/TTL cable and restarting my VM) I was successful.

  • When I went to reflash with your recommended syntax (thank you once again!), I kept having timeout and connection errors. I ended up removing the baud speed altogether (I had originally selected to use the debug log flash speed 74880) and went with the default (which I believe is specified at 115200). After several
    sudo python esptool.py write_flash -fm dio -fs 4m -ff 80m 0x0 nodemcu-dev-13-modules-2016-11-24-01-56-58-integer.bin later, the process flashed successfully. I was able to confirm it worked by logging onto my wifi and printing out a confirmation in my terminal.

Thanks so much for all of ongoing your support which was invaluable.

Best regards,

Forrest

@tablatronix
Copy link

So annoying, i get bit by this everytime I use it.

@radimkarnis radimkarnis changed the title Passing command line arguments out of order can lead to spurious/misleading errors Passing command line arguments out of order can lead to spurious/misleading errors (ESPTOOL-127) Dec 10, 2020
@tom-borcin tom-borcin added Type: Bug and removed bug labels Feb 13, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants