How to flash ?

[the-mentor]

Hi, If i want to test this firmware what is the process of flashing it to the chip? Is it possible to use a chip clamp to flash the chip or de-soldering and re-soldering it the only way?

Thank you very much for your work !!

-DM

[matlab22]

I just use the esp32s3.name=ESP32S3 Dev Module

Ok, I added support for the ESP32S3 and arbitrarily used gpio4 and gpio5 for SDA and SCL pins.

Perfect thank you 👍 I guess then I have to pass the 23 lines from https://github.com/mightymos/RF-Bridge-OB38S003/releases/download/v0.2.0/RF-Bridge-OB38S003_PassthroughMode.hex the 192 from the serial mode are a bit to much. Doing it by hand. I might make a python script handling it or do you have already something?

[mightymos]

I just use the esp32s3.name=ESP32S3 Dev Module

Ok, I added support for the ESP32S3 and arbitrarily used gpio4 and gpio5 for SDA and SCL pins.

Perfect thank you 👍 I guess then I have to pass the 23 lines from https://github.com/mightymos/RF-Bridge-OB38S003/releases/download/v0.2.0/RF-Bridge-OB38S003_PassthroughMode.hex the 192 from the serial mode are a bit to much. Doing it by hand. I might make a python script handling it or do you have already something?

I do not know any python so have no script unfortunately. You are right, manual copying is tiresome. Fortunately, if the passthrough flashing works the first time then it only needs to be done once. However, for the long term a script or way to upload the entire hex would be preferred.

[the-mentor]

I got around to testing the updated flasher and it seems like it was much easier this time around

[mightymos]

I got around to testing the updated flasher and it seems like it was much easier this time around

With the ESP32 module I have I seem to get write errors during hex flash. Then I have to repeat sending hex lines. With the ESP8265 in sonoff used to flash another target sonoff I do not get errors while writing.

I am not sure what is going on with the errors on ESP32.

[the-mentor]

I tried to use ChatGPT to find a way to add a command to the Arduino code to flash all the lines one after another but my C++ skills are terrible.

I also tried to write a python script that uses serial but because of all the back and forth between reading and writing I also failed to make the process easier :(

[mightymos]

I tried to use ChatGPT to find a way to add a command to the Arduino code to flash all the lines one after another but my C++ skills are terrible.

I also tried to write a python script that uses serial but because of all the back and forth between reading and writing I also failed to make the process easier :(

Thanks for looking into it, there would be a learning curve for sure.

[matlab22]

Thanks for the pointers, but I have been trying for 1h and could not get it to display Connected... I can not figure out whats wrong, I have double checked the pins and they look correct, I have also tried different timings when applying the power but no luck :-(

@the-mentor Did you have to do something special with the D1 flashing?

It looks like your setup is missing a common gnd.

[mightymos]

Thanks for the pointers, but I have been trying for 1h and could not get it to display Connected... I can not figure out whats wrong, I have double checked the pins and they look correct, I have also tried different timings when applying the power but no luck :-( @the-mentor Did you have to do something special with the D1 flashing?

It looks like your setup is missing a common gnd.

That's a valid observation but the ground through the USB connector on both devices should I think be common. It could be tested with multimeter by attaching one lead to ground on USB connector at PC side and seeing if voltage can be measured on each device (e.g. 3.3 V).

[the-mentor]

@mightymos i didnt use a common ground as a matter of fact I would advise against it as it can in some cases harm the USB port @matlab22 check if you have the ports the other way around also the only plug you should disconnect is the ground from the rf bridge then put the d1 mini in handshake mode and then connect the ground to the rf bridge thats what i did a couple of times and then it worked

[matlab22]

I had a lot of error messages, turned out I had to read the instructions fully before i succeeded:

Handshake failed (884)
cycle power to target (start with power off and then turn on)
Handshake failed (885)
cycle power to target (start with power off and then turn on)
Handshake complete...
Read config byte failed...
Chip type failed...
Read address failed...
Chip failed to read
However, chip type reported was: 0xFF
Can try command [signature] or [handshake] to retry
clear

erase
Chip erase successful

setfuse 18 249
Set configuration byte...
Wrote configuration byte

:20006800AE82AF837C007D00C3EC9EED9F50147A0B7B001ABAFF011BEA4B70F70CBC00E8A5
Wrote 32 bytes

:200088000D80E522AE82AF837C007D00C3EC9EED9F50147A957B051ABAFF011BEA4B70F712
Wrote 32 bytes

:0800A8000CBC00E80D80E5220C
Wrote 8 bytes

:2000B000758E0022758E502275F75575F7AA75F75A43B6202275B7552253D3FE43D201538E
Wrote 32 bytes

:2000D000D57F43D48053DBFE43DA0122439180D29E43878043D91075BA0375AACC22D2ACC2
Wrote 32 bytes

:2000F0002243C9202253C9DF2243C9202243890143D901758CC1758A7FD2A9D28C22438924
Wrote 32 bytes

:200110001043D904758DFF758B5FD2ABD28E2275C16075C8D122A2AFE433F58222AE82AF9A
Wrote 32 bytes

:1F013000838F8C8E8A22AE82AF838F8D8E8B2285C2822285C3822253C9FD228581822263
Wrote 31 bytes

:03000000020006F5
Wrote 3 bytes

:09005F0075080075090002000398
Wrote 9 bytes

:0300030002019067
Wrote 3 bytes

:20014F0022D28090001412008CC28022D2B09003E812008CC2B0D2B09003E812008CC2B05C
Wrote 32 bytes

:20016F00227F01C3E5A19F4017D2B09003E8C00712008CC2B09003E812008CD0070F80E359
Wrote 32 bytes

:20018F00221200B01200C9C2B0C280C2871200DCD29C1200EE12010ED2ABC29712015B9043
Wrote 32 bytes

:2001AF0001F412008C1200B81200C5AF08A296E433F508EFB50802800AE5086004D290808E
Wrote 32 bytes

:1D01CF0002C290AF09A291E433F509EFB5090280D7E5096004D28780CFC28780CB2B
Wrote 29 bytes

:06003500E478FFF6D8FD9F
Wrote 6 bytes

:200013007900E94400601B7A009001EC780175A000E493F2A308B8000205A0D9F4DAF275A6
Wrote 32 bytes

:02003300A0FF2C
Wrote 2 bytes

:20003B007800E84400600A790175A000E4F309D8FC7800E84400600C7900900001E4F0A3C3
Wrote 32 bytes

:04005B00D8FCD9FAFA
Wrote 4 bytes

:0D00060075810912014FE5826003020003BD
Wrote 13 bytes

:00000001FF

mcureset
MCU reset...

I will make a python script to write the hex files and post it here.

[matlab22]

Here is the script I made: (https://github.com/mightymos/OnbrightFlasher/pull/1) This will flash the blink.hix or passtrogh if you change line 297 to "if send_file_content(ser, 'RF-Bridge-OB38S003_PassthroughMode.hex'):" and copy the hex file in the same folder. For me this is working fine, but I cleared the write protection manually and now it is gone. Can not test how it behaves when it is still on. Someone can try and give feedback?

here is the log for pass trough:

Available COM ports:
1. COM9 - Standard Serial over Bluetooth link (COM9)
2. COM4 - Standard Serial over Bluetooth link (COM4)
3. COM10 - Standard Serial over Bluetooth link (COM10)        
4. COM5 - Standard Serial over Bluetooth link (COM5)
5. COM13 - Intel(R) Active Management Technology - SOL (COM13)
6. COM14 - USB-Enhanced-SERIAL CH343 (COM14)
Select a COM port (enter the number): 6
Serial connection opened on COM14
Received response:
handshake
Reset to handshake
Handshake successful!

Handshake failed (0)
cycle power to target (start with power off and then turn on)
Handshake failed (1)
cycle power to target (start with power off and then turn on)
Handshake failed (2)
cycle power to target (start with power off and then turn on)
Handshake failed (3)
cycle power to target (start with power off and then turn on)
Handshake failed (4)
cycle power to target (start with power off and then turn on)
Handshake failed (5)
cycle power to target (start with power off and then turn on)
Handshake failed (6)
cycle power to target (start with power off and then turn on)
Handshake failed (7)
cycle power to target (start with power off and then turn on)
Handshake complete...
Chip read: 0xA
Connected...
Returning to idle state...
Initialization complete!
Response: :20006800AE82AF837C007D00C3EC9EED9F50147A0B7B001ABAFF011BEA4B70F70CBC00E8A5
File content sent successfully.
Response: Wrote 32 bytes
File content sent successfully.
Response: :200088000D80E522AE82AF837C007D00C3EC9EED9F50147A957B051ABAFF011BEA4B70F712
File content sent successfully.
Response: Wrote 32 bytes
File content sent successfully.
Response: :0800A8000CBC00E80D80E5220C
File content sent successfully.
Response: Wrote 8 bytes
File content sent successfully.
Response: :2000B000758E0022758E502275F75575F7AA75F75A43B6202275B7552253D3FE43D201538E
File content sent successfully.
Response: Wrote 32 bytes
File content sent successfully.
Response: :2000D000D57F43D48053DBFE43DA0122439180D29E43878043D91075BA0375AACC22D2ACC2
File content sent successfully.
Response: Wrote 32 bytes
File content sent successfully.
Response: :2000F0002243C9202253C9DF2243C9202243890143D901758CC1758A7FD2A9D28C22438924
File content sent successfully.
Response: Wrote 32 bytes
File content sent successfully.
Response: :200110001043D904758DFF758B5FD2ABD28E2275C16075C8D122A2AFE433F58222AE82AF9A
File content sent successfully.
Response: Wrote 32 bytes
File content sent successfully.
Response: :1F013000838F8C8E8A22AE82AF838F8D8E8B2285C2822285C3822253C9FD228581822263
File content sent successfully.
Response: Wrote 31 bytes
File content sent successfully.
Response: :03000000020006F5
File content sent successfully.
Response: Wrote 3 bytes
File content sent successfully.
Response: :09005F0075080075090002000398
File content sent successfully.
Response: Wrote 9 bytes
File content sent successfully.
Response: :0300030002019067
File content sent successfully.
Response: Wrote 3 bytes
File content sent successfully.
Response: :20014F0022D28090001412008CC28022D2B09003E812008CC2B0D2B09003E812008CC2B05C
File content sent successfully.
Response: Wrote 32 bytes
File content sent successfully.
Response: :20016F00227F01C3E5A19F4017D2B09003E8C00712008CC2B09003E812008CD0070F80E359
File content sent successfully.
Response: Wrote 32 bytes
File content sent successfully.
Response: :20018F00221200B01200C9C2B0C280C2871200DCD29C1200EE12010ED2ABC29712015B9043
File content sent successfully.
Response: Wrote 32 bytes
File content sent successfully.
Response: :2001AF0001F412008C1200B81200C5AF08A296E433F508EFB50802800AE5086004D290808E
File content sent successfully.
Response: Wrote 32 bytes
File content sent successfully.
Response: :1D01CF0002C290AF09A291E433F509EFB5090280D7E5096004D28780CFC28780CB2B
File content sent successfully.
Response: Wrote 29 bytes
File content sent successfully.
Response: :06003500E478FFF6D8FD9F
File content sent successfully.
Response: Wrote 6 bytes
File content sent successfully.
Response: :200013007900E94400601B7A009001EC780175A000E493F2A308B8000205A0D9F4DAF275A6
File content sent successfully.
Response: Wrote 32 bytes
File content sent successfully.
Response: :02003300A0FF2C
File content sent successfully.
Response: Wrote 2 bytes
File content sent successfully.
Response: :20003B007800E84400600A790175A000E4F309D8FC7800E84400600C7900900001E4F0A3C3
File content sent successfully.
Response: Wrote 32 bytes
File content sent successfully.
Response: :04005B00D8FCD9FAFA
File content sent successfully.
Response: Wrote 4 bytes
File content sent successfully.
Response: :0D00060075810912014FE5826003020003BD
File content sent successfully.
Response: Wrote 13 bytes
File content sent successfully.
Response: :00000001FF
File content sent successfully.
Response: mcureset
MCU reset successful.
Serial connection closed.

[the-mentor]

@matlab22 very cool script. I will test it out when I get a chance and provide feedback

[the-mentor]

@matlab22 the script worked great. I think you can add a step to do the setfuse 18 249 every time since it dosen't cause any issues if you do it every time.

[mightymos]

Ideally for a general purpose flasher, we need to read the fuse setting, modify only the bits that should be changed, and then write the fuse byte back. I might also need wrapper functions that only do specific changes like set reset pin to gpio or set reset pin to reset function. That is instead of encouraging user to modify raw bytes.

However, I'm not sure when I'll get to that, but can keep it in mind.

I'm working on allowing both SoftWire or Wire libraries to be used for I2C. Will get that tested and uploaded first.

[mightymos]

I was often seeing errors with SoftWire on my ESP32-WROOM board. This required repeated sending of hex lines.

Wire library is now available to use which allows hardware I2C. I no longer see errors with ESP32 board.

EDIT: Well...erase chip with hardware I2C times out but is actually working and erasing chip. I have a hack for now to indicate success.

[otsoni]

I have problem flashing the chip. Actually I don't have spare ESP boards so I tried flashing with Arduino Mega 2560 board and that didn't work so I also tried to write my own python code with smbus library to flash it using raspberry pi, but that failed too. Both seems to be same as https://github.com/mightymos/msm9066_capture/blob/main/erasecode_bench_supplies3.3V_turnedon_08-22-2023.sr when checking with logic analyzer. It gives ACK for the reset 0x7c but it gets NACK from writing "read config byte" 0x09. Do you have any idea what might be the problem?

[mightymos]

I have problem flashing the chip. Actually I don't have spare ESP boards so I tried flashing with Arduino Mega 2560 board and that didn't work so I also tried to write my own python code with smbus library to flash it using raspberry pi, but that failed too. Both seems to be same as https://github.com/mightymos/msm9066_capture/blob/main/erasecode_bench_supplies3.3V_turnedon_08-22-2023.sr when checking with logic analyzer. It gives ACK for the reset 0x7c but it gets NACK from writing "read config byte" 0x09. Do you have any idea what might be the problem?

Sorry, there are multiple places that use the reset chip 0x7c and read config byte 0x09, so I do not know which sequence you are referring to.

As you say during handshake, a reset chip 0x7c is written in a loop after device address has been written. Reset chip is repeatedly written until an ack is received in order to continue handshake. The loop can also stop after say ten nacks and exit handshake. Note that this does not reset chip, to actually reset microcontroller 0x7c must be read from. After ack is received during handshake additional bytes are written as part of the handshake sequence.

To read a config byte you must write device address, command 0x09, data address to read, and then request read. So reading configuration byte at address 0 should be 0xA which is the chip type.

It looks like the Arduino Mega 2560 rev3 board has pins D20 (sda) and D21 (scl) for I2C communication. How did you modify the sketch to try flashing? What output did you see in the serial monitor?

[otsoni]

As you say during handshake, a reset chip 0x7c is written in a loop after device address has been written. Reset chip is repeatedly written until an ack is received in order to continue handshake. The loop can also stop after say ten nacks and exit handshake. Note that this does not reset chip, to actually reset microcontroller 0x7c must be read from. After ack is received during handshake additional bytes are written as part of the handshake sequence.

Writing the reset register 0x7c in a loop gets acked so it continues from that. 0x7d and 0x2d after that get nacked, but I think that it is doing the same for you. Reading 0x7e after those three gets acked but returns nothing (same for you, I think). Then it waits 120ms and tries to write 0x09 and 0x00 to address 0x7e, but it fails as it gets NACK for writing the first byte 0x09. It does the same with Arduino Mega and my python script on raspberry pi.

It looks like the Arduino Mega 2560 rev3 board has pins D20 (sda) and D21 (scl) for I2C communication. How did you modify the sketch to try flashing? What output did you see in the serial monitor?

I added int sdaPin = 20; and int sclPin = 21; and changed Wire.begin(sdaPin, sclPin); to Wire.begin(); when using wire library. It seems that both Wire and SoftWire does the same thing. Here is serial monitor output:

Ready.
Entering [idle] state.
Type [handshake] to attempt connection to target.
Type [idle] and then [handshake] to start from the beginning
handshake
State changing to handshake
cycle power to target (start with power off and then turn on)

Handshake succeeded
Status: 3
NACK on transmit of data
Chip read type FAILED
Chip type reported was: 0xD5
Can try command [signature] or [idle] then [handshake] to retry

[matlab22]

Sometimes I also get this on the esp32 Chip type reported was: 0xD5 the latest python script has a retry and for me this works. Have you tried the script? Is your Status: 3 persistent?

I have 3.3V, GND, SDA, SCL connected from the "flasher board" to the SonOff and then shortly remove and reinsert the 3.3V connection. Sometimes I get Chip type reported was: 0xD5 , but most of the time it works

[otsoni]

Have you tried the script? Is your Status: 3 persistent?

I hadn't tried the script before, but I tried it now. Status: 3 is persistent and happens every time also when using the script. Maybe I need to order some spare ESP board and maybe couple more rf bridges. Do you have recommendations about compatible ESP boards?

[matlab22]

I am using an ESP32-S3-DevKit replica from AliExpress https://www.aliexpress.com/w/wholesale-ESP32%2525252dS3%2525252dDevKit.html?spm=a2g0o.detail.search.0

[mightymos]

@otsoni I guess that board has 10kohm pull ups on those lines, but I think logic is 5V. I do not know if the OBS38003 is tolerant of 5V. The other possible issue is that internal pull ups on either flasher or target are also enabled which could be out of range. I will try to figure out more.

[otsoni]

That's true, Arduino Mega has logic level 5V so it might be problem for OBS38003 if I2C SDA and SCL are pulled to 5V. But I think that it hasn't fried the chip as it is still acking the first reset. But Raspberry Pi has 3.3V logic level and it is not working there either. But that is running my own horrible python script and I think that smbus library is using I2C one byte per millisecond (frequency is 100kHz, but separate bytes are sent just one per millisecond) and that might be problem there. Maybe I need to try to do it without smbus library and maybe using C, but I'm not fluent in it.

Anyway, I'm ordering couple more RF Bridges and some separate ESP boards so I can get it fixed.

[mightymos]

@otsoni There is at least one more thing to try. I now include support for the SoftwareWire library, another software i2c library that supports AVR (only avr I think). It should work with your board but I cannot try it myself. You'll need to uncomment just the softwarewire line in projectDefs.h. The pins use the macros PIN_WIRE_SDA and PIN_WIRE_SCL.

[otsoni]

There seems to be something wrong with my setup as I am unable to flash it with D1 mini and ESP32 too. Is there need for some kind of hardware mod and does it matter what is running on the esp chip on rf bridge? I have two boards and other is running original sonoff firmware on esp and other is running blank esphome but neither seem to work. Maybe I need to do some more testing and try to figure out what is wrong

[mightymos]

@otsoni It seemed like others had the most success with the D1 mini. I do not have one but may need to order. There should not be any hardware modification required except installing header pins. It should not matter if the ESP8285 on the rf bridge is erased, however it should not hurt especially if you plan to erase anyway.

It might help if you post a photo of your setup. Otherwise just a pinout would also be helpful.

This is an example of my ESP32 serial monitor output, what are you seeing?

ets Jul 29 2019 12:21:46

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0030,len:1344
load:0x40078000,len:13964
load:0x40080400,len:3600
entry 0x400805f0
Ready.
Entering [idle] state.
Type [handshake] to attempt connection to target.
Type [idle] and then [handshake] to start from the beginning
handshake
State changing to handshake
cycle power to target (start with power off and then turn on)

Handshake succeeded
Status: 0
Success
Chip read: 0xA
Connected...
Returning to idle state...

[otsoni]

Here is a photo of my setup:

So pinout is following:

Breadboard plus and minus powered with 3.3V

D1 mini GND to breadboard minus D1 mini SDA to rf bridge SDA on J3 D1 mini SCL to rf bridge SCL on J3

Breadboard minus to rf bridge GND on J3 Breadboard plus to rf bridge 3V3 on J3

USB between computer and D1 mini for data and power for D1 mini.

Maybe I still check with oscilloscope if my 3.3V power supply is dropping voltage on startup or something, but otherwise I have no idea what to do next.

[matlab22]

Why are you not using the 3.3V from the D1 mini? How do you know it is not working? Which step is failing?

[otsoni]

Why are you not using the 3.3V from the D1 mini? How do you know it is not working? Which step is failing?

I read somewhere that it is recommended to use different power supplies so that's why. When I try to power it with D1 mini it causes sonething weird and serial connection is lost for second or something. Maybe it is drawing too much power and serial is lost or something.

It is failing with reading chip type because of NACK on transmit of data.

[otsoni]

By the way, it seems that in some photo (https://user-images.githubusercontent.com/3618442/190150761-00fe2fa4-8e04-437a-8155-1d3f154ed732.jpeg) the marking on the OB38S003 chip is 8R08A1 L51CN1 and in my chip the marking seems to be 8R08A1 L53CN1 so the 51 has changed to 53. Can somebody confirm their marking on known working chip?

[matlab22]

This Can you post the log from the terminal? Open the terminal and hit the reset button on your D1 Don't mind the marking. Only the first line is relevant the rest are production specific numbers. Probably: Factory code, production date, yield ...

[otsoni]

;ld��|�l�|�l�c|����s�c�c��nn�dno���cp��l{d{dx�g��d��co�|���c��gg�l��l`�ggl`'s���ncd�lp�o�r������cn�|�c��oo�l`�ggd`n{���oc��`{��gb��`��{�dd`��o�d����g�r��g|�l�d`c��|{�l�o��o�l`��s�l�l��Ready.
Entering [idle] state.
Type [handshake] to attempt connection to target.
Type [idle] and then [handshake] to start from the beginning
handshake
State changing to handshake
cycle power to target (start with power off and then turn on)

Handshake succeeded
Status: 3
NACK on transmit of data
Chip read type FAILED
Chip type reported was: 0x20
Can try command [signature] or [idle] then [handshake] to retry

It seems that the board is sending info on baud rate of 74880 on reset so that is the first line. Here is the same with correct baud rate:

 ets Jan  8 2013,rst cause:2, boot mode:(3,6)

load 0x4010f000, len 3424, room 16 
tail 0
chksum 0x2e
load 0x3fff20b8, len 40, room 8 
tail 0
chksum 0x2b
csum 0x2b
v00045890
~ld
rf cal sector: 1020
freq trace enable 0
rf[112] : 0�

[matlab22]

it looks like something with your D1 board is of. Can you try the serial prompt reset cycle without anything attached?

[otsoni]

With baud rate 115200:

sll��|�d�<�l�c|����s�c�c��oo�lgg���c8��drlslp�o��l��co�|���b��oo�l��l`�nnd`o{���obl�dx�g�s������cg�|�c��gn�d`�ool`gr���gc��`{��oc��`��s�dd`��o�l����n�{��o|�l�l`c��|s�d�o��o�l`��r�l�l��Ready.
Entering [idle] state.
Type [handshake] to attempt connection to target.
Type [idle] and then [handshake] to start from the beginning

And with 74880:

 ets Jan  8 2013,rst cause:2, boot mode:(3,7)

load 0x4010f000, len 3424, room 16 
tail 0
chksum 0x2e
load 0x3fff20b8, len 40, room 8 
tail 0
chksum 0x2b
csum 0x2b
v00045890
~ld
rf cal sector: 1020
freq trace enable 0
rf[112] : 0��P��
�ѮPY@���@��72�T?�Q-,Ԣ�@T�
T'Y�r��P��r�T�
N�OQ�!t1Y=I�
Ii9A�P�P��P�
%n�qo�

Can I change the baud rate it is using on reset from somewhere?

[matlab22]

I rewoke it looks like the bootloader is printing out on 74880 and the application on 115200. So far so good. Can you check the I2C signals? logic analyzer or scope?

[otsoni]

I have combined scope and logic analyzer, but it's kinda vintage so I just upload images as it is kinda hard to get data out. And it has just 8K memory so I can't fit everything to one timing sample and need second trigger for getting sample of things happening after 120ms waiting.

Here is the scope signal for 3.3V for rf bridge when connecting to voltage. Green marker is 3.3V and yellow marker is 3.0V. Other power supplies I tried are worse than this

Here is the handshake part on logic analyzer. Everything seems fine for me.

Same on power supply on scope:

This is the part for reading the chip info after 120ms waiting and here it is failing. It seems that it is acking the address, but it is nacking the data, both bytes:

I checked the voltage on power supply here too, but forgot to take photo. It was really near 3.3V at that time.

[mightymos]

@otsoni I just tried powering the Sonoff target with my ESP32 board directly. It will only work if I first erase the ESP8285 on target. This is likely because if the ESP8285 is connecting to Wifi it can be drawing too much current and/or drawing current too quickly and this produces a voltage glitch on either the flasher board or the target which interferes with a clean startup.

Could you try erasing your ESP8285 and connect your Lolin module directly to target (leave target 3.3V pin unconnected until after issuing handshake command)?

If you have the Lolin D1 mini v4.0.0 it seems to contain a ME6211C33 voltage regulator which can provide 500mA: https://www.wemos.cc/en/latest/d1/d1_mini.html https://datasheet.lcsc.com/lcsc/Nanjing-Micro-One-Elec-ME6211C33M5G-N_C82942.pdf

One of my Sonoff bridge microcontrollers contains the marking M08CN1. Unfortunately I do not think the datasheet for the OB38S003 explains what these second markings mean. So I am not sure what your different markings mean. Hopefully it is just a manufacturing date and does not change the functioning of the chip. I will try to look into it further, especially if it somehow changes the flash procedure.

Apparently, the 8R08A1 M08CN1 is present in other Sonoff devices as well: https://github.com/arendst/Tasmota/issues/17944

[otsoni]

@mightymos erasing rf bridge chip didn't fix it. It seems that for some reason powering the rf bridge with my Lolin D1 mini does something strange and it kinda resets the serial (disconnects and connects it back). Maybe it is doing it because it is drawing too much power or something, I don't know. It seems that my nodeMcu works better and it doesn't do that reset thing, but it's still not working, same thing for my esp32 board, except that on esp32 board Wire library is not working at all

[mightymos]

@otsoni Ok, I am ordering a Lolin D1 mini v4 to try myself in the future.

You erased rf bridge esp8285 with esptool? What specific nodemcu and ESP32 boards do you have?

I may just need to try Lolin board myself and see if I can reproduce problems.

[otsoni]

You erased rf bridge esp8285 with esptool?

Yes, I erased the rf bridge esp8285 with esptool and at least it's not showing any led activity anymore.

What specific nodemcu and ESP32 boards do you have?

I have board that says to be LoLin new NodeMcu V3, but it might be clone. ESP32 board that I have seems to be clone of DOIT ESP32 DEVKIT V1, at least it doesn't have DOIT logo printed. I'm not sure if the D1 mini V4 that I have is also clone or not.

[mightymos]

Okay, the DOIT board is the most similar to what I have at the moment so we can stick to that board for now.

The pinout I see here shows that sda and scl pins are GPIO21 and GPIO22 respectively: https://www.circuitstate.com/pinouts/doit-esp32-devkit-v1-wifi-development-board-pinout-diagram-and-reference/

So in the sketch under CONFIG_IDF_TARGET_ESP32 you'll need to change to:

  int sdaPin = 21;
  int sclPin = 22;

In projectDefs.h you can uncomment only USE_WIRE_LIBRARY at first.

You can then connect those pins to respective pins on target. Also connect ground to target (pin 2 next to BOOT push button). And finally connect 3.3V to target after typing "handshake".

If you need to retry handshake, just disconnect 3.3V pin from target. Then type "idle" and then "handshake". Then connect 3.3V pin again and handshake should be attempted again.

What do you get in serial monitor?

[otsoni]

I tried it but it's not working. Here is serial monitor output:

Type [handshake] to attempt connection to target.
Type [idle] and then [handshake] to start from the beginning
handshake
State changing to handshake
cycle power to target (start with power off and then turn on)
Handshake succeeded
Status: 2
NACK on transmit of address
Chip read type FAILED
Chip type reported was: 0x7C
Can try command [signature] or [idle] then [handshake] to retry

idle
State changing to idle

handshake
State changing to handshake
cycle power to target (start with power off and then turn on)
Handshake succeeded
Status: 2
NACK on transmit of address
Chip read type FAILED
Chip type reported was: 0x44
Can try command [signature] or [idle] then [handshake] to retry

It seems that SDA and SCL are not pulled up if I have connected it to both boards, but only ESP32 devkit is powered. When powering also rf bridge, it seems to pull those pins up. Is it normal? I also tried to add pullup resistors myself, but it caused strange problems because rf bridge is somehow pulling those pins down and cousing garbage, even when it's not powered.

I also found something interesting when checking with logic analyzer. It seems to be kinda same than yours here https://github.com/mightymos/msm9066_capture/blob/main/erasecode_bench_supplies3.3V_turnedon_08-22-2023.sr, but mine is keeping sda high when reading address 0x7e here https://github.com/mightymos/OnbrightFlasher/blob/main/onbrightFlasher.cpp#L70. Here is photo of that on logic analyzer:

I also found that I have some activity on i2c just after waiting the read operation and your is just getting both sda and scl up. Here is photo from my scope:

[mightymos]

@otsoni I need more time to consider the pull up situation, I looked and the Sonoff bridge certainly does not have any external pull ups on the board. The idle state of the i2c bus should be high as I recall.

I am not sure where the ESP32 wire library implementation enables pull ups, it seems it cannot be disabled/specified when initializing.

I did notice in your picture that some of your jumper wires are at an angle when plugged into female receptacles. In other words, they look like diamond orientation compared to square receptacles as though the pin can rotate.

Are the pins rounded or square? Are you sure your connections are good?

The flasher has to try driving the i2c bus even when the target is unpowered to look for handshake response. There can be an errant response if a pin is floating, but I think it should be okay as long as there is a ground connection. If ground is floating it can appear you are getting i2c activity but it is just junk.

[mightymos]

@otsoni Also I will use logic analyzer on OnbrightFlasher so it can be compared with stock flasher captures as soon as I can. Maybe that will reveal something.

[otsoni]

Are the pins rounded or square? Are you sure your connections are good?

I don't really have the best soldering skills, but otherwise the connections should be good. The pins kinda can rotate there. I got a espressif ESP32 DevKitC V4 from my friend at it's also not working. I have three separate rf bridges and they are not working. Is it possible that I have rf bridges from some kind of batch that is not programmable or something. I really don't know what might be wrong. But if you get logic analyzer capture using OnbrightFlasher it might reveal something.

[otsoni]

I got it working! I have no idea why, but after running this (https://github.com/mightymos/msm9066_capture/blob/07dd621cb97439575ee9e3cdefc33042d49ead45/esp32_i2c_onbright_flasher.ino) one time it allowed me to run the current OnbrightFlasher too! So now I have one board that works and still two boards that doesn't work if I need to get a LA capture from the old flashing procedure to check what has changed or something

[mightymos]

@otsoni That is great news. I hope to improve reliability as time goes on and will update the readme.

[mightymos]

@otsoni I just noticed there was a bug in the Atmega2560 board pin definitions, the sda and scl pins were being assigned to the same pin which was clearly not correct. I am now relying on PIN_WIRE_SDA and PIN_WIRE_SCL definitions for boards instead of manually specifying them myself.

I also tried the Lolin D1 mini v4.0.0 and it works well. However, on all the boards I have when I try to use the on board 3.3V regulator to power the target I get a lot of glitches as you have also observed. I am just using a separate bench top power supply to power the target right now. I have also had some okay luck with using a separate usb to serial converter just as a power source.

If you have managed to flash a hex to your Sonoff and get ESPHome/Tasmota working I would suggest leaving it alone. However, if you would like to retest the Atmega2560 board to see if handshake can work that could be helpful to others.

[otsoni]

I tried to see what was the problem with my another rf bridge and it seems that the trick on the old script is that it erasing the chip regardless of the status of reading chip type. So it seems that reading chip type on my rf bridges isn't possible before erasing the chip. So now I have to rf bridges that have erased successfully and one rf bridge that is still protected if I need to do some more testing about it. I can try the Atmega2560 next for the erased boards to make sure if it works at all.

[otsoni]

It seems that Atmega2560 has at least successful handshake and erase. I didn't try flashing, but I think it should work too. But still I wouldn't recommend using it as it has 5V logic level and OB38S003 has 3.3V logic level