Trouble Uploading Firmware

jdoolin

I finished soldering the BE a few days ago, and since then I've been trying to get the firmware installed. I have a FT232RL dupont wires, a multimeter and two working USB cables.

The FT232RL (set to 3.3v) comes up fine in Linux as /dev/ttyUSB0. I have permission to write to it. Here is how I have things connected:

BE <--> FTDI
gnd <--> gnd
RX <--> TX
TX <--> RX
RTS <--> RTS
DTR <--|
GND <--| (i.e., I have the DTR pin on the BE connected to a GND pin to pull it down so it goes into flash mode)

I've checked many connections with the multimeter, including RX, TX, GPIO0<->DTR, ground, 3.3v, CH_PD, and CTS<->RTS (from the esp to the pin header).

My command to upload the firmware (using the esptool from ttbasic git repository):

python esptool.py -c esp8266 -b 921600 -p /dev/ttyUSB0 write_flash 0x00000000 ttbasic-0.88-alpha.bin

The result is always:

Connecting........__.............................................__

A fatal error occurred: Failed to connect to ESP8266: Timed out waiting for packet header

The blue led blinks a couple times every few seconds on the ESP, and the LED on the adapter closest to the USB port blinks in time. The other LED on the adapter (closer to the voltage jumper) blinks I think 4 times after the others blink twice.

Any help would be most welcome.

jdoolin

Update: I soldered up a second BasicEngine board in case my first one had some bad solder joints or if I had accidentally bricked the ESP8266 (although I doubt that I did).

I'm getting exactly the same behavior on the second board, so YAY, it seems like my boards are soldered fine, but crud, I still haven't figured out why I'm getting that serial error when trying to upload the firmware.

Peek

Just a stab in the dark, but maybe try lowering the baud rate (115200? 9600?) or leave that baud flag out altogether. If I remember correctly, in addition to DTR being held low, I also had to hold the reset button down until it started trying to connect (this was for another project and it was on an esp8266 devboard)

jdoolin

Another Update.

I'm trying to see if I can talk to the ESP at all by using minicom. I've configured minicom to use the right serial port, 115200 baud, 8N1, add a carriage return to line feed (as I found in several tutorials).
I'm able to connect, and if I hit reset on the Basic Engine, I get some output of various printing and non-printing characters, followed by the word "ready".

If I type AT and press Enter, nothing happens. I'm not even seeing lights blinking on the FTDI adapter. Shouldn't I be seeing that?

jdoolin

I tried using cu, screen and minicom and was not able to send an AT command to test. This time I decided to try the Arduino editor.

I did try something new and got some results. I set the baud rate to 74880, and this time I got boot output from the ESP:

ets Jan 8 2013,rst cause:2, boot mode🙁3,6)

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 : 40MHz
SPI Mode : QIO
SPI Flash Size & Map: 32Mbit(512KB+512KB)
jump to run user1 @ 1000

rf cal sector: 1017
rf[112] : 00
rf[113] : 00
rf[114] : 01

SDK ver: 2.0.0(5a875ba) compiled @ Aug 9 2016 15:12:27
phy ver: 1055, pp ver: 10.2

⸮⸮j⸮l

What's odd about this is that I don't have a 'ready' prompt and instead there's that little ??j?l. At 115200 baud, I get garbled characters, but a 'ready' prompt. I also still cannot send an AT command, but it could be I'm not doing things correctly.

I also tried grounding the DTR pin and it started in bootmode(1,6) instead of (3,7). I suspect that means it is in flash mode. I still can't send an AT command (not sure if I should be able to in that mode anyway).

bitartrate

I use the same UART as you; the FTDI FT232RL and I also set it at 3.3v. I use linux also.
I think I see what some of your trouble might be.
instead of crossing rx and tx wire it like this:
BE <--> FTDI
gnd <--> gnd
RX <--> RX
TX <--> TX
RTS <--> RTS
I do not use the DTR; instead I configure 'esptool' command to wait for a reset button push
DTR <--|
GND <--| (i.e., I have the DTR pin on the BE connected to a GND pin to pull it down so it goes into flash mode)

Instead of using 'esptool.py' I changed to 'esptool' instead. I did note that 'esptool.py' was finicky sometimes.

Also I see you are flashing ttbasic-0.88-alpha.bin which isn't an immediate problem however the latest nightly build has fixed a lot of bugs since the alpha build. The nightly repo is at:
There are three versions of the firmware: the one I use is basicengine-firmware-default-v0.88-alpha-678-g1dd9.tar.gz
The version that supports NETworking (I never tried it): basicengine-firmware-net-v0.88-alpha-678-g1dd9.tar.gz
BASIC Engine has an X86 emulator running in linux and it is very good: basicengine-hosted-x86_64-v0.88-alpha-678-g1dd9.tar.gz

There is also an SDL version of the BASIC Engine emulator which is so much more than the X86 hosted version. One must compile the source code and target for SDL version.
Just in case here is the github page for the firmware source code:

Back to the flashing 😉

For comparison sake the command you posted is:
python esptool.py -c esp8266 -b 921600 -p /dev/ttyUSB0 write_flash 0x00000000 ttbasic-0.88-alpha.bin

My command is as follows: (on my linux install I did not use 'python' with 'esptool.py' however this could be a difference in the packager I found for python.

esptool --port /dev/ttyUSB0 --baud 921600 --before no_reset write_flash --flash_mode qio --flash_size=detect --flash_freq 80m 0 firmwarever678.bin

Note: the --baud set at 921600 is just wishful thinking 😉 and esptool will change it to 115200 baud

I used to use: esptool.py --port /dev/ttyUSB0 --baud 115200 --before no_reset write_flash --flash_size=detect -fm dio 0 firmwarever678.bin

I wonder if setting 'esptool.py' with --baud 921600 will cause problems or not?

Keep us posted about your progress

bitartrate

Hmm, well the 'add a link' icon doesn't work
The links I meant to embed are:
Nightly firmware builds: https://basicengine.org/git_builds/
Github source code: https://github.com/uli/basicengine-firmware

Maybe HTML will work?
"" <a href="url">link text</a> ""

<a href=" https://basicengine.org/git_builds/">Check out BASIC Engine Nightly Builds</a>
<a href="https://github.com/uli/basicengine-firmware">BASIC Engine Github page</a>

🤔 I wonder if I know anything about HTML?

jdoolin

Still no luck and I'm getting the same error (waiting on packet header). Here's what I did.

I now have only 4 duponts connecting the UART and the BE.
BE<-->UART
GND<-->GND
RTS<-->RTS
RX<-->RX
TX<-->TX

I am trying with two different BE boards and I've done a loopback test on the UART. I've done as much continuity testing as I know how to do to check the ESP pins, the header and even the UART.

I downloaded the latest build, so I'm flashing that. Kinda curious about the one with net support, so maybe I'll put that on my second board.

I used pip to install esptool instead of using the one in Uli's ttbasic scripts directory. I think the absence of the '.py' extension just depends on packaging. Using pip on Debian installs the script with the extension. I used the following command:

esptool.py --port /dev/ttyUSB4 --baud 115200 --before no_reset write_flash --flash_size=detect -fm dio 0 ttbasic.bin

Here's my procedure:

Connect UART to BE
Plug in the UART to laptop
Plug in the BE to laptop USB port (I also tried a good quality Samsung wall adapter, thinking maybe power was a problem)
Run the esptool command
Press the reset button (I've tried at various times during the process)

The blue LED on the esp doesn't flash at all during the process, even when pressing the reset button (I'm not sure if I should there anyway), but it does flash twice quickly when the process completes and fails.

Am I looking at a bad solder joint somewhere? On BOTH boards?

jdoolin

Well, something interesting happened. I decided to try a different FT232RL module. I hooked it up, ran esptool and when I hit the Reset button on the BE, I got really encouraged for a moment! This was my output:

Connecting........____
Detecting chip type... ESP8266
Chip is ESP8266EX
Features: WiFi
Crystal is 26MHz
MAC: 50:02:91:78:fd:c4
Uploading stub...

A fatal error occurred: Failed to write to target RAM (result was 0107)

So it almost looked like it was going to upload. But then I saw something curious. I had accidentally wired it wrong. I had BE(DTR) connected to UART(RTS).

After more experimenting. This time i connected BE(DTR) to BE(GND). It seems like it's trying to upload.

esptool.py --port /dev/ttyUSB4 --baud 921600 --before no_reset write_flash --flash_mode qio --flash_size=detect --flash_freq 80m 0 ttbasic.bin
esptool.py v2.8
Serial port /dev/ttyUSB4
Connecting....
Detecting chip type... ESP8266
Chip is ESP8266EX
Features: WiFi
Crystal is 26MHz
MAC: 50:02:91:79:5e:2e
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 921600
Changed.
Configuring flash size...
Auto-detected Flash size: 4MB
Flash params set to 0x004f
Compressed 478192 bytes to 327294...
Writing at 0x00000000... (5 %)
A fatal error occurred: Failed to write compressed data to flash after seq 0 (result was C100)

jdoolin

I found the problem and successfully flashed one BE.

It was not one, but TWO bad UARTs. The first one wouldn't talk at all. The second one got a variety of errors as I showed above. It was very inconsistent. The third one worked on the very first try. Engine BASIC is loaded and running just fine.

Downside: I'm pretty sure I fried one of my ESP8266 modules by accidentally connecting DTR to 5V (I meant to connect it to GND). As I understand, they aren't very tolerant of high voltages, and it's just not responding at all now. Not even a blink.

So, new topic: any tips on desoldering that ESP module?

bitartrate

jdoolin What bad luck. I am glad you have one up and running now. On desoldering the ESP8266 I think I would start with a solder sucker on each connector which probably wont finish the job. Then use a desoldering braid to try and wick up the remaining solder. If that doesn't free it then a hot air blower would finally free it.