Programming sync errors about esp-link HOT 7 CLOSED

Thanks for the detailed report! Can you confirm that you are using v1.0.3 of esp-link?

I've looked at similar traces and tweaked things back and forth. The avrdude sync code leaves a lot to be desired, for example, it doesn't deal with late sync responses coming in, as you've noted. I don't really agree with The first received sequence (0x30;0x20) is sent to the arduino. (It is sent very short after the reset, and can be considered lost in almost all situations because the MCU has not booted yet at this moment) because optiboot does come up in less than a millisecond, if I remember correctly. On the time-scale of your trace that's going to look like "at the same time". There is a delay of 1ms after toggling reset (https://github.com/jeelabs/esp-link/blob/v1.0/serial/serbridge.c#L235), which I thought was enough, but I can try it again myself as well. One thing I'm curious about is the detailed timing between the reset line, the actual reset pin on the arduino (there may be A/C coupling which can delay the rising edge), and the first character arriving.

WRT your overall set-up: there is a timing constant in optiboot which determines how much time the programmer has between an optiboot response and the next programming command. By default this seems to be 500ms and it applies to every single command. If at any point in time the programmer doesn't send the next command within that time-frame the programming sequence ends and the loaded sketch is run. With your long-distance set-up you may well find that it's difficult to meet this constraint reliably. I'm not saying it's impossible, I don't know what your network connectivity is for one, just mentioning it as something to look out for. Actually, since you're already compiling your own version of optiboot you might as well increase this, however it also increases the time optiboot waits at boot before running your sketch, so if you need that to be short then this won't work for you.

In terms of timing, right now esp-link does not interfere in any way with the data transmitted, and I'd like to keep it that way if at all possible. I could increase the initial delay after reset, but if it exceeds ~10ms I need to change the code quite a bit 'cause that starts to interfere with wifi operation.

from esp-link.

With regard to boot time, there are fuse settings that determine how long it takes before the mcu boots (Clock source fuse bits). Typically the fuses are set to the most conservative timing which means at least a 65 ms delay before the mcu boots after a powerup or reset.

65ms is more than a busy-wait will accomodate. This brings me to the question why there is not a prompt reply to the second sync attempt (labeled 3 in your trace).

from esp-link.

The version of esp-link I used is the master tree code at commit f057a65.

Optiboot remarks

Looking at the code of optiboot I notice:

1. The watchdog timer is initialised (optiboot.c line 502) with a timeout value of 1 second. So I assume delay can be up to 1 second (instead of 0.5s)?
2. I was wondering too about the unusual delay of the response.
   It seems the UART is initialised first, next the led flashes in a blocking way and finally the serial response is processed.
   • UART Init (optiboot.c lines 487-499)
   • Start flashing of led (optiboot.c line 516) by calling the blocking function flash_led (optiboot.c lines 808-822) function
   • Processing serial input (optiboot.c lines 520-678)

So this timing issue might be optiboot specific. I'll try with the default arduino bootloader in the weekend to see if it behaves differently.

Reset timing

Currently I only have the logic analyser screenshot (see below), but if you want, I can record it in the analog domain too with my scope. But since you toggle the reset from 1 to 0 and back, the rising edge of the reset should be fine afaik. Just like the 1-0 pulse 'passes' the capacitor, the 0-1 pulse wil also 'pass' the capacitor and quickly restore reset back to a logical 1.

As can be seen on the screenshot above, the reset pulse is low for 0.2091 ms. The time between the end of the pulse and beginning of the serial TX (from ESP to arduino) is 1.124 ms (time between markers A1 and A2 is displayed on the right side of the screenshot).

Remark The reset channel is also measured on the reset pin of the arduino (just like TX and RX) and NOT on GPIO12 of the ESP module.

My network latency

Thanks for the remark about my overall setup. Just to get an idea, I just measured my round trip times.

I have this small serial-echo sketch running on the arduino that is connected to the ESP:

bool led=false;

void setup()
{
  pinMode(13, OUTPUT);      
  Serial.begin(250000);      
}

void loop() 
{
  while (Serial.available()) {
    Serial.write(Serial.read());
    digitalWrite(13, led);
    led=!led;
  }
}

I also have a small perl program running in my remote development environment that repeatedly sends 1 byte of data to the esp-link'ed arduino and waits for the response. Based on those full-loop round trip times I calculated some statistics (based on 10000 rtt measurements):

min       = 0.00993s
max       = 0.65968s
range     = 0.64974s
count     = 10000
mean      = 0.01488s
median    = 0.01415s
stddev    = 0.00932s

So occasionally, there are some outliers up to 650ms, but in general rtt is 14ms with a small standard deviation. An occasional watchdog timeout might happen sometimes, but in general I would not expect it to be a real issue with this setup.

conclusion & questions

Maybe my sync timing issue is mostly caused by the way optiboot blinks the led. I will test the default arduino bootloader during the weekend.

Some questions:

• What bootloader do you use?
• What does avrdude send/receive when you get an error? e.g. Do you also receive a double sync reply (0x14;0x10)?

from esp-link.

FYI, I will work on this and want to say a big thanks for the detailed description. I also use optiboot but I was reminded of the AVR (and PIC) fuses which can delay the start-up time by varying amounts...

from esp-link.

I'm now dropping the first sync bytes sent by the programmer on the floor. Let's see whether this improves things...

from esp-link.

Ok. I'll test it as soon as I got some free time.

from esp-link.

I'm closing this given that the built-in programming support works pretty well at this point.

from esp-link.