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

[mightymos]

You can try to use this sketch with library: https://github.com/mightymos/OnbrightFlasher

The sketch is intended to be run on the built in ESP8265. But you'll have to use an external Arduino board. This is because the RESET pin functionality is probably disabled on Sonoff (set to GPIO) but handshake needs to occur at microcontroller startup. If you power the whole board up both microcontroller and ESP8265 will start up but ESP8265 startup is slower and so handshake will miss the microcontroller.

Instead you can have the separate Arduino powered, and have I2C pins connected to the Sonoff microcontroller. The Arduino will be constantly trying to handshake while powered. Then apply power to the Sonoff and handshake should occur.

If it does not complete handshake, will need to power cycle Sonoff until it does.

Then you'll need to erase chip to unprotect it. Then can finally write hex file line by line to microcontroller.

The sketch does not easily set configuration bytes now. So that will need to be added eventually to make this whole process easier (to use built in ESP8265 to flash). Also some script on PC side will be needed to make sending hex file lines easier.

Do you have an Arduino board around, maybe something like an ESP32?

I can help with hardware hookup but need to know what you have first. Possibly will try on my side first too to make sure it can work.

[the-mentor]

@mightymos thanks for reaching out. I have a bunch of ESP32 and D1 mini(esp8266) boards around.

A step by step guide + a picture of the pins on how the wiring to the ESP32 board etc need to be wired will help a lot.

[mightymos]

I have been able to erase the microcontroller with an external ESP32 board. I am working on setting the configuration bytes so the built in ESP8265 can be used afterward because I think that will be easier. I will respond once I have made progress.

[the-mentor]

@mightymos can you write the instructions to erase the micro-controller with an external ESP32 board so I can test if I can get that working?

[mightymos]

For now I think it is best to use your D1 mini (esp8266) board as a programmer.

You can follow the usage instructions here now: https://github.com/mightymos/OnbrightFlasher/blob/main/usage.txt

However, if something is unclear please ask me questions.

It is best to power both boards up from separate 3.3V supplies. Do you have a couple usb to serial adapter boards with 3.3V output?

[the-mentor]

@mightymos can you explain how I'm suppose to connect the pins ? the picture doesnt really explain it from which pins on the d1 to which pins on the rf bridge ?

edit: also how do I compile the flasher ? edit2: when trying to compile the project its complaining about a missing "SoftWire.h" file

[mightymos]

You need to install the SoftWire library in the Arduino IDE. You might also need to install esp8266 board support: https://randomnerdtutorials.com/how-to-install-esp8266-board-arduino-ide/

I am assuming this matches your D1 board, let me know if it does not: https://randomnerdtutorials.com/esp8266-pinout-reference-gpios/

So the D1 board is, I assume, connected to computer by USB to upload. Then GPIO4 SDA (pin D2) on D1 board is connected to SDA pin on Sonoff (J3 connector). Also GPIO4 SCL (pin D1) on D1 board is connected to SCL pin on Sonoff.

On Sonoff, you can have ground connected to your separate power supply. Once you are ready to try handshake, you can apply 3.3V to Sonoff 3.3V pin (any one should work, but might make sense to just use J3 connector).

[the-mentor]

@mightymos did this work properly ?

[mightymos]

It looks like the commands might have worked, except the chip read should be 'A' for this microcontroller. You will have to redo handshake with powerup and see if it displays 'A'.

Also, you did not write any hex to microcontroller? You can try sending all lines from blink.ihx once you see chip read 'A'.

[the-mentor]

ok so after a bunch of fiddling I managed to flash it and get the red led to blink. now what ?

edit: I mean how do I put it in pass-through mode

[mightymos]

That's great.

The project hex file is too big for this type of manual flashing right now. Because it includes a bunch of other stuff besides pass through mode.

Let me create a simpler version and we can try to flash that.

[the-mentor]

I wonder if we can modify the flasher program to flash the hex automatically rather then pasting line by line. It can help a lot

[mightymos]

That is true.

I see two ways: [1] Send file line by line with a script on computer side [2] Modify or replace sketch with ability to handle an entire file sent over serial port

Either approach would be helpful long term but I could not do either quickly.

I will try to make a simpler version of the pass through mode first.

[mightymos]

I created a branch that tracks the simpler pass through mode firmware. Hopefully in the future the source code can be better organized. And/or the flashing can be made easier.

In any case, I have attached a simple pass through mode hex. I have also attached my ESPHome yaml which demonstrated pass through is working.

RF-Bridge-OB38S003_SimplePassThrough_01-14-2024.zip

sonoff_bridge.zip

You do not have to do the setfuse step every time, once is enough. Just need to: erase copy hex lines mcureset

Are you using ESPHome?

[the-mentor]

I'm going to try and flash it sometime today and report back.

I have two rf bridges and the one I used to try to flash the rf chip's firmware has Tasmota but I'm going to flash it with esphome since that is my preferred custom firmware.

Either way thank you very much for all the support you've given me.

Once I get everything working I'll try to write documentation on how to flash the firmware and contribute it to the repo.

[the-mentor]

@mightymos I was able to flash the code and get ESPHome going.

Does pass-through mode also works for transmitting or only receiving ?

I added this code to my ESPHome config and It doesnt turn on the device I want it to turn on.

switch:
  - platform: template
    name: RF Power Button
    optimistic: true
    turn_on_action:
      - remote_transmitter.transmit_rc_switch_raw:
          code: '10111100110001100101010110101'
          protocol: 1
          repeat:
            times: 1
            wait_time: 0s   

Edit: if i change the repeat to 3 i see this in the ESPHome log

Edit2: Also another interesting thing. I have 2 sonoff rf brides (same model) one with your pass-through firmware (left) and one without (right) as you can see in the picture of them side by side the one with the pass-through firmware doesnt handle all the button presses of my remote.

Edit3: adding the following tolerance/filter/idle in the remote receiver helped with the issue in Edit2

remote_receiver:
  pin:
    number: GPIO3
    mode:
      input: true
      pullup: false
  tolerance: 60%
  filter: 4us
  idle: 4ms
  dump: 
    - rc_switch

[mightymos]

Yes, you need to send duplicate transmissions with a delay between. Otherwise the decoding will ignore. Some door sensors send as many as 20 repeats.

I have not previously done much with transmitting. I am not sure about the missed button decoding. It would need more examination.

I received on my other Sonoff running Tasmota: 18:59:08.905 RSL: RESULT = {"Time":"2024-01-16T18:59:08","RfReceived":{"Sync":10800,"Low":320,"High":1020,"Data":"BCC655","RfKey":"None"}}

You would need to do something like this:

# FIXME: add comment
remote_transmitter:
  pin: GPIO1

  # Set this to 50% if you’re working with IR LEDs and to 100% if working with other things like 433MHz transmitters
  carrier_duty_percent: 100%

switch:
  - platform: template
    name: RF Transmit Button
    optimistic: true
    turn_on_action:
      - remote_transmitter.transmit_rc_switch_raw:
          code: '10111100110001100101010110101'
          protocol: 1
          repeat:
            times: 8
            wait_time: 30ms 

[the-mentor]

I have not previously done much with transmitting. I am not sure about the missed button decoding. It would need more examination.

this code in the remote_receiver: fixed the missing decoding

tolerance: 60%
filter: 4us
idle: 4ms

I've added your example of transmitting and my 2nd sonoff doesn't receive my transmission at all even when using your example.

This is what i have in the yaml

remote_transmitter:
   pin: GPIO1
   carrier_duty_percent: 100%

switch:
  - platform: template
    name: RF Transmit Button
    optimistic: true
    turn_on_action:
      - remote_transmitter.transmit_rc_switch_raw:
          code: '10111100110001100101010110101'
          protocol: 1
          repeat:
            times: 8
            wait_time: 30ms 

here is a screenshot side by side of the sender (left) and the receive (right)

any suggestions ? transmitting also happens via the OB38S003 chip ?

[mightymos]

Are you using Home Assistant to toggle switch? If so you might want to remove device from Home Assistant and re-add. I did change the switch name to RF Transmit, so in my case RF Power would no longer exist.

I have done transmission from OB38S003 previously but it was not very thorough. The firmware when in serial mode does not really yet support transmission. I am not sure about other suggestions.

We can keep trying to exchange ideas until it works.

[mightymos]

I did want to comment that my receiver with Tasmota is a Sonoff R2 v1.0 (black box) running Portisch firmware.

[the-mentor]

If I understand you correctly the firmware in serial mode (pass through) doesn't support transmitting yet.

I think it will be great to add that feature. Once that feature is added this firmware should be as good as the direct hack just without the hard work of soldering/cutting traces etc.

Either way amazing work!!

EDIT: I also tried toggling the switch from the esphome device's web server and it didnt work and i've also tried sending codes from simple remotes that the rf bridge without the rf firmware can pick up without luck so i'm pretty sure its not transmitting

[mightymos]

Do you have an oscilloscope or logic analyzer?

[the-mentor]

Do you have an oscilloscope or logic analyzer?

I do not.

[mightymos]

You might be able to use something like this to inspect the transmit pin with another of your D1 boards: https://github.com/aster94/logic-analyzer

There are also logic analyzers that work with pulseview for about $20 USD.

That would at least indicate if the transmit pin is toggling or not.

[the-mentor]

What is the transmit pin on the j3 connector that I need to monitor?

On Thu, Jan 18, 2024, 8:39 AM Jonathan Armstrong @.***> wrote:

You might be able to use something like this to inspect the transmit pin with another of your D1 boards: https://github.com/aster94/logic-analyzer

There are also logic analyzers that work with pulseview for about $20 USD.

That would at least indicate if the transmit pin is toggling or not.

— Reply to this email directly, view it on GitHub https://github.com/mightymos/RF-Bridge-OB38S003/issues/4#issuecomment-1897890007, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACVK2JT3SYG3RGT66FEXSPTYPC7RJAVCNFSM6AAAAABBUUSZV2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJXHA4TAMBQG4 . You are receiving this because you authored the thread.Message ID: @.***>

[the-mentor]

Nevermind about the sending issue I was able to confirm that sending works.

[mightymos]

Nevermind about the sending issue I was able to confirm that sending works.

That's great, was it something simple, how were you able to confirm?

[the-mentor]

I'm tinkering with all kinds of RF devices since I'm trying to control my Rf fans.

So I got all kinds of devices from aliexpress in order to try and reverse engineer the remote.

One of them is the cc1101 transponder that arrived a few days ago and I was able to set it up today and I could see the rf signals coming in from the sonoff rf bridge with the serial pass through firmware.

Your excellent work makes it very easy to modify the device without too much Hassel and no soldering requirments.

[mightymos]

For future reference here are pin descriptions that can be further notated: https://github.com/mightymos/RF-Bridge-OB38S003/blob/main/notes/sonoff_r2v2.2_connector_pinouts_fv1.txt

That's great you saw some radio activity. Keep testing and do let me know how things go.

[syepes]

@mightymos First of all thanks for the hard work on this! I don't have a spear ESP32 board for flashing the MCU, so I am going to buy a SyncMOS MSM9066 MCU Programmer MCU. Could you share the procedure and pinout when using this method.

Edit: I am going to get a D1 board this is faster an also try the alternative flasher. So if I understand correctly, once I flash the MCU I can then just flash esphome as usual right?

[the-mentor]

@syepes i highly recommend you buy a nodemcu or a esp8266 d1 mini They are much cheaper and easier to flash Also I recommend you get a serial flasher that has 3.3v output or a 3.3v battery to power the chip for during flashing. Also header pins helped a lot during flashing and they prevent you from needing to solder anything

[syepes]

Thanks I am receiving a esp8266 d1 mini this week and I already have the series flasher. It would be appreciated the procedure on what need to be flashed on the D1 and than where are the last hex lines that I need to flash.

I also have two Sonoff R2 one with the direct hack + esphome and one unmodified that I'll be testing with this method

[mightymos]

You'll need to upload the OnbrightFlasher sketch to the ESP8266 D1 mini or similar board. You could actually have used one of the Sonoff ESP8265 to flash the microcontroller on another board. But having the separate mini is probably convenient.

You can go to the Releases page of this repository to get the PassthroughMode hex file for the microcontroller. There are instructions in the readme and a usage.txt at the OnbrightFlasher repository. They probably should be combined and edited. If something is not clear just ask for help.

If you did for some reason want to use the official MSM9066 programmer, here is a picture of pins:

[mightymos]

Here are the SMAP AC settings for the MSM9066 official programmer:

[syepes]

@mightymos

I have finally gone with the ESP8266 D1 board, but I am seeing these error when powering the Sonoff.

This is the pin connection:

• GPIO4 SCL (pin D1) on D1 board is connected to SCL pin on Sonoff
• GPIO4 SDA (pin D2) on D1 board is connected to SDA pin on Sonoff

Do you know what could be wrong?

[mightymos]

The software I2C library is probably taking too long to time out (if nothing is connected to bus) and then the software watchdog is thinking the program is stuck so it forces a reset. I probably need to improve the sketch so this does not happen.

I think you can make it work. Have ground connected on the target but 3.3V disconnected on target.

Upload the sketch to the D1 board. Then immediately change to serial monitor and type "handshake". Then apply 3.3V to target board.

I think target should then detect handshake and other instructions can be followed.

[syepes]

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?

[mightymos]

It looks correct...it is always a possibility that without soldering in headers you have a loose connection(s). I think you should try it by leaving the 3.3 V Power Supply plugged into USB but leave the VCC pin on the target end disconnected. Then when you are ready to apply power touch and leave 3.3V pin touching.

If you cannot get it to work we can investigate further.

[mightymos]

What output are you seeing in serial monitor?

[mightymos]

I pushed changes to the OnbrightFlasher repo. I shortened the softwire i2c timeout so that the watchdog on the processor should no longer reset while waiting in handshake state.

I get this output in the serial monitor now:

Ready.
Entering [idle] state.
Type [handshake] to attempt connection to target.
Type [idle] and then [handshake] to start from the beginning
handshake
Reset to handshake

Chip failed to read
Can try command [signature] over serial port to see if Chip read: A
signature
Read chip type...Chip read: A

[syepes]

Thanks for the update, I am still having the same issue. I never see the Connected... string message in the monitor. I have also tried another D1 board :-( Question, when powering the Bridge on VCC do we need to press the reset button or something else that I am missing?

[mightymos]

You should not need to hold the reset button on the bridge during power up. The reset button is only used to place the ESP8265 in boot mode.

With the fixes now, you should just need to upload sketch to D1 board once. Just leave it running and can issue commands. Type [idle] to start over, followed by [handshake] if retrying handshake. Then apply power to target bridge.

As you can see in my output above, for some reason now the chip read is failing during handshake. However handshake must have worked because I am able to issue [signature] command and read a hex "A" which is correct for the chip type.

What serial output do you get when you try?

[mightymos]

I've updated OnbrightFlasher and the handshake seems to be reliable now. Appreciate anyone that can test on D1 board.

[matlab22]

I would like to test it but i just have a esp32 s3 mini

[the-mentor]

I've updated OnbrightFlasher and the handshake seems to be reliable now. Appreciate anyone that can test on D1 board.

I'll try to so some testing tonight

[mightymos]

@matlab22 I added support for ESP32 which works on my ESP-WROOM-32. But I need to know exactly what gpio pins are available on your board. Can you provide a link to the actual board you purchased?

@syepes I realized the instructions were unclear in readme to say the least...one potential problem is in Arduino IDE you need to set serial monitor to "Both NL & CR" at 115200 baud. Otherwise the command parsing will never work. I have gotten ESP8265 to sonoff target and ESP32 to sonoff target working reliably and others are testing.

@the-mentor Thanks, appreciate the help for syepes.

[matlab22]

I have a yd-esp32-23 hosting an esp32-s3-wroom-1. https://mischianti.org/vcc-gnd-studio-yd-esp32-s3-devkitc-1-clone-high-resolution-pinout-and-specs/

[mightymos]

I have a yd-esp32-23 hosting an esp32-s3-wroom-1. https://mischianti.org/vcc-gnd-studio-yd-esp32-s3-devkitc-1-clone-high-resolution-pinout-and-specs/

Ok, this implies under gpio_set_pull_mode that all pins which are NOT input only have pull ups and pull downs: https://docs.espressif.com/projects/esp-idf/en/latest/esp32s3/api-reference/peripherals/gpio.html#gpio-rtc-gpio

Looking at your board you could probably just use GPIO4 and GPIO5 for SDA and SCL respectively. You will need to change this yourself under ESP32 macro in sketch for sdaPin and sclPin.

I am not sure if there is a specific macro defined for this board so as to avoid manual editing pin definitions. What board do you choose in Board Manager for programming?

https://github.com/espressif/arduino-esp32/blob/master/boards.txt

[matlab22]

I just use the esp32s3.name=ESP32S3 Dev Module

[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.