TLSR8251 can't read

[bearpawmaxim]

Hi! I'm unsuccessfully trying to dump the stock firmware from Xiaomi SJWS01LM water leak sensor that has a tslr8251 chip.
(I 'm going to write a custom firmware because I don't like how the stock one behaves)
(I'm a newbie to TSLR* chips)

Trying to dump the firmware with the USB-uart converter.
TX wire connected through 1k resistor to SWS/PA<7> (pin 4 on 24-pin package) and RX wire connected to the same SWS pin directly.
RST pin is not connected (because my uart converter doesn't have one)..

The error I'm getting is
Error[102] Read PGM Version and Config!
What am I doing wrong? Thanks for help!

[bearpawmaxim]

Okay, the error means that we're receiving less bytes than expected - will check RX.

[bearpawmaxim]

Added logging to command function and got

Open COM4, 230400 bit/s... ok
Read bytes count less than expected! (6 < 19) bytes: 00 00 00 00 00 24!
Error[102] Read PGM Version and Config!```

[pvvx]

Not all types of USB-UART chips work with Telink Swire emulation.
Only Chinese USB-UARTs. Not FTDI - FTDI filters invalid UART characters...
The RX input of the USB-UART adapter must not have a resistor with an LED.

[bearpawmaxim]

I'm finished with using the stm32f103vet6 at the hardware side and tsltools825x at software side. But even with this sometimes I cannot connect to the MCU (because it is falling asleep?). I think I definitely need to solder the rst pin to be able to use the activation procedure...

[pvvx]

This repository is dedicated to Telink-SWire hardware programmer based on TLSR8269/825x chips... And I don't quite understand your question... Is it about a different type of programmer?

A reset or power-up signal is required to wake the chip from sleep mode.

[bearpawmaxim]

Upd: connected the reset line, but even with this still getting an error Error[102] Read PGM Version and Config!

And I don't quite understand your question...

The question is whether the described in the first post wiring is correct and the reason why I'm getting an error.

P.S.: with ch340g and an stm32-based adapters the result is same - error mentioned above.