SerialNINAPassthrough + esptool in UNO WiFi rev2 = won't connect. Write Timeout

[gvJaime]

Hello.

I'm trying to load the compiled firmware to the Arduino UNO WiFi rev2, making use of esptool + SerialNINAPassthrough script, which as I understand, boots up the NINA in recovery mode, waiting for a binary to arrive via serial (pretty much the same as in the obsolete "UNO WiFi DEV Ed".

The thing is that I've been trying such communication for a week and it never works. I always get:

esptool.py v2.6
Serial port /dev/ttyACM0
Connecting......
Traceback (most recent call last):
File "/home/gvJaime/.platformio/packages/tool-esptoolpy/esptool.py", line 2959, in <module>
_main()
File "/home/gvJaime/.platformio/packages/tool-esptoolpy/esptool.py", line 2952, in _main
main()
File "/home/gvJaime/.platformio/packages/tool-esptoolpy/esptool.py", line 2653, in main
esp.connect(args.before)
File "/home/gvJaime/.platformio/packages/tool-esptoolpy/esptool.py", line 460, in connect
last_error = self._connect_attempt(mode=mode, esp32r0_delay=False)
File "/home/gvJaime/.platformio/packages/tool-esptoolpy/esptool.py", line 440, in _connect_attempt
self.sync()
File "/home/gvJaime/.platformio/packages/tool-esptoolpy/esptool.py", line 379, in sync
timeout=SYNC_TIMEOUT)
File "/home/gvJaime/.platformio/packages/tool-esptoolpy/esptool.py", line 322, in command
self.write(pkt)
File "/home/gvJaime/.platformio/packages/tool-esptoolpy/esptool.py", line 285, in write
self._port.write(buf)
File "/usr/lib/python2.7/site-packages/serial/serialposix.py", line 552, in write
raise writeTimeoutError
serial.serialutil.SerialTimeoutException: Write timeout
*** [upload] Error 1

Also comms seem really glitchy from the serial monitor in the arduino IDE, here is an example:

ets Jun  8 2016 00:22:57

rst:0x1 (POWERON_RQ⸮�U⸮I⸮⸮⸮⸮0x23 (ets Jun  8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x23 (DOWNLOAD_BOOT(UART0/UART1/SDIO_REI_REO_V2))
waiting for download

Such glitches appear at random, and they seem to get worse with the temperature of the room. Freezing the board does make the glitches dissapear, but you still get the write timeout.

Is this a production issue, or am I missing some detail here? I have two boards with the same problem.

[facchinm]

Hi @gvJaime ,
the UNO Wifi rev2 needs a little tweak in the commandline to use esptool, since the onboard debugger resets the 4809 when DTR is asserted (the normal esp32 "autoreset" phase) 😓 .
The right commandline resembles

esptool.py --chip esp32 --port /dev/ttyACM1 --baud 115200 --before no_reset --after hard_reset write_flash -z --flash_mode dio --flash_freq 40m --flash_size detect 0x1000 .....

(note the --before no_reset flag).

About the wrong characters / frequency drift, make sure you are using the latest SerialNINAPassthrough example and latest megaAVR core .
Let me know if it works!

[gvJaime]

I'm using the SerialNINAPassthrough that is provided by the latest (1.8.9) arduino IDE version. I'm using yours now which I presume is the same, but the results are the same. The megaAVR core was 1.8.2.

I figured the no_reset flag out later in the afternoon I wrote this issue. When used, it connects. So the core matter of this issue is solved and therefore it could be closed.

...but

After connecting I run into a quite diverse collection of errors that halt the upload in different stages of the process. Featuring:

A fatal error occurred: Invalid head of packet (0x21)

A fatal error occurred: Timed out waiting for packet header

A fatal error occurred: MD5Sum command returned unexpected result: '\x96/~\x90sM\xfe\x1b\xf4\x08$\xa5f%'

A fatal error occurred: Failed to write to target RAM. Only got 3 byte status response.

And, sometimes, a successful upload. Which makes me think that this is a result of the "gibberish" I get in the serial monitor.

This gibberish doesn't only affects the comms with the ESP32, but the ATMega4809 as well. Serial comms get pretty unstable when you go over 115200 baud. (Difficulty connecting, gibberish...etc.) Compiling with the new megaAVR 1.8.3 doesn't make it better. Configuring the Serial interface without the arduino core, in c, yields the same results.

Some days ago I was wrestling with this problem, and suspecting that it was a physical contact failure, I had the desperate idea of putting the board in the freezer for 1h.
The comms were perfectly stable while the board was frozen, and they gradually deteriorated as it heated to room temperature again. Is there a possibility that this batch came with soldering issues? I have experienced this in the two UNO WiFi rev2 boards I own.

[gvJaime]

Just tested putting an ice cube underneath the board and it works like a charm. Sketchy solution, but it works indeed.

[facchinm]

Hi @gvJaime ,
thanks for the long explanation (and for the "workaround"). It looks like one chip's (the 4809 or the ESP32) clock is drifting a lot. From my previous experience it's more likely to be the ESP32, but its drift is usually compensated by the not-so-picky usb-to-serial converter it comes with (we measured something like ~119000 bps at room temperature when setting it at 115200).
One software workaround can be trying to change the SerialNiNa baud rate in the 115200 - 120000 range and check if it behaves better.
I'll try reproducing here anyway; which temperature range are we talking about? 30 degrees?

[gvJaime]

Hello @facchinm

I doubt is a thing of the ESP32, because communications with the ATMega4809 are very dirty as well.
Oftentimes, uploading the sketch to the board causes a "bad command 0xa0" error loop (cannot really copypaste it properly right now). Will try the baud shift tomorrow.

Regarding the temperature, I'm talking about cooling the area around the ATMegas at like, 10ºC. My room temperature, the day I started researching this, was around 30ºC. I didn't make a measure of this so these figures are orientative. Let's say that the communications work when that area is cool to the touch.

[facchinm]

@gvJaime it looks like the boards has some serious hardware issues (the bad command 0xa0 output comes from the USB-to-serial converter, which is also a full fledged programmer and only interacts with the ATMega4809 debugging hardware when programming).
Just to make a test (in case the issue is silicon related, could you apply this patch to the core and report if you see any improvement? Thanks!

[gvJaime]

Sorry for the delay, I've been out for vacation.
I just came back. When I'm finally settled, I'll apply the patch and give feedback. I'm unsure on how to apply it locally though, as I don't use the framework in the context of a git repo but rather the regular Arduino installation.
I can do it manually though, as it is not a big patch.

[gvJaime]

Well I added the patch manually and it worked perfectly on the first try. Loading onto ATMega4809 and thru loading into the ESP32 worked perfectly at room temperature... but I only made the first try.

I haven't tested this for resilience. Hopefully this afternoon I'll be able to play around with the board and make many, many attempts at this. I will report when this happens.

I'll leave to you @facchinm , the decision to close this issue if you see fit. I hope I can report a good testing so you can confidently merge the pull request related to this issue.

[facchinm]

@gvJaime thanks A LOT for trying this with a problematic board. I'm way more confident now about merging it.

Would you comment on the PR itself after you are able to perform some more testing? Thanks!

[gvJaime]

So! I've been fiddling with it for a while, and:

• Loading onto the ATMega4809 works somewhat reliably. It only gave me the bad command 0xa0 once.
• Loading onto the ESP32 through the SerialPassthrough it's still an adventure. Right now I've been trying 20 times with no success. And only when I blow air onto the board, it seems to improve... somewhat. You have to be consistent with air because if you take a break and it heats up, you get an error mid-upload. You'd get one of the miscellaneous errors seen above.

The only consistent fix I've found for this issue is an icecube.

[gvJaime]

Also, I must clarify that the upload speed I selected for uploading onto the ESP32 is 115200, because the default 921600 that the arduino IDE tries wasn't working. Maybe by changing the baudrate I circumvented the fix in some way?

Should I just copy my previous message onto the PR?

[facchinm]

Hi Jaime, thanks for testing! I think I'm merging the PR even if it didn't really fix your issue.
I'd recommend you to write to support linking this thread to get a replacement board since 0x0a issues are totally unexpected and I'd like to deeply analyze your actual board.

[MarioG1]

I tried flashing the NINA on my UNO WiFi rev2 with the latest version of SerialNINAPassthrough and if worked without any problems.