arduino_ide_flash_issues.md 5.8 KB

arduino_ide_flash_issues

I have no idea if these NodeMCU v3 b0ards ever come with something besides an ESP-12E module, but if they do then this qt lil writeup may not apply. =]]]

Also, this shit consists of 2 sections, one with actually properly hooking that shit up (just bel0w) and another for additional tips further down.

pr0blelm?

The NodeMCU has a built-in serial to USB converter, but in my case the Mac drivers for the CH340G chip are completely fucked. Sometimes I could flash a sketch like 5 times in a row, then after that it would fail 10+ times instead. Or even if I finally did get it to flash 100%, the serial output is all garbage no matter the fuckin baud rate. It works fine on a physical Wind0ngs machine but fuck that. ;]

The warnings/errors I was getting were p cool too:

  • WARNING: Detected crystal freq. 156.38MHz is quite different to normalized freq. 40 MHz. Unsupported crystal in use?
  • Timed out waiting for packet header
  • Timed out waiting for packet content

The best part about this is that even the 40 MHz frequency is wrong, since the built-in converter actually runs at 26 MHz. :DDD

The mentioned "crystal" is a crystal oscillator, which is used as an internal clock and directly affects the baud rate that boards use at initial startup and the rates they can scale down/up to. For instance: if you set your sketch to a baud rate of 115200, open your serial monitor, power down the board and plug it back in, the first line of serial output is a bunch of garbage. Now switch the baud rate on the serial monitor to 74880 and prest0, you'll see a message about the used boot mode. I'm not sure if it's true for all boards, but in my case the divisor was 2880 so 115200 / 2880 = 40 MHz crystal and thus 26 MHz crystal * 2880 = 74880 baud. But since the IDE detected it as 156.38 MHz I would've needed a baud of around 450374, which doesn't exist and the nearest one Arduino supports (500000) isn't within the error tolerance margin (usually a couple percent). Fat fucking rip. =]

So I decided to try using an external serial to USB converter (blessed FTDI232):

  • Make sure the converter provides 3.3V, in my case it has a jumper to switch between that and 5V ;]
  • Simply wire the TX pin on the converter to RX on the NodeMCU
  • Then wire RX to TX obviously
  • Connect both GNDs together
  • Finally, provide power from VCC on the converter to VIN on the b0ard
  • The other pins are not necessary, you could theoretically use the DTR pin to automatically restart the b0ard after a flash, but I didn't bother xd

Since USB also provides power it's theoretically possible to power both the FTDI and through that, the NodeMCU. However, this didn't work at all because USB only supports limited power:

  • Low-power USB (up to USB 2.0): 100 mA
  • Low-power USB 3.0: 150 mA
  • High-power USB (up to USB 2.0): 500 mA
  • High-power USB 3.0: 900 mA
  • Multi-lane high-power USB 3.2 gen 2: 1.5 A

Now, since you're dealing with serial connections there's no point in using USB 3.0 for its improved speed to begin with, as such many converters will still be v2.0 or maybe even v1.1. Even if your p00ter supports USB 3.0, it will simply fall back to the older protocol. Meaning it only draws at most 500 mA, and even then I doubt a serial device presents itself as high-power, leaving you with only 100 mA for both the FTDI and NodeMCU. The ESP-12E itself allegedly uses about 80 mA on average when operating, and I assume it peaks higher than that when you're trying to flash shit. If you're powering the board this way and you try to flash a sketch, you'll know the power is insufficient if it does start to flash but suddenly terminates with a Timed out waiting for packet header/content error.

If I use a 1A wall plug to USB converter thingy to power the b0ard, disconnect the wire between VCC and VIN and plug the converter directly into muh p00ter, shit's all fine and dandy. [[=[=[=[=[==[

Also, if the serial drivers on your computer aren't fucked and you power the NodeMCU without an FTDI, it seems to be able to draw enough power to fully run a flash.

br0tips

Improving flashing speed

If you've followed one of the guides like many others, you're probably using the board called NodeMCU 1.0 (ESP-12E Module) in em Arduino IDE. While this generally works fine, it limits the available options and some of those improve flashing performance. I mean yeah, the difference is only a minute or so but if you're working on a new sketch, you'll be flashing a lot at first. ;];]

  • Take note of the current settings such as Flash Size and Builtin Led
  • Change the board to Generic ESP8266 Module
  • Set Builtin Led to its original value if it's different than bef0re
  • Change Upload Speed from 115200 to 3000000 (doesn't affect the serial monitor)
  • Possibly change the Crystal Frequency to 26 MHz if your FTDI also runs at that
  • Set Flash Size to its original value (should pr0lly be a 4 MB flash chip)
  • Change Flash Mode from DOUT to DIO, the former of which is more compatible but slower
  • If you set up automatic reset via the DTR pin I mentioned earlier, you'll prolly wanna make sure the Reset Method is set to dtr (aka nodemcu)
  • You can also change the Espressif FW to something newer if you're feeling audacious

After setting/changing all this, my flash times of about 90 seconds went all the way down to 5 or so. ;]

One extra option the generic board has: Flash Frequency, which you can use to overclock the flash chip and thus improve memory speed. The default of 40 MH should be sufficient for most cases, but if you need a little more then you can run it at 80 MHz. I did that for a short while and didn't notice any instability, but I don't need it (yet) for production usage so I kept it at 40 to be safe. =]