Merge branch 'TvEmaster' into EMS-Link

* TvEmaster:
  update readme with esp8266 flashing info
  improve optiboot sync
pull/95/head
susisstrolch 9 years ago
commit 7df1e3266c
  1. 19
      README.md
  2. 46
      esp-link/cgioptiboot.c

@ -360,8 +360,8 @@ it starts the connection with the `?\r\n` synchronization sequence.
### Flashing an attached esp8266
(This is not well tested, more details forthcoming...)
Yes, you can use esp-link running on one esp8266 module to flash another esp8266 module!
Yes, you can use esp-link running on one esp8266 module to flash another esp8266 module,
however it is rather tricky! The problem is not electric, it is wifi interference.
The basic idea is to use some method to direct the esp8266 flash program to port 2323 of
esp-link. Using port 2323 with the appropriate wiring will cause the esp8266's reset and
gpio0 pins to be toggled such that the chip enters the flash programming mode.
@ -378,6 +378,21 @@ Another option is to use a serial-to-tcp port forwarding driver and point that t
of esp-link. On windows users have reported success with
[HW Virtual Serial Port](http://www.hw-group.com/products/hw_vsp/hw_vsp2_en.html)
Now to the interference problem: once the attached esp8266 is reset it
starts outputting its 26Mhz clock on gpio0, which needs to be attached to
the esp8266 running esp-link (since it needs to drive gpio0 low during
the reset to enter flash mode). This 26Mhz signal on gpio0 causes a
significant amount of radio interference with the result that the esp8266
running esp-link has trouble receiving Wifi packets. You can observe this
by running a ping to esp-link in another window: as soon as the target
esp8266 is reset, the pings become very slow or stop altogetehr. As soon
as you remove power to the attached esp8266 the pings resume beautifully.
To try and get the interference under control, try some of the following:
add a series 100ohm resistor and 100pf capacitor to ground as close to
the gpio0 pin as possible (basically a low pass filter); and/or pass
the cable connecting the two esp8266's through a ferrite bead.
Debug log
---------
The esp-link web UI can display the esp-link debug log (os_printf statements in the code). This

@ -10,9 +10,9 @@
#include "serbridge.h"
#include "serled.h"
#define SYNC_TIMEOUT 3600 // to achieve sync on initial baud rate, in milliseconds
#define SYNC_INTERVAL 25 // interval at which we try to sync
#define BAUD_INTERVAL 400 // interval after which we change baud rate
#define SYNC_TIMEOUT 4800 // to achieve sync, in milliseconds
#define SYNC_INTERVAL 77 // interval at which we try to sync
#define BAUD_INTERVAL 600 // interval after which we change baud rate
#define PGM_TIMEOUT 20000 // timeout when sync is achieved, in milliseconds
#define PGM_INTERVAL 200 // send sync at this interval in ms when in programming mode
@ -29,7 +29,9 @@
static ETSTimer optibootTimer;
static enum { // overall programming states
stateSync = 0, // trying to get sync
stateSync = 0, // trying to get initial response
stateSync2, // trying to get in sync
stateSync3, // trying to get second sync
stateGetSig, // reading device signature
stateGetVersLo, // reading optiboot version, low bits
stateGetVersHi, // reading optiboot version, high bits
@ -525,10 +527,15 @@ static void ICACHE_FLASH_ATTR optibootTimerCB(void *arg) {
serbridgeReset();
// no point sending chars if we just switched
} else {
uart0_write_char(STK_GET_SYNC);
//uart0_write_char(STK_GET_SYNC);
uart0_write_char(CRC_EOP);
uart0_write_char(CRC_EOP);
}
break;
case stateSync2: // need one more CRC_EOP?
uart0_write_char(CRC_EOP);
progState++;
break;
case stateProg: // we're programming and we timed-out of inaction
uart0_write_char(STK_GET_SYNC);
uart0_write_char(CRC_EOP);
@ -568,7 +575,8 @@ static void ICACHE_FLASH_ATTR optibootUartRecv(char *buf, short length) {
// dispatch based the current state
switch (progState) {
case stateSync: // we're trying to get a sync response
case stateSync: // we're trying to get a sync response
case stateSync3: // we're trying to get a second sync response
// look for STK_INSYNC+STK_OK at end of buffer
if (responseLen > 0 && responseBuf[responseLen-1] == STK_INSYNC) {
// missing STK_OK after STK_INSYNC, shift stuff out and try again
@ -576,12 +584,18 @@ static void ICACHE_FLASH_ATTR optibootUartRecv(char *buf, short length) {
responseLen = 1;
} else if (responseLen > 1 && responseBuf[responseLen-2] == STK_INSYNC &&
responseBuf[responseLen-1] == STK_OK) {
// got sync response, send signature request
progState++;
// got sync response, send more...
os_memcpy(responseBuf, responseBuf+2, responseLen-2);
responseLen -= 2;
uart0_write_char(STK_READ_SIGN);
uart0_write_char(CRC_EOP);
if (progState==stateSync) {
// need to deal with odd-even sync issue, send one more to see whether we get a response
uart0_write_char(CRC_EOP);
} else {
// got clean sync, send request to get signature
uart0_write_char(STK_READ_SIGN);
uart0_write_char(CRC_EOP);
}
progState++;
armTimer(); // reset timer
} else {
// nothing useful, keep at most half the buffer for error message purposes
@ -592,6 +606,18 @@ static void ICACHE_FLASH_ATTR optibootUartRecv(char *buf, short length) {
}
}
break;
case stateSync2: // we're trying to actually get in sync
if (responseLen > 1 && responseBuf[responseLen-2] == STK_INSYNC &&
responseBuf[responseLen-1] == STK_OK) {
// got sync response, send signature request
os_memcpy(responseBuf, responseBuf+2, responseLen-2);
responseLen -= 2;
uart0_write_char(STK_READ_SIGN);
uart0_write_char(CRC_EOP);
progState = stateGetSig;
}
armTimer(); // reset timer
break;
case stateGetSig: // expecting signature
responseLen = skipInSync(responseBuf, responseLen);
if (responseLen >= 5 && responseBuf[0] == STK_INSYNC && responseBuf[4] == STK_OK) {

Loading…
Cancel
Save