Browse Source

Added NodeMCU v3 categ0ry and lil writeup about flashing pr0blems [=[=[=[

Wazakindjes 1 year ago
2 changed files with 59 additions and 0 deletions
  1. 4 0
  2. 55 0

+ 4 - 0

@@ -0,0 +1,4 @@
+# [nodemcu_v3] Index lol
+| pr0blelm?                                                                 | h4lp                                                      |
+| ------------------------------------------------------------------------- | --------------------------------------------------------- |
+| Problems with flashing (Arduino IDE)                                      | [arduino_ide_flash_issues](./ |

+ 55 - 0

@@ -0,0 +1,55 @@
+# arduino\_ide\_flash\_issues
+I have no idea if these __NodeMCU v3__ b0ards ever come with something besides an ESP8266 chip, 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](#br0tips).
+# 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 `GND`s 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 ESP8266 chip itself 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. =]