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

Un-Borking a module? #855

Closed
vicatcu opened this issue Oct 4, 2015 · 12 comments
Closed

Un-Borking a module? #855

vicatcu opened this issue Oct 4, 2015 · 12 comments

Comments

@vicatcu
Copy link

vicatcu commented Oct 4, 2015

Hey guys,

I'm not sure what happened, but whenever I upload a sketch now, even though it says "Done Uploading" without any errors, when I put it into back into Flash bootmode and reset the unit, all it does is spew garbage out the Serial port. I've tried every possible baud rate in the IDE, but there's no baud rate that results in legible English ASCII output. Looking at the output with a scope I'm seeing what appears to be a 13.34us bit time, which would be like 75kbaud.

The last thing I did before I noticed this happening was load this sketch:

void setup() {
  // put your setup code here, to run once:
  delay(1000);
  Serial.begin(115200);
  Serial.print(F("Flash Chip Size By Id: "));
  Serial.println(ESP.getFlashChipId());
}

void loop() {
  // put your main code here, to run repeatedly:

}

And the one time I got an output before that using getFlashChipSizeByChipId it returned printed 0. Anyone seen anything like this happen before? How to recover? I should mention I was also using the staging release (version 1.6.5-1160-gef26c5f) installed via Boards Manager. Also tried changing to the stable release, same results. What the heck did I do?

@vicatcu
Copy link
Author

vicatcu commented Oct 4, 2015

So, I went over to Windows and used flash_download_tool_v1.2_150512 from the SDK and loaded:

  • AT_bin_v0.25_for_512KB_flash_cannot_upgrade\eagle.flash.bin @ 0x00000
  • AT_bin_v0.25_for_512KB_flash_cannot_upgrade\eagle.irom0text.bin @ 0x40000

I'm using an ESP-WROOM-02module. The Flash Download tool outputs this stuff:

flash vendor:
A1h : FM
flash devID:
4016h
QUAD;32Mbit
crystal:
26 Mhz

After loading that stuff, it still spews junk to the console, but it's actually something like 115200 baud (based on scope measurement of bit time) and if I scan the output (most of it is still nonsense text), I see "C MEM CHECK FAIL!!!" being output occasionally. Is this ringing a bell for anyone?

@vicatcu
Copy link
Author

vicatcu commented Oct 4, 2015

Seems pretty similar to #95

@vicatcu
Copy link
Author

vicatcu commented Oct 4, 2015

Yup 77400 output read:

load 0x4010f000, len 1264, room 16
tail 0
chksum 0x42
csum 0x42
~ld

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

... over and over again ... still not sure what I'm supposed to do to recover from this situation after reading through issue #95?

@vicatcu
Copy link
Author

vicatcu commented Oct 4, 2015

Based on issue #95, I grabbed the latest esptool from here and tried running:

python esptool.py --port COM3 --baud 76800 erase_flash

Right after doing that, and switching the boot mode back to Flash and brought up a PuTTY console at 77400, and got this output:

 ets Jan  8 2013,rst cause:1, boot mode:(3,7)

ets_main.c

And after loading a sketch with the Arduino IDE, it goes back to reading boot mode (3, 6) as above.

This would seem to imply that my boot mode is incorrectly set? So looking at the GPIO0 pin with a scope, what I see is something like a sine wave at 26MHz, min 0.94mV, max 2.98V. It's pulled up to 3.3V through a 10k pull-up, is that too weak? When I connect GPIO0 to GND directly (for UART load), I see a 26MHz waveform, min -420mV, max +420mV on the scope. FWIW I'm powering the board with a bench-top PSU @ 7.5V, linear regulating it down to 5V, then linear regulating the 5V to 3.3V which is what the ESP8266 is running from.

@vicatcu
Copy link
Author

vicatcu commented Oct 4, 2015

So I tried connecting GPIO0 to 3.3V directly, and then to GND directly, this is right after doing the flash erase with esptool.py.

The output when I connect GPIO0 to 3.3V is:

 ets Jan  8 2013,rst cause:1, boot mode:(3,7)

ets_main.c

The output when I connect GPIO0 to GND is:

 ets Jan  8 2013,rst cause:1, boot mode:(1,7)

Then loading a trivial sketch using the Arduino IDE...

The output when I connect GPIO0 to 3.3V is (repeatedly):

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

load 0x4010f000, len 1264, room 16
tail 0
chksum 0x42
csum 0x42
~ld

The output when I connect GPIO0 to GND is (still):

 ets Jan  8 2013,rst cause:1, boot mode:(1,7)

@vicatcu
Copy link
Author

vicatcu commented Oct 4, 2015

.... and I'm out of ideas for now ... 🎱

@Links2004
Copy link
Collaborator

I have seen simulate problems with a damaged flash.
can you dump the SPI flash with external hardware and compare it to the bin file you download?

@vicatcu
Copy link
Author

vicatcu commented Oct 5, 2015

Downloaded esptool on Ubuntu, appears to be something very messed up (no surprise here).

python esptool.py --port /dev/ttyUSB0 flash_id
Connecting...
Manufacturer: a1
Device: a1a1

Suspicious 'a1' everywhere... then did:

./esptool.py dump_mem 0x40000000 65536 iram0.bin

... and using some Bless Hex export magic, that bin has the contents here. Now that means next to nothing to me, but maybe someone else can glean insight from that?

@Links2004
Copy link
Collaborator

you have dumped stuff from the RAM.
for flash use:

./esptool.py read_flash <address> <size> <outFile>

when the flash is OK you will get the exact same binary like the compiler will build.
the read_flash is not fast it will take some time. if the compare is not the same you flash chip is defective and need to be re-pleased.

it goes a lot faster it you have access to something like a CH341A USB Programmer,
in combination with a SOIC clip you not need so solder.

@vicatcu
Copy link
Author

vicatcu commented Oct 6, 2015

@Links2004 Yea I did the read_flash and compared it to the bin generated by the build process and they matched. I think we probably should just chalk this up to "mysterious ESD goblins" and close the issue. If it comes up again we can re-open it. If I'm the only one who has seen this happen, it's not a real issue.

@vicatcu vicatcu closed this as completed Oct 6, 2015
@Cieszlunek
Copy link

Cieszlunek commented Jan 9, 2018

Hi there. I know I'm late with answer, but maybe I'll help someone else who is looking for answer:
Issue is related to voltages missmatch on line ESP RX -> UART TX. ESP RX accepts 3.3V, but UART produces 5V. So it's needed some voltage reduction, i.e. by using two resistors R1 = 4.7k and R2 = 10k.
Connection: ESP RX -> R2 (connected to mass) -> R1 -> UART TX
image

@mharmon12
Copy link

I got this.
so when you see,
ets Jan 8 2013,rst cause:1, boot mode:(1,7)

That means you are in program mode.

Remember, the GPIOs are internally tied high on ESP-01(s)
To get there:
GPIO-2 (RST=Reset) to GND
GPIO-0 to GND (Program/Flash mode pin)
Reset off
GPIO-0 off

So you are ready to flash! :)

After flash remove the jumper from GPIO-0
Then reset by cycling power or touching Reset to GND momentarily.

Now when you reset then baud rate is 74880 odd value.
You'll see the memory status and a little garbage at the end.

Setting buad rate to 115200 and then resetting will now print that same memory dump (it will look like junk) then Ready at the bottom.

Send AT to put into AT mode
and then send AT+GMR to see the current AT version and such.

You will not see any AT messages or ready IF you flash over it with your own binary or Arduino Sketch.

One last note, you NEED to make sure to have a robust 3.3 or if you can adjust to 3.6 BUT that is only if you are having issues flashing.

Good luck and have fun!
MIKE

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants