• Hi

    I'd really like to get Espruino running on some Wemos D1 Mini boards - it would let me save a huge amount of space in a very tightly packed room. But I can't seem to get it running the first time.

    I flashed v1.95 with

    Z:\ESPTOOL\espruino_1v95_esp8266_4mb>..\­esptool.py --port COM3 --baud 115200 write_flash --flash_freq 80m --flash_mode qio --flash_size 4MB-c1 0x0000 boot_v1.6.bin 0x1000 espruino_esp8266_user1.bin  0x3FC000 esp_init_data_default.bin 0x3FE000 blank.bin
    

    But now when I try to connect to it with hterm (at 115200 baud, which works for naked ESP12F's) to configure the wifi, I'm clearly not talking to Espruino. It seems like it might be stuck in the bootloader?

    When I press reset with serial terminal connected, I get a bunch of garbage - like the wrong baud rate is selected, except I can't figure out what the right baud rate is. It looks like the ESP8266 likes to use some obscenely high baud rate, 460800 (is that the baud rate I should use to see WTF it's outputting?) - but none of my serial console software gives me an option to select that baud rate; I tried downloading several terminal programs, and none would go higher than 230400. Does anyone know of a program that will (assuming that's the correct baud rate)?

    I originally thought I had a defective board, and wound up trashing the board trying to figure this out (as I started pulling everything connected to the strapping pins off the board ("There's gotta be something about this WeMos stuff that's holding the strapping pins in the wrong state, so remove everything that seems to be connected to it" but nothing I did seemed to fix the behavior I was seeing. The second board behaves the same as the first though, so it seems like it's something wrong with what I'm doing, not with the board I had.

    Has anyone managed to get these to work? What am I missing? I suspect it's something really simple here, but I've put I'd say 5-6 hours into it at this point, and am no closer to making it work than I was when I started.

    Thanks!

  • Baud is 115200. You need to set that in the ide

    Sometime first time connects can be dodgy so use putty or a Linux term to connect first

  • I know that when Espruino is running correctly, I should be able to connect at 115200 baud and after pressing reset, see the Espruino splash screen, and if I don't press reset, sending a few CRLF sequences should generate =undefined in response. Neither of those things happens.

    When I connect at 115200 baud (and every other baud rate setting that hTerm will let me select), I get gibberish (like with a baud rate mismatch) after pressing reset, instead of the Espruino splash screen. Also, if I press enter (after setting the serial terminal application to send a CRLF sequence upon enter, for the terminal programs that need that to be set), I don't get anything back from it at all (not even gibberish).

    I have used hTerm, the Arduino serial monitor, Termite and PuTTY and get the same results on all of them.

    I do not have this issue with an ESP12F on other breakout boards; only on the WeMos D1 Mini. There must be something different about the D1 Mini - I'm just hoping someone knows what it is!

    If not, any suggestions for how to debug this? I'm going crazy, this isn't hard stuff, and I'm sort of embarrassed that I am asking questions like this - I should know better. But I just can't seem to get it sorted, and I don't know what's different that's keeping it from working like it does on my own breakout boards.

  • Maybe a bad output state on RTS/DTR ? Just had a look at the schematic (https://wiki.wemos.cc/_media/products:d1­:mini_new_v2_2_0.pdf) and saw that those signals can have control of RST pin (see U4 on the PDF).

  • Tried every permutation of DTR and RTS states, pressing reset after each one.

    On the other board, I also removed those transistors entirely. It did not change the behavior (other than that I had to manually manipulate GPIO2 to upload to it successfully.

  • If you have a solder iron you could try to access it direct on UART side by removing resistors R3 and R4 and soldering wires to a FTDI chip or cable. the USB-serial chip CH240G is well known for not having good ESD protections, it is not excluded that it is damaged. In the past I already smoked a few of them.

  • We know the serial adapter chip is working though - otherwise I wouldn't be able to flash the firmware with ESPTOOL

  • I use the D1 Mini - well I think they're clones. I'm behind on versions but I flashed 1.91 recently and could connect via Espruino IDE no issues. Have you tried an older version out of interest?

    Edit: espruino_1v95.4819_esp8266.tgz works fine. I didn't set 4M-C1 I used 32m in the esptool command as normal. Not sure what that's for? Otherwise flash command is same including 115200 baud, but not port I'm on Mac.

    When started with these I needed a different serial driver (wchusbserial1410) it took a bit of finding. I wonder if that's relevant? Though if you've flashed it ok I'd guess not.

  • I recommend to start with

    esptool.py --port COM3 erase_flash

    next check id to make sure to use the correct parameter for write_flash

    esptool.py -port COM3 flash_id

    and write_flash statement

  • Thanks - I haven't tried older versions (though 1v95 versions do work for me on ESP8266 on my own breakout boards)...

    The CH340G driver on mac is harder to find, because the one you need changed with high sierra. It's not such a bad situation on Windows. But it's not that - I use a lot of CH340G serial adapters (just quickly looking in the places I know that they live, I counted over 50... They are my go-to serial adapters. Surprised to hear you've managed to damage them. I treat them with reckless abandon and have never had one fail, and the people on the Arduino forum almost never trash the CH340G's (compared to the 16u2 programmed as serial adapter on the official Uno, which burns out if you even think of abusing the +5v rail)

    But I've gotten a bit of new information here.

    flash_id:

    esptool.py v2.3-dev
    Connecting....
    Detecting chip type... ESP8266
    Chip is ESP8266EX
    Uploading stub...
    Running stub...
    Stub running...
    Manufacturer: c8
    Device: 4016
    Detected flash size: 4MB
    Hard resetting...
    

    Output from programming:

    Z:\ESPTOOL\espruino_1v95_esp8266_4mb>..\­esptool.py --port COM3 --baud 115200 write_flash --flash_freq 80m --flash_mode qio --flash_size 32m 0x0000 boot_v1.6.bin 0x1000 espruino_esp8266_user1.bin  0x3FC000 esp_init_data_default.bin 0x3FE000 blank.bin
    WARNING: Flash size arguments in megabits like '32m' are deprecated.
    Please use the equivalent size '4MB'.
    Megabit arguments may be removed in a future release.
    esptool.py v2.3-dev
    Connecting....
    Detecting chip type... ESP8266
    Chip is ESP8266EX
    Uploading stub...
    Running stub...
    Stub running...
    Configuring flash size...
    Flash params set to 0x004f
    Compressed 3856 bytes to 2763...
    Wrote 3856 bytes (2763 compressed) at 0x00000000 in 0.2 seconds (effective 123.4 kbit/s)...
    Hash of data verified.
    Compressed 509332 bytes to 340820...
    Wrote 509332 bytes (340820 compressed) at 0x00001000 in 30.0 seconds (effective 135.9 kbit/s)...
    Hash of data verified.
    Compressed 128 bytes to 75...
    Wrote 128 bytes (75 compressed) at 0x003fc000 in 0.0 seconds (effective 73.1 kbit/s)...
    Hash of data verified.
    Compressed 4096 bytes to 26...
    Wrote 4096 bytes (26 compressed) at 0x003fe000 in 0.0 seconds (effective 4096.1 kbit/s)...
    Hash of data verified.
    
    Leaving...
    Hard resetting...
    

    But most excitingly, I was able to read the output on startup. It's at 74880 baud, the bootlog output! Here's that - does anyone have any thoughts?

     ets Jan  8 2013,rst cause:2, boot mode:(3,6)
    
    load 0x40100000, len 2408, room 16
    tail 8
    chksum 0xef
    load 0x00000000, len 0, room 0
    tail 0
    chksum 0xef
    load 0x00000000, len 0, room 8
    tail 0
    chksum 0xef
    csum 0xef
    csum err
    ets_main.c
    
  • Use flash_size 32m-c1 or 4MB-c1 for espruino_1v95_esp8266_4mb firmware.

  • 4MB-c1 and 32m produce the same behavior:

    Z:\ESPTOOL\espruino_1v95_esp8266_4mb>..\­esptool.py --port COM3 --baud 115200 write_flash --flash_freq 80m --flash_mode qio --flash_size 4MB-c1 0x0000 boot_v1.6.bin 0x1000 espruino_esp8266_user1.bin  0x3FC000 esp_init_data_default.bin 0x3FE000 blank.bin
    esptool.py v2.3-dev
    Connecting....
    Detecting chip type... ESP8266
    Chip is ESP8266EX
    Uploading stub...
    Running stub...
    Stub running...
    Configuring flash size...
    Flash params set to 0x006f
    Compressed 3856 bytes to 2763...
    Wrote 3856 bytes (2763 compressed) at 0x00000000 in 0.2 seconds (effective 124.4 kbit/s)...
    Hash of data verified.
    Compressed 509332 bytes to 340820...
    Wrote 509332 bytes (340820 compressed) at 0x00001000 in 29.9 seconds (effective 136.3 kbit/s)...
    Hash of data verified.
    Compressed 128 bytes to 75...
    Wrote 128 bytes (75 compressed) at 0x003fc000 in 0.0 seconds (effective 73.1 kbit/s)...
    Hash of data verified.
    Compressed 4096 bytes to 26...
    Wrote 4096 bytes (26 compressed) at 0x003fe000 in 0.0 seconds (effective 4095.9 kbit/s)...
    Hash of data verified.
    
    Leaving...
    Hard resetting...
    

    Same output at 74880 baud:

    ets Jan  8 2013,rst cause:2, boot mode:(3,6)
    
    load 0x40100000, len 2408, room 16
    tail 8
    chksum 0xef
    load 0x00000000, len 0, room 0
    tail 0
    chksum 0xef
    load 0x00000000, len 0, room 8
    tail 0
    chksum 0xef
    csum 0xef
    csum err
    ets_main.c
    
    

    I have two boards showing identical behavior (the new one, and the one I removed the transistors between DTR/RTS and the strapping pins on). They are being powered off MicroUSB (could it be a power problem? Do I need an external 3.3v power supply? If so, that makes them a bit less appealing)

  • Mine run from Mac USB power. These and the NodeMCU have always been pretty reliable on USB power. Only when I've been using the 01 and 12 directly have I needed to use a capacitor and maybe supply power from a source other than the USB FTDI adapter. Are yours genuine D1s? You don't think you could have got a bad batch? The quality varies with the cheap boards and I've bought ESP8266 boards that don't do what they should before now (Wifi Node-M).

  • Hmm, strange...it should look like this:

    load 0x40100000, len 2408, room 16
    tail 8
    chksum 0xe5
    load 0x3ffe8000, len 776, room 0
    tail 8
    chksum 0x84
    load 0x3ffe8310, len 632, room 0
    tail 8
    chksum 0xd8
    csum 0xd8
    2nd boot version : 1.6
      SPI Speed      : 80MHz
      SPI Mode       : QIO
      SPI Flash Size & Map: 32Mbit(1024KB+1024KB)
    jump to run user1 @ 1000
    âìnìròn|ìll`ârlþ
    

    What about flashing the 1v95 4mb combined bin file?

    ..\esptool.py --port COM3 --baud 115200 write_flash   --flash_freq 80m --flash_mode qio --flash_size 4MB-c1  0x0000 espruino_1v95_esp8266_4mb_combined_4096.­bin
    
  • Nope, no change....

    C:\esptool\espruino_1v95>..\esptool.py --port COM3 --baud 115200 write_flash  --flash_freq 80m --flash_mode qio --flash_size 4MB-c1  0x0000 espruino_1v95_esp8266_4mb_combined_4096.­bin
    esptool.py v2.3-dev
    Connecting....
    Detecting chip type... ESP8266
    Chip is ESP8266EX
    Uploading stub...
    Running stub...
    Stub running...
    Configuring flash size...
    Flash params set to 0x006f
    Compressed 4194304 bytes to 348713...
    Wrote 4194304 bytes (348713 compressed) at 0x00000000 in 30.7 seconds (effective 1094.0 kbit/s)...
    Hash of data verified.
    
    Leaving...
    Hard resetting...
    
     ets Jan  8 2013,rst cause:2, boot mode:(3,6)
    
    load 0x40100000, len 2408, room 16
    tail 8
    chksum 0xef
    load 0x00000000, len 0, room 0
    tail 0
    chksum 0xef
    load 0x00000000, len 0, room 8
    tail 0
    chksum 0xef
    csum 0xef
    csum err
    ets_main.c
    

    verify_flash passes.

    An external 3.3v regulator doesn't change it.

    The ESP8266 windows download tool does not change results.

    Edit: AAHA! I got it! It needs to be flashed with flash_mode dio instead of qio...

    I examined the module closely, and it's marked ESP-12N - so it sounds like it's not an ESP-12F but a slightly different module, with a different flash mode...

  • Hmm, so first try qio and if it does not work try dio

    Found this hint on https://github.com/espressif/esptool#fla­sh-mode---flash_mode--fm

    Most boards use qio mode. Some ESP8266 modules, including the ESP-12E modules on some (not all) NodeMCU boards, are dual I/O and the firmware will only boot when flashed with --flash_mode dio. Most ESP32 modules are also dual I/O.
    In qio mode, two additional GPIOs (9 and 10) are used for SPI flash communications. If flash mode is set to dio then these pins are available for other purposes.

    Which ESP board is on your Wemos board?

  • Original


    1 Attachment

    • Wemos original.JPG
  • or Clone


    1 Attachment

    • Wemos clone.JPG
  • The ones I've got are these. The prototyping shields are of my design, you can buy em here.


    1 Attachment

    • 20180113_190756.jpg
  • looks like we all missed that post :)

  • Post a reply
    • Bold
    • Italics
    • Link
    • Image
    • List
    • Quote
    • code
    • Preview
About

Has anyone gotten Espruino to work on a Wemos D1 Mini? What am I missing?[SOLVED: dio mode]

Posted by Avatar for DrAzzy @DrAzzy

Actions