Tasmota Arduino Client flashing doesn't seem to work

[kobuki]

I thought I'd make my life a bit easier by deploying an ESP32 with Tasmota along with the Arduino-based mote i'm developing a sensor with (a Moteino, which is technically the same as a Pro Micro with extras and extra care for low power operation) to aid in developing a new sensor that I can only test outdoors. So I connected the two, first tried the TCP-serial bridge (baud rate: 115200), working fine, all good. Then I compiled a custom firmware using the settings for Tasmota Client here. Compiled fine, Tasmota reports via debug messages that the driver is active, using UART2 (ports: GPIO 25, 26, 27 for RX, TX and RST). All good.

Now the problem: for the life of me I can't get it to flash the mote. I upload the .hex using the firmware update function as instructed by the docs, but it always fails with Upload error 301. Weirdly enough, it also says that it's switching to Safeboot, which is standard for flashing a normal Tasmota FW. It doesn't switch, though, maybe because the upload fails. I can tell that the Arduino reset is not really functioning, based on how the LED on the Moteino flashes when trying to upload. Maybe the client driver has a bug that doesn't reset the attached device properly? Or it needs the Tasmota client flashed on the Moteino by other means? I can reset the mote just fine if I configure GPIO 27 as an inverted relay output with PulseTime1 2 and click the standard button on the main page. BTW, normal serial flashing of the part via vsCode/PlatformIO works fine.

Any insight is appreciated.

[arendst]

How about trying the inverted TasmotaClient Reset?

[kobuki]

Yeah, tried that, too. Forgot to mention, sorry. Doesn't work. The mote uses the "usual" Arduino signaling for programming. For the relay-output reset I need to use invert because the reset line needs to be kept high.

[Jason2866]

Remote flashing does only work with the Arduino uno, mini and nano. For all other variants the sketch needs to be flashed directly to the board.

[kobuki]

The Arduino Uno profile in the original Arduino IDE (or in avrdude) can be used to flash the Moteino modules I use so it should work.

[Jason2866]

Try to change the USE_TASMOTA_CLIENT_FLASH_SPEED as written in Tasmota documentation

[kobuki]

Naturally, I adjusted that via user_config_override.h. This module uses 115200 baud for flashing.

My settings:

#ifndef USE_TASMOTA_CLIENT
#define USE_TASMOTA_CLIENT    // Enable the driver
#endif

#ifndef USE_TASMOTA_CLIENT_FLASH_SPEED
#define USE_TASMOTA_CLIENT_FLASH_SPEED 115200    // Configure the baud rate of the bootloader
#endif

#ifndef USE_TASMOTA_CLIENT_SERIAL_SPEED
#define USE_TASMOTA_CLIENT_SERIAL_SPEED 115200    // Configure the baud rate at which the client microcontroller will be interfacing to Tasmota
#endif

[Jason2866]

Try the lower speed. I have modules that need even different settings for serial and flash speed.

[kobuki]

Well, the Moteinos I use can't be flashed at other speeds than 115200 baud, but I tried with 57600. The same happens:

Switching to safeboot partition...

...

Upload Failed
Upload error code 301

Is that code 301 meaningful in any way? Maybe it's an upload protocol timing error? I could try changing something in the driver.

[arendst]

Error 3xx is a TasmotaClient Error.
Error x01 is a timeout as in STK bootloader; Make sure there is a STK bootloader on your Moteinos.

[kobuki]

Error x01 is a timeout as in STK bootloader; Make sure there is a STK bootloader on your Moteinos.

It has one - I can program the mote via PIO or avrdude just fine using serial. As @Jason2866 mentioned, it does look wrong to be switching to safeboot, even though the 3xx messages are supposed to come from the TCL driver, so that driver must be involved in some way.

[Jason2866]

@arendst Seeing switching to safeboot looks wrong.

[arendst]

Fixed in v14.3.0.7

[arendst]

A wrong upload result (caused by wrong RX/TX GPIO's) after a restart:

16:23:31.145 TCL: Serial UART1
16:23:31.153 TCL: Enabled
16:29:25.788 HTP: Main Menu
16:29:27.788 HTP: Firmware Upgrade
16:30:11.270 UPL: File BlinkSendCommand.ino.hex (7966 bytes)
16:30:11.410 CFG: Saved, Count 111, Bytes 4096
16:30:11.426 UPL: File type 4
16:30:11.582 UPL: Transfer 7966 bytes
16:30:24.402 HTP: Upload done
16:30:38.236 HTP: Main Menu

And SAYS that it switches to safeboot but that's just a message. It doesn't switch but reports error 301.

A correct upload result after a restart (with correct Rx/Tx GPIO's):

16:31:23.169 TCL: Serial UART1
16:31:23.176 TCL: Enabled
16:31:24.997 TCL: Version 20191129
16:31:27.698 HTP: Firmware Upgrade
16:31:36.211 UPL: File BlinkSendCommand.ino.hex (7966 bytes)
16:31:36.345 CFG: Saved, Count 114, Bytes 4096
16:31:36.362 UPL: File type 4
16:31:36.516 UPL: Transfer 7966 bytes
16:31:36.789 TCL: Found bootloader
16:31:37.654 UPL: Successful 7966 bytes
16:31:37.665 HTP: Upload done
16:31:37.709 SRC: WebGui from 192.168.2.1
16:31:40.522 APP: Restarting

Notice the message 16:31:24.997 TCL: Version 20191129 indicating a good serial connection.

So I would check your GPIO config.

BTW define USE_TASMOTA_CLIENT_FLASH_SPEED is obsolete. Use define USE_TASMOTA_CLIENT_SERIAL_SPEED instead.

[kobuki]

Thanks for looking into it and trying a flash. I swapped the RX/TX config and now it looks like the mote is rebooting into boot loader but then it skips to run the sketch. That's a short-long-short flashing of the LED on these boards. I think the wrong GPIO setup makes the communication impossible. When I use the original GPIO arrangement (25, 26, 27 -> RX, TX, RST), the LED flashes 3 short pulses. I can just assume without deeper debug logs, but I think it enters the boot loader and then a desync occurs at some STK phase. The mentioned pin setup works with the TCP-serial bridge, so it should be OK.

So I guess it's reset -> STK starts -> desync/timeout -> error 301. If 301 is timeout, can I increase that timeout somewhere (C code)? Are you using ESP32? And what Arduino board are you using? I only have some Pro Micros and my custom ATMega328p based boards besides the Moteinos I usually use. I might try the Pro Micros if that makes sense (can also be flashed as Uno). Maybe some timing is different in Tasmota vs. the timing in avrdude which is used by both PIO and the Arduino IDE.

[arendst]

I use a Pro Mini Mega328P 3V3 at 57600 bps.

You'll find precompiled binaries in /tools/fw_TasmotaClient_arduino/ProARmega328P-3V3-8MHz

See source file xdrv_32_tasmota_client.ino function TasmotaClient_Flash() regarding errorcode 1 (which becoms 301)

[kobuki]

Thanks, I'll look into it later.

[kobuki]

I had a look, increased the retry count, but it didn't help. Tweaked the reset pin sequence a bit, but it didn't change anything. Looking at both the Tasmota and the DualOptiBoot bootloader code that the Moteinos use, it should work. STK_GET_SYNC is sent to the target, it responds with STK_INSYNC (with terminator bytes on both ends). At least in code it looks OK, but in reality, it fails. I'd need to debug the actual serial traffic to see where it goes astray. I might try to dig deeper later but I can use a Raspi for the same purpose so it's not a priority at the moment. However, if anyone has more ideas to try before that, I'll gladly test some more.

[kobuki]

Just a fun thing. I left the ESP32 in TCP serial bridge mode with the relay pin as reset. I attempted flashing through it and it was successful, see below. Sometimes this can be an alternative to the Tasmota Client flashing method. Maybe it can be also useful for others.

This is from a Raspberry Pi 4, running RaspiOS/Debian 12. I attempted the same from windows, but it doesn't work, fails with sync error.

~ $ curl 'http://10.11.12.100/?m=1&o=1'; avrdude -p m328p -c arduino -P net:10.11.12.100:22222 -Uflash:w:firmware.hex:i
<img style='display:none;' src onerror="eb('o1').style.background='#1fa3ec';">{t}</table>

avrdude OS error: ioctl("TIOCMGET"): Inappropriate ioctl for device
avrdude OS error: ioctl("TIOCMGET"): Inappropriate ioctl for device

avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 0x1e950f (probably m328p)
avrdude: Note: flash memory has been specified, an erase cycle will be performed.
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file firmware.hex for flash
         with 9914 bytes in 1 section within [0, 0x26b9]
         using 78 pages and 70 pad bytes
avrdude: writing 9914 bytes flash ...

Writing | ################################################## | 100% 15.85 s

avrdude: 9914 bytes of flash written
avrdude: verifying flash memory against firmware.hex

Reading | ################################################## | 100% 15.60 s

avrdude: 9914 bytes of flash verified
avrdude OS error: ioctl("TIOCMGET"): Inappropriate ioctl for device

avrdude done.  Thank you.