Very strange behaviour UNO+WiFi ATmega328+ESP8266 - solved but not understood

Hi guys, I frequently use the UNO+WiFi R3 ATmega328P+ESP8266 board which I usually order via AliExpress. I dare to say that I have quite some experience with them and I am also happy with them. Couple of days ago I got a delivery of 10 pieces but programming them was a frustrating event as they all showed the same behavior: The ESP programming went uneventful but all 10 cards reported the well known error 'avrdude: stk500_recv(): programmer is not responding...' when doing the UNO part. Two days of troubleshooting changing cables, host of the IDE (Linux, OS X, Win10), cleaning DIP switches, etc... did not produce any progress.

Finally, as last attempt before ditching the cards, I decided to re-burn the bootloader using a generic UNO as programmer exactly as described in https://www.arduino.cc/en/Tutorial/BuiltInExamples/ArduinoISP and the Chinese cards as target. This generated initially an USB-link error and I stopped for the day. While stopping I discovered that having pins 10 and 13 of the programmer (=UNO) connected as dead (=unpowered) loads to pins RST and 13 of the target board (=Chinese board), supported successful programming of all ten boards.

Reverting back to the standard set-up for programming, the 'programmer not responding' error was back again. In my happiness, I forgot to test whether an ohmic load on the two pins would also ensure successful programming. But I verified that both pins and no more or less need to be loaded for good programming.

Has somebody made a similar experience and/or understands why loading the pins D13 and RST makes the programming error disappear? I would like to understand the physical background of this behavior. Thanks for your help in advance.

it looks like they flashed a corrupted bootloader to a batch of boards

Thanks, but a new boot loader this does not seem to be the only issue. I successfully burnt a new loader but to no avail. Error 'programmer not ....' did not go away.

My strange process appears to have a success rate of 75% but no clue why a (voltmeter) measured voltage of 3.3 V on RST and 0.3V on pin 13 seems to cure the uploading problem.

This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.