Periodic corruption of data over SWire

[badrpc]

I'm trying to read flash of Tuya relay with ZT3L chip. I prepared TB-03F and it seem to be able to communicate with ZT3L chip over SWire except that I'm regularly seeing corrupted data. For example here 2 out of 10 reads of Flash JEDEC ID returned what looks like a complete garbage:

forlond:ols/workshop/zigbee_devices/TLSRPGM % python ./TlsrPgm.py -p COM7 i | grep JEDEC
Flash JEDEC ID: 0x04F9EB, Size: 53919893334301279589334030174039261347274288845081144962207220498432 kbytes
forlond:ols/workshop/zigbee_devices/TLSRPGM % python ./TlsrPgm.py -p COM7 i | grep JEDEC
Flash JEDEC ID: 0xC86014, Size: 1024 kbytes
forlond:ols/workshop/zigbee_devices/TLSRPGM % python ./TlsrPgm.py -p COM7 i | grep JEDEC
Flash JEDEC ID: 0xC86014, Size: 1024 kbytes
forlond:ols/workshop/zigbee_devices/TLSRPGM % python ./TlsrPgm.py -p COM7 i | grep JEDEC
Flash JEDEC ID: 0xC86014, Size: 1024 kbytes
forlond:ols/workshop/zigbee_devices/TLSRPGM % python ./TlsrPgm.py -p COM7 i | grep JEDEC
Flash JEDEC ID: 0xC86014, Size: 1024 kbytes
forlond:ols/workshop/zigbee_devices/TLSRPGM % python ./TlsrPgm.py -p COM7 i | grep JEDEC
Flash JEDEC ID: 0xC86014, Size: 1024 kbytes
forlond:ols/workshop/zigbee_devices/TLSRPGM % python ./TlsrPgm.py -p COM7 i | grep JEDEC
Flash JEDEC ID: 0xC86014, Size: 1024 kbytes
forlond:ols/workshop/zigbee_devices/TLSRPGM % python ./TlsrPgm.py -p COM7 i | grep JEDEC
Flash JEDEC ID: 0x1C7EE9, Size: 13479973333575319897333507543509815336818572211270286240551805124608 kbytes
forlond:ols/workshop/zigbee_devices/TLSRPGM % python ./TlsrPgm.py -p COM7 i | grep JEDEC
Flash JEDEC ID: 0xC86014, Size: 1024 kbytes

Same thing happens when I try to read flash.

Do you have any suggestions as to how could I fix this?

[pvvx]

Pin PD3 (OUT) --> RESET
The RESET pin of the microcircuit must be connected, and option `-t100 -a100'.
Zigbee firmware turns off power to Flash when sleeping.
And the processor runs from Flash. Reading Flash at the same time as the CPU is running will create a mess.

Another option is to stop the processor.

[pvvx]

Without RESET: wait up to 11 seconds for the SoC to wake up, pause the processor, do not use RESET with an activation time of 70 ms.

TlsrPgm.py -p COM7 -z 11 -a-70 -s  <command>

If the -s option worked, then the second and subsequent launches will be with the CPU stopped. Until you give the start or power or reset command...

A better option is to use RESET or power up with an activation command. Then all SoC registers are set to normal by default.
The activation command is analogous to the CPU stop command.
If the firmware contains a code to disable SWS output, then operation is only possible through RESET or Power off/on.
All other options for debugging code on the fly.

[badrpc]

Thanks! I already had D3 connected to Reset, apparently on its own it wasn't enough. Adding -t100 -a100 seemed to have removed corruption and so did your second suggestion (-z 11 -a 70 -s ). However it turned out there was a second problem: with D3 connected to Reset it looked like the CPU would occasionally restart (the network LED would start flashing as it does when I plug the power into the device) while flash reading was still running and I would get Error Read Flash data at 0x068400! on a random address. With reset disconnected from D3 and either of your suggestions I seem to be able to read and write flash without issues. Thank you again!