Dimmer

[macpit]

Hi arendt,

Great Project and many thank for your work! I love it and it's work perfect. I know that is not project related but maybe you can help me.

I search a W-iFi dimmer for 230V/~400W for pulps. Sonoff is veyr cool but there is no dimmer :-( Maybe you have a tip for me?

Regards,

Marc

[mrphyslaw]

Why would you want to try and run it all from the esp? Zero cross is timing intensive especially with a chip that running WiFi and doing other duties.

[qingz2004]

Why would you want to try and run it all from the esp? Zero cross is timing intensive especially with a chip that running WiFi and doing other duties.

The MCU on my dimmer does not work well. Increase/Decrease buttons do not work, and the PWM does not sync with zero cross point. The bulb is flickering a lot when dimmed. The current dimmer uses smartlife app, and I need one to work with my MQTT server so I can integrate it into my home automation system.

I don't think zero cross is that timing intensive. 60Hz AC vs 80MHz system clock. It should be doable like this, It uses one ESP8266 to control two dimmer switches.

[chaosmaster]

I have also just received one of these and was already able to backup the original firmware, here is how I connected to the device:

[qingz2004]

I have also just received one of these and was already able to backup the original firmware, here is how I connected to the device:

That's how I backup mine. Possible to backup the MCU firmware? Since my dimer does not work well, I guess the firmware in MCU is no good. I try to update the MCU if not bypass it.

[chaosmaster]

I haven't tried backing up the MCU firmware yet. I am currently trying to get tasmota to talk to the MCU. I could imagine it uses the same protocol mentioned here: https://github.com/arendst/Sonoff-Tasmota/issues/595 https://github.com/enesbcs/ESPEasyPluginPlayground/blob/master/_P165_SerSwitch.ino

I assume backing up the MCU should be possible using an STLINK v2 (I have one lying around, but haven't tried yet)

[chaosmaster]

I have made some progress, it is indeed the same protocol, although different data-format, since it is a dimmer.

The following code snippet switches the light on (to whatever brightness-level was previously set):

    Serial.write(0x55); // header 55AA
    Serial.write(0xAA);

    Serial.write(0x00); // version 00

    Serial.write(0x06); // command 06

    Serial.write(0x00); // length
    Serial.write(0x05); // length

    Serial.write(0x01); // light number
    Serial.write(0x01); // boolean
    Serial.write(0x00); // length
    Serial.write(0x01); // length
    Serial.write(0x01); // status (0 or 1)

    Serial.write(0x0E); // checksum:sum of all bytes in packet mod 256
    Serial.flush();

baudrate is 9600

I also have the format for setting the brightness, but need to test first

[ahzazou]

Great news keep us updated i cant wait to see more updates i really appreciate your hard efforts

[qingz2004]

Here are the results I got with a logic analyzer. They include transmitting command and receiving feedback. To turn on the light: Tx: Time [s],Value,Parity Error,Framing Error 0.0s,0x55,, 0.0010419375s,0xAA,, 0.0020838125s,0x00,, 0.00312575s,0x06,, 0.004167625s,0x00,, 0.0052095625s,0x05,, 0.0062514375s,0x01,, 0.007293375s,0x01,, 0.00833525s,0x00,, 0.0093771875s,0x01,, 0.0104190625s,0x01,, 0.011461s,0x0E,, 0.05625s,0x00,,Error

Rx: Time [s],Value,Parity Error,Framing Error 0.0126726875s,0x55,, 0.01371s,0xAA,, 0.01474725s,0x00,, 0.0157845625s,0x07,, 0.016822s,0x00,, 0.0178594375s,0x05,, 0.01889675s,0x01,, 0.0199340625s,0x01,, 0.0209714375s,0x00,, 0.022009s,0x01,, 0.0230465s,0x01,, 0.0240840625s,0x0F,, 0.0251215625s,0x55,, 0.026159125s,0xAA,, 0.0271965s,0x00,, 0.028234s,0x07,, 0.0292715s,0x00,, 0.0303088125s,0x05,, 0.0313459375s,0x01,, 0.0323830625s,0x01,, 0.03342025s,0x00,, 0.034457375s,0x01,, 0.0354945s,0x01,, 0.0365316875s,0x0F,, 0.037569s,0x55,, 0.0386064375s,0xAA,, 0.0396438125s,0x00,, 0.0406811875s,0x07,, 0.041718625s,0x00,, 0.0427559375s,0x08,, 0.04379325s,0x02,, 0.0448305s,0x02,, 0.0458678125s,0x00,, 0.046905125s,0x04,, 0.047942375s,0x00,, 0.0489796875s,0x00,, 0.0500169375s,0x00,, 0.0510541875s,0xFF,, 0.0520914375s,0x15,, 0.05625s,0x00,,Error

To turn off light Tx: Time [s],Value,Parity Error,Framing Error 0.0s,0x55,, 0.0010419375s,0xAA,, 0.0020838125s,0x00,, 0.00312575s,0x06,, 0.004167625s,0x00,, 0.0052095625s,0x05,, 0.0062514375s,0x01,, 0.007293375s,0x01,, 0.00833525s,0x00,, 0.0093771875s,0x01,, 0.0104190625s,0x00,, 0.011461s,0x0D,, 0.05625s,0x00,,Error

Rx: Time [s],Value,Parity Error,Framing Error 0.012690375s,0x55,, 0.013727375s,0xAA,, 0.0147645s,0x00,, 0.0158015625s,0x07,, 0.016838625s,0x00,, 0.017875625s,0x05,, 0.018912625s,0x01,, 0.019949625s,0x01,, 0.0209865625s,0x00,, 0.0220235625s,0x01,, 0.023060625s,0x00,, 0.0240976875s,0x0E,, 0.02513475s,0x55,, 0.0261716875s,0xAA,, 0.02720875s,0x00,, 0.0282459375s,0x07,, 0.0292829375s,0x00,, 0.030319875s,0x05,, 0.0313568125s,0x01,, 0.0323938125s,0x01,, 0.033430875s,0x00,, 0.034467875s,0x01,, 0.035504875s,0x00,, 0.036541875s,0x0E,, 0.03757875s,0x55,, 0.03861575s,0xAA,, 0.0396528125s,0x00,, 0.0406899375s,0x07,, 0.041727s,0x00,, 0.042764s,0x08,, 0.0438010625s,0x02,, 0.044838125s,0x02,, 0.0458750625s,0x00,, 0.0469119375s,0x04,, 0.047948875s,0x00,, 0.0489858125s,0x00,, 0.0500229375s,0x00,, 0.05106s,0xFF,, 0.052097125s,0x15,, 0.05625s,0x00,,Error

To increase the brightness Tx: Time [s],Value,Parity Error,Framing Error 0.0s,0x55,, 0.001041875s,0xAA,, 0.0020838125s,0x00,, 0.0031256875s,0x06,, 0.004167625s,0x00,, 0.0052095s,0x08,, 0.0062514375s,0x02,, 0.0072933125s,0x02,, 0.00833525s,0x00,, 0.009377125s,0x04,, 0.0104190625s,0x00,, 0.0114609375s,0x00,, 0.012502875s,0x00,, 0.01354475s,0xC0,, 0.0145866875s,0xD5,, 0.05625s,0x00,,Error

Rx: Time [s],Value,Parity Error,Framing Error 0.0158369375s,0x55,, 0.016874125s,0xAA,, 0.0179113125s,0x00,, 0.0189484375s,0x07,, 0.019985625s,0x00,, 0.02102275s,0x08,, 0.022059875s,0x02,, 0.0230969375s,0x02,, 0.024134125s,0x00,, 0.0251713125s,0x04,, 0.0262084375s,0x00,, 0.027245625s,0x00,, 0.02828275s,0x00,, 0.0293199375s,0xC0,, 0.03035725s,0xD6,, 0.0313944375s,0x55,, 0.032431625s,0xAA,, 0.0334688125s,0x00,, 0.034506125s,0x07,, 0.0355433125s,0x00,, 0.0365804375s,0x05,, 0.0376175625s,0x01,, 0.038654625s,0x01,, 0.039691625s,0x00,, 0.040728625s,0x01,, 0.041765625s,0x01,, 0.0428025s,0x0F,, 0.0438394375s,0x55,, 0.044876375s,0xAA,, 0.0459135s,0x00,, 0.046950625s,0x07,, 0.0479878125s,0x00,, 0.0490249375s,0x08,, 0.050062125s,0x02,, 0.05109925s,0x02,, 0.052136375s,0x00,, 0.0531734375s,0x04,, 0.0542105625s,0x00,, 0.055247625s,0x00,, 0.05625s,0x00,,Error

To decrease the brightness Tx: Time [s],Value,Parity Error,Framing Error 0.0s,0x55,, 0.0010419375s,0xAA,, 0.0020838125s,0x00,, 0.00312575s,0x06,, 0.004167625s,0x00,, 0.0052095625s,0x08,, 0.0062514375s,0x02,, 0.007293375s,0x02,, 0.00833525s,0x00,, 0.0093771875s,0x04,, 0.0104190625s,0x00,, 0.011461s,0x00,, 0.012502875s,0x00,, 0.0135448125s,0x62,, 0.0145866875s,0x77,, 0.05625s,0x00,,Error

Rx: Time [s],Value,Parity Error,Framing Error 0.0159045625s,0x55,, 0.0169414375s,0xAA,, 0.017978375s,0x00,, 0.0190153125s,0x07,, 0.0200523125s,0x00,, 0.02108925s,0x08,, 0.0221261875s,0x02,, 0.0231631875s,0x02,, 0.02420025s,0x00,, 0.0252371875s,0x04,, 0.02627425s,0x00,, 0.0273113125s,0x00,, 0.0283483125s,0x00,, 0.0293854375s,0x62,, 0.0304224375s,0x78,, 0.0314594375s,0x55,, 0.0324964375s,0xAA,, 0.0335334375s,0x00,, 0.0345705625s,0x07,, 0.0356076875s,0x00,, 0.0366446875s,0x05,, 0.0376816875s,0x01,, 0.0387188125s,0x01,, 0.0397558125s,0x00,, 0.04079275s,0x01,, 0.0418298125s,0x01,, 0.042866875s,0x0F,, 0.043903875s,0x55,, 0.044940875s,0xAA,, 0.045977875s,0x00,, 0.0470146875s,0x07,, 0.0480515625s,0x00,, 0.0490884375s,0x08,, 0.050125375s,0x02,, 0.0511625s,0x02,, 0.0521995s,0x00,, 0.053236625s,0x04,, 0.05427375s,0x00,, 0.0553108125s,0x00,,Error

Actually, the MCU keep sending the light status periodically. That's why we can not read or update the FW of the esp8266 without cutting the Rx trace from the PCB.

[chaosmaster]

That seems right. I am currently able to power the light on and off. But setting the brightness fails somehow. From my understanding you can send the MCU an absolute brightness-level. But that doesn't seem to work. In your increase-command the value is 0xC0 In your decrease-command it is 0x62

Max is 0xFF and min is 0x00

Could you test if it always sends the same values when increasing or decreasing?

Edit: Maybe it's possible to keep the MCU in a reset-state and thus flash without cutting RX? (i.E by pulling the MCUs reset pin to some specific level)

[checksummaster]

check my previous post for a zero crossing + triac... it still need a esp32 but it more cheap than build the circuit yourself

On Mon, Jun 11, 2018, 9:21 AM qingz2004, notifications@github.com wrote:

Why would you want to try and run it all from the esp? Zero cross is timing intensive especially with a chip that running WiFi and doing other duties.

The MCU on my dimmer does not work well. Increase/Decrease buttons do not work, and the PWM does not sync with zero cross point. The bulb is flickering a lot when dimmed. The current dimmer uses smartlife app, and I need one to work with my MQTT server so I can integrate it into my home automation system.

I don't think zero cross is that timing intensive. 60Hz AC vs 80MHz system clock. It should be doable like this http://www.instructables.com/id/Multichannel-Wireless-Light-Dimmer/

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/arendst/Sonoff-Tasmota/issues/469#issuecomment-396241009, or mute the thread https://github.com/notifications/unsubscribe-auth/AAdJwfpdvCl6uts0M9vS-y-VEzrC0J3Zks5t7m7xgaJpZM4Nhrog .

[qingz2004]

Could you test if it always sends the same values when increasing or decreasing?

Just tested. Every time it sends different values when increase or decrease. So you are right. It just sends the absolute brightness (PWM) value to the MCU.

Maybe it's possible to keep the MCU in a reset-state and thus flash without cutting RX?

It all depends on how strong the MCU pulls up or down the line. It the MCU pulls down more strong than your programmer, you will not be able to pull it up.

[qingz2004]

My MCU does not work well. Modifying the ESP8266 FW will not help. The MCU does respond to ESP8266 commands sent from serial port, but it does not respond to the button touches (respond to on/off button, but not +/- buttons). And when the bulb dims, it flickers a lot. The PWM generated by MCU is not synced to zero crossing. I probed the PWM with an oscilloscope, half of the pulses are wrong. I wish I can program the MCU with a good FW or totally bypass the MCU.

[chaosmaster]

It all depends on how strong the MCU pulls up or down the line. It the MCU pulls down more strong than your programmer, you will not be able to pull it up.

I was thinking along the lines of just connecting the MCUs reset to gnd/vcc and keep it there while programming so it just doesn't boot up. Just like how it can be done with the esp as well.

I wish I can program the MCU with a good FW or totally bypass the MCU.

Using an STLINK v2 that should be possible, although i also saw some kind of update method in the serial protocol
That would also mean writing a firmware for it.

Do you think the hardware used for dimming is fine and its just an MCU issue or could it also be a hardware issue?

[qingz2004]

I was thinking along the lines of just connecting the MCUs reset to gnd/vcc and keep it there while programming so it just doesn't boot up. Just like how it can be done with the esp as well.

As long as it is not tri-stated during reset, it has some strength to pull up or down.

Do you think the hardware used for dimming is fine and its just an MCU issue or could it also be a hardware issue?

I believe it is mcu software issue. I probed the touch button signal and cross zero detection signals which go into mcu are all good. And I bought a few of those dimmers, all have the same problem. Mines are US version.

[chaosmaster]

Since I just had to reflash the device, I tried without disconnecting RX and connecting MCUs reset pin to GND while flashing. This worked well, the NRST pin of the MCU is even exposed on the header (I mislabeled it before):

I also got setting brightness working ( I did a mod 255 instead of a mod 266 for the checksum)

[chaosmaster]

@stanvv @reeso3000 @qingz2004 @epicality85: I have tasmota mostly working, I have attached the firmware, if you care to test. After some code cleanup I will publish the modified sources as well.
The Firmware starts in WPS_CONFIG AP mode initially, to enable AP-mode reset WIFI:

• Switch dimmer off using the center button
• Press down button for +/-20 seconds (until the green LED starts blinking)

What's working:

• Switching light on and off
• Setting brightness
• Sync on/off state when set through the dimmer
• Switch to AP-Mode for configuration using reset-procedure
• Control green LED
• Sync brightness when set through dimmer

What isn't working (yet):

• Syncing brightness-level when set through the dimmer

For flashing without cutting any traces, check my previous post

sonoff-tuya.zip

[qingz2004]

Good job!

What isn't working (yet):

• Syncing brightness-level when set through the dimmer

For the feedback from the MCU, check my previous post. I believe each frames starts with 0x55AA. So my feedback message contains 3 frames. Not sure which one is the real one. Since the +/- buttons do not work with my dimmer, I can not capture the message when you set the brightness through the dimmer.

[chaosmaster]

I am getting the feedback from the MCU. I just haven't figured out how to set it inside tasmota without causing it to again set the dimmer etc.

Since the +/- buttons do not work with my dimmer, I can not capture the message when you set the brightness through the dimmer.

I wonder why your buttons don't work. They work fine for me. also dimming seems fine as well (I couldn't see any flicker) What kind of lighting are you using? I am currently testing with an IKEA 6.3W dimmable 230V LED

[qingz2004]

I think the MCU sends the brightness and on/off status to esp8266 periodically. You just need to decode it and set it on GUI. Do not need to send any command to MCU.

My dimmer is USA version (check my previous post with picture), the code in MCU is wrong. I'm using incandescent bulb for test. Tried a dimmable LED, same result.

[chaosmaster]

I think the MCU sends the brightness status to esp8266 periodically. You just need to decode it and set it on GUI. Do not need to send any command to MCU.

Decoding already works, set "weblog 4" in webconsole to see debug-output. but setting the state inside tasmota without causing it to send it to the MCU because it thinks it received through mqtt or web etc, I'm not sure how yet. (I am not deeply familiar with tasmota-source, I just started digging into it)

My dimmer is USA version (check my previous post with picture), the code in MCU is wrong. I'm using incandescent bulb for test. Tried a dimmable LED, same result.

There is an update-procedure in the serial-protocol have you tried doing a firmware-update using the original esp-firmware? Maybe that will push a corrected version to the MCU.

I assumed the code running on the MCU in the US and the EU-Version is the same, maybe it's not?! I'll see if I get around to dumping the firmware of the MCU using STLINK v2. I assume the unlabeled pin in my previous image is the SWIM of the MCU so the header should have all pins needed for connecting STLINK v2.
On your US-Board the unpopulated header on the bottom right is probably the same pinout.

[qingz2004]

What do you mean "an update-procedure in the serial-protocol"? I see there is FW update from the SmartLife app, I have not tried that yet. Will try it tonight after work. I ordered STLINK a month ago, have not received it yet. I have all the hole labelled (V S G N) on my PCB. Here is the other side of my board. The touch sensor wired to a unknown chip CR302, and then the debounced signals go to the MCU. Can you check which pins on your MCU receive the touch sensor signals? Try to see if they are the same on mine. If they are the same, I should be able to us the FW from EU version. I also attached picture of the PWM generated from MCU. Ch1 is PWM, ch2 is cross zero. You will see they come in pairs. If one pulse from each pair is good, the other one is not good. That's why my bulb flickering.

[chaosmaster]

What do you mean "an update-procedure in the serial-protocol"?

The protocol used for the communication between MCU and ESP also includes commands for updating the MCU firmware. So if there is an update for the original firmware, it might also include an update for the MCU.

I ordered STLINK a month ago, have not received it yet.

That sucks, might as well order another one :P, they are available from Amazon prime for around 7 bucks.

The touch sensor wired to a unknown chip CR302, and then the debounced signals go to the MCU. Can you check which pins on your MCU receive the touch sensor signals?

The touch-buttons go to pins 2,3,5 of the CR302 (which is labeled differently on the EU-Version: CR302 B751T004CG4, maybe just a serial-number?).

I was able to find the following connections between the MCU and the CR302

MCU CR302
5    15
6    13
7    10
9    11
10   12

I see the header on yours is even labeled: V(CC) S(WIM) G(ND) N(RST)

[qingz2004]

I ordered the STLink from AliEpress and shipped from China. It normally arrives in 60 days. Thanks for the connections info between MCU and CR302. I will check mine when I get home after work. Hope they are the same.

[qingz2004]

Here is the connections on my PCB. MCU CR302 5 15 6 14 7 10 9 11 10 13

Besides 7 and 9 on MCU are ground and power, only pin 5 are correct which I think it's for the middle button (on/off) which works for me. Pin 6 and 10 are one pin off on CR302. Please make sure the connections you put are right! I'm going to cut and re-connect my PCB after you confirmed. Even I correct the connections, make the +/- buttons work on my dimmer, I still get the bulb flickering when dimmed. From the picture I captured with an oscilloscope, the first pulse in the pair is synced with cross zero, but I think every second pulse is calculated from first pulse, not from cross zero point. And the calculation is based on 50Hz AC, not 60Hz which is used in North American. If that's the case, your MCU code won't work for my dimmer. Mine may already have the same MCU code. Just checked with SmartLife app. I already have the latest firmware.

[chaosmaster]

I have made some progress with syncing brightness, although it's still not perfect. The logic is still a bit messy since syncing the brightness is tricky. Please test: sonoff-tuya.zip

Please make sure the connections you put are right! I'm going to cut and re-connect my PCB after you confirmed.

I will check again to make sure. It sure sounds like they planned different firmwares for the US-MCU and the EU-MCU, but somehow the EU-Version ended up on your device.

EDIT: Actually your measurements are correct, I must have shifted by one.

EDIT2: Mostly working now

[qingz2004]

Actually you're measurements are correct, I must have shifted by one.

So if I have the same MCU FW as yours, the buttons should work at least.

[chaosmaster]

Yes I don't see why they wouldn't if it's not a hardware-issue. I'm not sure what MCU FW I have, but I assume it's the same. You could try with my tasmota-port If you get anything from the MCU when pressing the buttons, but that's unlikely.

[qingz2004]

I don't think so, since my logic analyzer did not catch any activity from the serial port when I press a button.

[chaosmaster]

Maybe it's something about the CR302, mine clearly has a different marking:

The one mentioned here is the same as yours, so it's not a serial number.

[qingz2004]

As I said in previous post, I checked with a oscilloscope, the signals go into the MCU from CR302 are perfect when I touch the buttons. I didn't record the pin number at that time.

[chaosmaster]

I've got it mostly working now, still needs a bit of testing and cleanup though: sonoff-tuya.zip

Code is available here: https://github.com/chaosmaster/Sonoff-Tasmota/tree/tuya-dimmer

I also changed the default mode to AP since WPS is useless for me.

Please test and report

EDIT: updated firmware

[chaosmaster]

@qingz2004 I have dumped the MCU firmware using https://github.com/vdudouyt/stm8flash and STLINK v2 It seems stm8flash also supports flashing STM8 using an ESP with this Firmware: https://github.com/rumpeltux/esp-stlink

I'm unsure If the firmware contains any device-specific information. It is 5378 Bytes (after stripping the trailing 0-bytes) The MD5SUM of the stripped file is 47f6b2cd4af222bcbad5d0662a760ddf The MD5SUM of the unstripped file is ba03ae2d5cdb47014f96b17601706490

[qingz2004]

@chaosmaster Great! Looks like I can use my NoceMCU to flash the MCU before I get the STLink. Where can I get your MCU dump? Thanks!

[chaosmaster]

Looks like there isn't any device-specific information in there,
the only sensible strings in there are 1.0.0 and bSXSSFArVKtc4DyC,
which are the version and product_key.
All device specific information is stored inside the ESP.

Please make a backup of your MCU, I would really like to compare the two: stm8flash -p stm8s103f3 -c espstlink -s flash -r mcu-backup.bin

Here is my stripped dump: mcu-dump.zip

[qingz2004]

Thanks for the MCU dump. I will dump mine and flash yours. Before that, I need to install esp-open-sdk and build an esp FW. Not sure if there is any issue there.

[qingz2004]

Compiled the new stm8flash which supports espstlink. Built the esp firmware with esp-open-sdk. Will flash my NodeMCU and try when I get home after work.

[qingz2004]

Flashed NodeMCU with espstlink FW. Stuck at "Determine FLASH area" when I tried to read MCU flash with NodeMCU. Do I need to do anything to make the MCU in flash mode like esp8266?

[chaosmaster]

As mentioned in esp-stlink Readme, it doesn't support reset. So you will probably have to reset the MCU manually (by connecting NRST to GND)

[qingz2004]

Reset, still the same. Shall I keep it in reset? I think I need to read how the MCU programming work, or just wait for my STLink v2. It's almost 60 days since I ordered it. Should arrive in a few days.

[chaosmaster]

• Did you use a 1K-Pullup between SWIM and VCC as mentioned in the Readme?
• Is your NodeMCU running at 80MHz?

here is some documentation on SWIM (pages 8 upwards) I believe you just have to pull reset low while starting stm8flash, I don't think it should stay connected.

[qingz2004]

Yes, I have 1K pull up. I guess the clock is defined in the ESP FW. I have no way to set or change it. I believe espstlink FW will set it at 80MHz.

[chaosmaster]

The Arduino-IDE lets me set the CPU-frequency in the board-settings, so I assume it is defined in the linker-script. What do the LEDs look like while you're trying to run stm8flash? AFAIR they should be off, while in SWIM-mode.

[qingz2004]

When I run stm8flash, nothing happened on the board. All 3 LEDs are on. So it's not in SWIM mode. How can I set it to that mode? Pulling the RSTN down make the LEDs off, release RSTN, LEDs back to on. stm8flash still stuck at "Determine FLASH area".

[chaosmaster]

Could you upload your compiled esp-stlink? I can try with a NodeMCU

[qingz2004]

"make flash" generates two files and flashes both files into NodeMCU at two locations. If you read the Makefile, the command is as following. $(ESPTOOL) --baud 460800 --port $(ESPPORT) write_flash $(FW_FILE_1_ADDR) $(FW_FILE_1) $(FW_FILE_2_ADDR) $(FW_FILE_2) FW_FILE_1_ADDR is 0, and FW_FILE_2_ADDR is 0x10000.

The command from the terminal windows is like this:

"esptool.py --baud 460800 --port /dev/ttyUSB0 write_flash 0x00000 firmware/0x00000.bin 0x10000 firmware/0x10000.bin"

Here are the espstlink firmware and stm8flash with support of espstlink. firmware.zip stm8flash.zip

[chaosmaster]

OK, I tried with your firmware (I used my own stm8flash though) It worked fine this way: Connect everything up as in the readme besides NRST. Pull NRST low and keep it there. run stm8flash -p stm8s103f3 -c espstlink -s flash -r mcu-backup.bin

now I get:

Determine FLASH area
Due to its file extension (or lack thereof), "mcu-backup.bin" is considered as RAW BINARY format!
Reading 8192 bytes at 0x8000... Command 0x01 failed with code: 0x01

Requested 8192 bytes but received only 0.
Failed to read MCU

Now when I disconnect NRST from GND the LEDs stay off (MCU is now in SWIM mode) Now just run the same command again without NRST connected and I get:

Determine FLASH area
Due to its file extension (or lack thereof), "mcu-backup.bin" is considered as RAW BINARY format!
Reading 8192 bytes at 0x8000... OK
Bytes received: 8192

• Check your connections
• Try running as Admin/sudo

EDIT: just checked, just to be sure, it also works with your stm8flash

[qingz2004]

I changed to a different NodeMCU with espstlink flashed, and keep the RSTN low. Sometimes I got the same error as yours, sometimes different error. But as soon as I release RSTN, all LEDs light up.

[chaosmaster]

What happens when you start stm8flash without the nodemcu connected? Do you get different errors? (That would indicate that stm8flash is able to talk to the nodemcu at least)

I assume, there must be an issue with your SWIM connection or the 1K-pullup-resistor. The pin on your board labeled S is connected to D2 on the nodemcu and via a 1K-pullup-resistor also to 3v3. If the leds light up, after disconnecting NRST the MCU never receives the SWIM-sequence.

[qingz2004]

I flashed 2 NodeMCUs, they have different behaviors. One stuck at "Determine FLASH area", and one looks good. I got the same error as you if I keep RSTN to ground. I did get different errors with and without MCU connected. I metered 1K between V and S. And S is connected to D02 on my NodeMCU. The only issue I found is the VCC was less than 3.0V. Sometimes even less than 2.8V. Not sure if this will cause problem.

[qingz2004]

I will probe SWIM signal tomorrow. It's too late today.