SparkFun Forums

[Mars]

Hardware: sparkfun esp8266 thing. Tried to reflash using the NodeMCU flasher and the two bin files for the shield in the Github to get the "thing" to be a "shield". I grounded GPIO0 during the flash, and the flashing looks successful per the flasher tool. When I try to connect to the thing, using the Arduino UNO demo, I get the "looping forever". I then removed the UNO and used a terminal program to try to talk to the thing. After reset at 74880 baud, I get the rst 2 and boot mode (3,7) message which I have seen interpreted as the reset was an external reset (correct) and the boot mode is correctly from flash.
However, no other communications.

I believe it is a problem with the .bin files in Github (which are the QC production files per the description). My reasoning for this conjecture: I used the exact same sequence/method with the NodeMCU tool to flash the lua interpreter into the thing and it works perfectly. I have flashed an AI-thinker "AT" interpreter into the thing using the same tool and process and it works perfectly. The other observation which I am not sure is relevant is that the two successful loads (lua and AT) resulted in the GPIO0 pin *not* outputing the 26MHz clock, only a static level.

I have found at least two other Sparkfun users on the web trying to use the shield .bin files and having what look like

identical issues. I have tried reversing which of the two bin files goes to 00000 and which to 40000 just in case that was the issue and no difference in result. Of course, I have tried this multiple times and I completely flummoxed. TIA for any insight.

[Mars]

OK, I finally got the Sparkfun Wifi shield firmware flashed into the Thing board. I need to repeat the process to make sure this is not a
total fluke. The trick was to use a different flash tool. The sparkfun support page indicates to use the NodeMCU flasher. I could not, despite multiple tries (I mean MANY) to get the chip to work. The strange part is that the NodeMCU flashtool worked great to flash a LUA interpreter as well as a AI-Thinker AT command firmware. So what worked? Using the Expressif Flashtool, for whatever reason. Like I say, this may be a fluke...what possibly could cause the NodeMCU flashtool screw up on the shield bin load but not on two other loads?

I will probably not tempt fate (at least for a while) and try to reflash to confirm that this is the issue. On to getting the demo SW on the arduino to work. Can anyone make senses of this weirdness? Thanks.

[Mars]

Back again with more info (but no success (sigh).

I have established using my trusted Pico USB Oscilloscope (what a nice product!) that the esp8266 thing flashed as a "shield" is receiving an "AT" command from the Uno running the shield demo code and is responding back to the Uno with an "AT OK" response. I have painfully traced back into the Uno code and the failure is do to a _serial->available returning that the Uno softwareserial buffer has received no characters. I tried substituting the altsoftserial serial code and get the same problem. The esp8266 returns the "AT OK" response in about 1 millisecond after the end of the Uno transmit...could it be that response is happening too quickly relative to the software serial UART? Of course, all of this is at a slow 9600 baud....

I am almost to the point of trying a Arduino mega with a real serial port....

[Mars]

I think it is all working (but I have been fooled before. So far is the saga, I needed to use a different flash tool to flash the "thing" with the "shield" SW (see the original post for this reply). Then it became clear that the Arduino Shield Demo code was the problem. Then it became clear that it centered around the _serial.available() command in the SparkFunESP8266WiFi. cpp code. Here is a snippet:


int16_t ESP8266Class::readForResponse(const char * rsp, unsigned int timeout)
{
unsigned long timeIn = millis(); // Timestamp coming into function
unsigned int received = 0; // received keeps track of number of chars read

clearBuffer(); // Clear the class receive buffer (esp8266RxBuffer)
while (timeIn + timeout > millis()) // While we haven't timed out
{
//CHANGED FROM softwareserial to altsoftserial, though not clear that was critical
//if (_serial->available()) // If data is available on UART RX **CHANGED TO DIRECT CALL TO .available
if (swSerial.available() >= 1); //changed to >= 1
{
received += readByteToBuffer();
if (searchBuffer(rsp)) // Search the buffer for goodRsp
return received; // Return how number of chars read
}
}

if (received > 0) // If we received any characters
return ESP8266_RSP_UNKNOWN; // Return unkown response error code
else // If we haven't received any characters
return ESP8266_RSP_TIMEOUT; // Return the timeout error code
}

I substituted the AltSoftSerial soft UART for the Softwareserial UART code. This may not be needed...I never undid this and retested. Then (see the code snippet) called swSerial.available() directly and compared it to >= 1. This seems to work. The looping forever is over and the code progresses into the client/server dialogue. I know there are a few people out there who have or are dealing with the same problem. Can someone from Sparkfun at least read this and comment?

[Mars]

Well, hat in hand and after serving myself a coffee and a big wedge of humble pie, I come to report that I was plagued by two problems. One was the problem getting the "thing" flashed as a wifi shield which seemed to be resolved by using the expressif flashtool. The other appears to be self inflicted...basically an intermittent crimp on the cable that connected to the Uno. During troubleshooting with the o-scope, I chose a convenient place to grab the Rx/Tx signals...however, the intermittent connection was between that point and the Uno. That is why I was driven nuts by the serial.available and jumped to conclusion that the problem was the SW...oops. Well, on the bright side, I learned a lot of arduino cpp code. Peace.

[Mars]

Well, hat in hand and after serving myself a coffee and a big wedge of humble pie, I come to report that I was plagued by two problems. One was the problem getting the "thing" flashed as a wifi shield which seemed to be resolved by using the expressif flashtool. The other appears to be self inflicted...basically an intermittent crimp on the cable that connected to the Uno. During troubleshooting with the o-scope, I chose a convenient place to grab the Rx/Tx signals...however, the intermittent connection was between that point and the Uno. That is why I was driven nuts by the serial.available and jumped to conclusion that the problem was the SW...oops. Well, on the bright side, I learned a lot of arduino cpp code. Peace.