ESP8266 Community Forum

This is similar to a problem posted several other times, never resolved.
I connected an ESP01 to a CH340 USB interface cable and was able to communicate with the device, connect it to my network, etc. I then changed the baud rate to 9600 to use with an Arduino (AT+IFR=9600). After changing the baud rate, I was able to communicate with the device after resetting the baud rate of the serial monitor.

I then wired the device into an Arduino circuit (using a voltage divider on the input to RX to drop the voltage to 3.3V). Nothing worked. I then went back to the USB interface cable and finally found the device booting at 74880, but it doesn't boot to the AT command processor. I get this:

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

load 0x40100000, len 816, room 16
tail 0
chksum 0x8d
load 0x3ffe8000, len 788, room 8
tail 12
chksum 0xcf
ho 0 tail 12 room 4
load 0x3ffe8314, len 288, room 12
tail 4
chksum 0xcf
csum 0xcf

2nd boot version : 1.2
SPI Speed : 40MHz
SPI Mode : QIO
SPI Flash Size : 4Mbit
jump to run user1


S

After that, I can't get the device to respond to anything at any baud rate (or at least not 9600, 19200, 38400, 74880, 115200).

The device is clearly not dead, but what happened to the AT command processor?

According to some other posts I've found elsewhere, the problem is that the AT+IFR command will brick the firmware. Do not use AT+IFR to change the baud rate, use AT+UART_DEF. I was fooled by the AT+IFR because I could set the new baud rate, reset my terminal emulator to the new baud rate, and everything looked cool. But as soon as you power cycle the device, it's toast.

Oh boy! Why is it so hard to change baud rate with the AT commands?
I tried AT+CIOBAUD as documented - got only error response.
Found this post viewtopic.php?f=13&t=718 that says use AT+IPR
The document that that post points to no longer mentions AT+IPR.
I have not previously heard of AT+IFR.
I used AT+IPR apparently successfully, but got the same result as Llaves; after reboot, can't communicate at all.
(Described here: viewtopic.php?f=160&t=13082 )

I've also found this post http://arduino.stackexchange.com/questi ... ermanently
which claims that you can unbrick an ESP from this state via instructions here: https://developer.mbed.org/users/sschoc ... 6-Firmware
Personally, I don't see how that can work, as it's trying to send new firmware, for which you surely need to have comms working in the first place. Also, it's a Windows thing, and I'm pure Linux. But I mention it here in case anyone else can make use of it.