search

arendst / Tasmota

Alternative firmware for ESP8266 and ESP32 based devices with easy configuration using webUI, OTA updates, automation using timers or rules, expandability and entirely local control over MQTT, HTTP, Serial or KNX. Full documentation at
https://tasmota.github.io/docs
GNU General Public License v3.0
21.59k stars 4.69k forks source link

Adventures with Sonoff Zigbee Bridge #8583

Closed s-hadinger closed 3 years ago

s-hadinger commented 3 years ago

Have you looked for this feature in other issues and in the docs?
Yes

Is your feature request related to a problem? Please describe.
This issue is opened to track progress for the support of Sonoff Zigbee Bridge.

Describe the solution you'd like
Z2T full support, like with CC2530.

Describe alternatives you've considered
CC2530

Additional context
This issue is only to report about progress and issues on the Sonoff Zigbee Bridge with Tasmota. It shall not contain any speculation like in #8197. All speculations should stay in #8197.

s-hadinger commented 3 years ago

The form factor is cool and similar to the Sonoff RF Bridge, in white.

IMG_0595

Opening the box is super easy, remove the 4 rubber protections, and unswcrew. IMG_0596 IMG_0597

As reported before, it is based on ESP8266EX so flashing Tasmota shouldn't be hard.

IMG_0598 IMG_0599

The good news is that pads are easily accessible. Sonoff made available lots of GPIOs, although it looks only RX/TX (GPIO1/3) are used to communicate with the Zigbee module.

There is a Z_RST pad which should be the RESET for the Zigbee module. This may be useful since GPIO1/3 are connected to the module. If we want to flash Tasmota without interference, I guess we should keep Z_RST low.

Useful pads: GPIO1, GPIO3, GPIO0, 3.3V, GND, Z_RST IMG_0601

We'll however need to wait a little more to analyze the protocol, my logic analyzer is arriving next week.

s-hadinger commented 3 years ago

First test with the Sonoff Zigbee Bridge in pairing mode, using another Z2T in device mode.

The Z2T device finds the Sonoff coordinator, connects to the network but then nothing happens, the device does not receive any more packets from the coordinator. It looks like Sonoff is restricting to its own devices, either filtering on IEEE Address, or waiting for a specific packet.

s-hadinger commented 3 years ago

Listening to TX at boot, 76800 bauds, 8N1, here is what is printed to Serial: (3 sequences)


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

load 0x40100000, len 2592, room 16 
tail 0
chksum 0xf3
load 0x3ffe8000, len 764, room 8 
tail 4
chksum 0x92
load 0x3ffe82fc, len 676, room 4 
tail 0
chksum 0x22
csum 0x22

2nd boot version : 1.7(5d6f877)
SPI Speed : 40MHz
SPI Mode : DOUT
SPI Flash Size & Map: 16Mbit(1024KB+1024KB)
jump to run user1 @ 1000
OS SDK ver: 2.0.0(e271380) compiled @ Mar 30 2018 18:54:06
phy ver: 1055_1, pp ver: 10.7

rf cal sector: 507

Then the ESP pulls down Z_RST for 10ms.

The MCU sends two identical frame burst at 115299 bauds:

FE 0D 01 80 02 00 00 00 00 01 01 04 74

The first is sent at power-up, then the ESP resets the MCU and it sends it again.

Zigbee Reset

First line is TX, second is RX, third is Z_RST

Edit: corrected baud rates.

s-hadinger commented 3 years ago

Here is the complete sequence at start (115200 bauds, 8N1):

Edit: encoding looks similar to the one used by CC2530:

arendst commented 3 years ago

So it starts with fe followed by the total byte count

s-hadinger commented 3 years ago

Aha, listening to the UART port of the MCU:

First sequence:

Reset info: 0x04 (PWR)
Extended Reset info: 0x0401 (HV )

52ms later:

init pass
Build Time Apr 29 2020 17:12:29
EEPROM init: 0x00
EMBER_NETWORK_UP 0x0000
[Z3Coord_callbacks.c:emberAfStackStatusCallback]
status = 0x90
Send Data:
FE 0D 01 80 02 00 00 00 00 01 01 04 74 

Enter password:

Then after the ESP pulls down MCU Reset, we see a similar sequence again:

Reset info: 0x03 (EXT)
Extended Reset info: 0x0301 (PIN)
init pass
Build Time Apr 29 2020 17:12:29
EEPROM init: 0x00
EMBER_NETWORK_UP 0x0000
[Z3Coord_callbacks.c:emberAfStackStatusCallback]
status = 0x90
Send Data:
FE 0D 01 80 02 00 00 00 00 01 01 04 74 

Enter password:

And 175ms later:

InitNetworkEventHandler
PANID = D136
Hedda commented 3 years ago

@s-hadinger It would be absolutely great if that SONOFF ZBBridge (SONOFF Zigbee Bridge) already has its firmware based on EmberZNet Zigbee Stack with their standard EZSP (EmberZNet Serial Protocol) serial protocol interface / API over UART bus on the EFR32 base MCU, as it now looks to have.

If it already has EmberZNet firmware with EZSP interfaces then will hopefully not need to worry about any firmware upgrade of in the first place and instead just focus on hacking its ESP8266 instead and maybe offering a serial server service (like ser2net or similar) to offer remote access the Zigbee module.

Otherwise, if the Zigbee SoC module used in the SONOFF ZBBridge (SONOFF Zigbee Bridge) is at all similar to other Silicon Labs EFR32 family modules, like the E180-ZG120B by Ebyte, then at least according to the Ebyte manual can flash the firmware on EFR32 module with J-Link over GPIO/JTAG.

JTAG

SWD (Serial Wire Debug)

In the Ebyte E180-ZG120B manual, the "burning program" sais that GPIO pins for J-Link interface is:

FYI, there's also a related discussion about flashing firmware on these type of EFR32 modules here:

If still are serious about flashing that firmware then checkout a Silicon Labs document called AN136

Maybe it is possible to just use the Command-Line Interface (CLI) of Simplicity Commander as it supports using Serial Wire Debug (SWD) or Joint Test Action Group (JTAG) as the target interface?

AN136 otherwise refers to other documents for many different methods, like SWD, JTAG, and C2:

MarkDing who work at Silicon Labs summarized their Serial Wire Debug (SWD) in their forum here:

The same @MarkDing also maintains a wiki about development with Silicon Labs IoT MCU SoCs:

Hedda commented 3 years ago

To all, by the way, here are a few related discussions specifically about hacking SONOFF ZBBridge:

s-hadinger commented 3 years ago

More data:

When entering Pairing mode, MCU sends:

FE 0B 02 01 02 F9 FF 00 04 37 C1

MCU responds:

FE 0B 02 41 02 F9 FF 00 04 00 B6

MCU logs:

Recv Data:

FE 0B 02 01 02 F9 FF 00 04 37 C1 
pJoin for 55 sec: 0x00
Open network: 0x00
Send Data:
FE 0B 02 41 02 F9 FF 00 04 00 B6

Edit: sending a new Pairing mode request shows:

FE 0B 02 01 02 F9 FF 00 0B 37 CE 
pJoin for 55 sec: 0x00
Open network: 0x00
Send Data:
FE 0B 02 41 02 F9 FF 00 0B 00 B9

It shows that the n-2 byte is actually a sequence number, probably so that the ESP knows which response correspond to which request.

s-hadinger commented 3 years ago

Aborting Pairing mode:

Recv Data:

FE 0B 02 01 02 F9 FF 00 03 00 F1 
pJoin for 0 sec: 0x00
Send Data:
FE 0B 02 41 02 F9 FF 00 03 00 B1
s-hadinger commented 3 years ago

Finally, when trying to join the network from a Z2T device, the MCU logs the following but does not report to the ESP:

[Z3Coord_callbacks.c:emberAfTrustCenterJoinCallback]
add dev:NodeID=4351 mac:4B:CB:9D:19:00:4B:12:00ParentOfNewNode=0, status = 1 decision=0
Adding device to the queue
Adding to queue at index 0

It looks like Ember layer did accept the connection, but the app layer dropped it; probably filtering based on IEEE address.

s-hadinger commented 3 years ago

Connecting to the EFR32 with a JLink probe (SWD mode using SWDIO and SWCLK), it shows that the device is debug-locked but can be erased and should be possible to reflash with a custom firmware:

EFR32

Or Sonoff is kind enough to give the unlock key?

digiblur commented 3 years ago

Excellent work so far! I see they have a new board revision listed on yours. I'll have to compare to see what changed.

stevew817 commented 3 years ago

Or Sonoff is kind enough to give the unlock key?

According to that screenshot, there is no unlock key on the device, so Sonoff wouldn't be able to give you one either way :)

Hedda commented 3 years ago

Sounds as if don't need an unlock key to erase & flash firmware via JTAG interface or SWD interface:

Simplicity Commander support CLI as the target for EFx32 but it is not open-source or for Arduino.

"Simplicity Commander is a software package provided by Silicon Labs that provides a very powerful GUI and command-line utility for working with your EFR32 parts. With Simplicity Commander you can flash firmware (bootloaders and applications), update the WSTK firmware, reset locked parts and unlock debug access. It is the EFR32 version of the ISA3 Utilities."

Simplicity Commander GUI and CLI interfaces with software download for Linux, Mac, and Windows.

Simplicity Studio also includes a simpler tool called "Flash Programmer" that allows the user to flash the device with a binary or hex file, supporting flashing to EFM8, EFM32, C8051, EZR32, and EFR32.

Hedda commented 3 years ago

Will you brick the EFR32 if erasing application firmware also erases the bootloader firmware?

That is if erasing the bootloader firmware is not optional, sounds strange if that is not optional?

If that is the case and EFR32 gets bricked then can you still unbrick it by flashing a new bootloader via the JTAG or SWD interface on EFR32 using just a Raspberry Pi / Arduino or will you need a purpose-built debugger for EFR32 or an official EFM32 Gecko Development Kit to unbrick it?

Gamester17 commented 3 years ago

Or Sonoff is kind enough to give the unlock key?

ITead (Sonoff) as a company has benefited a lot from alternative firmware from the community in the past and there are today more aware of that fact so would not hurt for you to ask.

Suggest that you sent a mail to "Jerry Shi" <jerry.shi 'at' itead.cc> and "Stan Li" <stan.li 'at' itead.cc> and explain that you are an open-source developer from the Tasmota community that is looking into developing an alternative firmware for the Sonoff ZBBridge and are therefore wondering if they could share the key to disable the debug lock. Jerry Shi and Stan Li

I have no affiliations to ITead/Sonoff myself however in the past I have sent a few questions or suggestions to them and got relatively quick replies from Jerry Shi and Stan Li. I think that Jerry is in marketing at ITead so he has to pass on the technical questions to the developers, however, I know he helped the community in the past and since he is in marketing I assume he would especially helpful if it directly or indirectly helps ITead sell more products, which is something Tasmota surely does.

stevew817 commented 3 years ago

Again, there is no secure boot key installed in the device, so there are no obstacles to mass-erasing and writing a new bootloader + application over SWD. The only thing you cannot do is reading out the current firmware.

Whether or not a new firmware can be flashed through the use of the factory-installed bootloader depends on how that bootloader is configured. If ITead's bootloader requires a signed and/or encrypted upgrade image, then those keys would be relevant in order to leverage the factory bootloader for upgrading over the UART interface, instead of having to go through JLink.

Hedda commented 3 years ago

Unlocking / disabling debug lock also erase all data to prevent reading or?

That is, does it also do a full erase of bootloader + application firmware?

That part is still unclear for me even after trying to interpret that from these:

https://www.silabs.com/community/mcu/32-bit/knowledge-base.entry.html/2016/11/04/unlock_a_brickedefr-GkC7

https://www.silabs.com/community/mcu/32-bit/knowledge-base.entry.html/2018/06/07/erasing_the_lockbit-WVQL

https://www.silabs.com/community/mcu/32-bit/knowledge-base.entry.html/2017/10/09/how_to_lock_or_disab-mb2d

https://silabs-prod.adobecqms.net/content/usergenerated/asi/cloud/content/siliconlabs/en/community/mcu/32-bit/knowledge-base/jcr:content/content/primary/blog/unlock_a_brickede-xkAm.social.$%7BstartIndex%7D.10.html

https://silabs-prod.adobecqms.net/content/usergenerated/asi/cloud/content/siliconlabs/en/community/mcu/32-bit/forum/jcr:content/content/primary/qna/bricked_efr32-1EjX.social.list-item.0.15.html

https://silabs-prod.adobecqms.net/content/usergenerated/asi/cloud/content/siliconlabs/en/community/mcu/32-bit/knowledge-base/jcr:content/content/primary/blog/debug_unlock_withj--QGXr.social.0.10.html

stevew817 commented 3 years ago

@Hedda correct. Unlocking a locked device, or disabling a debug lock that has been set, will result in an erase of main flash and RAM.

Some devices in EFR32 Series 1 (e.g. EFR32MG12) have a separate flash area where a bootloader optionally can reside. This is not the case for Series 2 (e.g. EFR32MG21 as used here), where a bootloader always resides at the start of main flash, and is thus erased together with the rest of it during an unauthorised unlock sequence.

s-hadinger commented 3 years ago

Bad day. I couldn't flash Tasmota on the ESP8266. The flash is corrupt and comparing by reading back the content, there are some random bit flips. Even reading the same location gives random bit flips. I changed the power supply and from another host (Raspberry Pi) but I get the same corruption.

This should be the easy part. I'm stuck...

arendst commented 3 years ago

Are you sure the serial interface is free of noise from the attached zigbee part? It might interfere with the firmware upload and download.

arendst commented 3 years ago

Also flash while usb powered.

s-hadinger commented 3 years ago

There must be noise. I force the zigbee reset to low to make sure the MCU doesn't interfere, no change. I was USB powered too, with 3 different ways (battery, laptop and charger).

I flash a 4KB block full of 0xFF, and read it back. There are ~4 bit flips in the block. And re-reading the block, some but flips remain, some change. Very weird...

I saw similar bit flips when flashing the entire Tasmota firmware.

Since the the firmware is sent in compressed form by esptool.py, I must not be the UART interface, otherwise the flash should be completely corrupt.

Only GPIO 6/7/8/11 are connected to the SPI Flash, so it's either DIO or DOUT.

On a side note, GPIO9/10 have Pads but are not connected to anything, no pull-ups/down. Could this be where the noise come from?

Even worse, the full chip erase doesn't work at all. It erases nothing. Yet the data sheet confirms that it should work.

s-hadinger commented 3 years ago

I'm almost certain there is an issue with the Flash or the ESP-Flash communication. Or with Flash erasing.

I flashed a 4KB file full of 0xFF. The file is transmitted in ZIP format by esptool.py and the checksum is locally tested. And it's always wrong.w

Then I flashed a 4KB file full of 0x00. Now the flash went ok.

kugelkopf123 commented 3 years ago

@s-hadinger Why not simply unsolder the flash chip and replace it with a flashed one from a Wemos or NodeMCU? At least you'll have Tasmota on it and you can continue testing. You could also solder the one from the zigbeebridge to the Wemos and test if the chip has a defect.

s-hadinger commented 3 years ago

@kugelkopf123 That would be in last resort. But I don't have a heat gun nor spare flash chips, or I need to crack open a Wemos D1.

After doing more tests, it looks like erasing flash is broken. Some bits never go back to 1 or start flipping randomly.

I have a second Sonoff Zigbee bridge but I'm reluctant in potentially bricking it too.

kugelkopf123 commented 3 years ago

@kugelkopf123 That would be in last resort. But I don't have a heat gun nor spare flash chips, or I need to crack open a Wemos D1.

After doing more tests, it looks like erasing flash is broken. Some bits never go back to 1 or start flipping randomly.

I have a second Sonoff Zigbee bridge but I'm reluctant in potentially bricking it too.

Never needed a heatgun. Had done it always this way: https://youtu.be/0KWkNDRQW5E So, if you think you have already destroyed the device, go ahead! nothing to lose.

s-hadinger commented 3 years ago

Thanks. I will try. Do you know how to open a Esp8266mod metallic case?

kugelkopf123 commented 3 years ago

Thanks. I will try. Do you know how to open a Esp8266mod metallic case?

It's soldered on too. https://wordswithcomputers.files.wordpress.com/2017/10/20171007_1717081.jpg So it might be possible to disconnect it with the same method. I've never done it before, though. Don't you have a Shelly or Sonoff Basic? There's no metal shield covering the chips. Maybe you also have a Wemos d1 Mini v3. They're not covered there either.

Hedda commented 3 years ago

WeMos D1 (all models?) should have the same type of "ESP8266EX" as Sonoff ZBBridge so could possibly be the perfect hardware for creating alternative development kit platforms for this project?

As for the Zigbee MCU SoC part it seems to currently be a bit harder to find inexpensive alternative hardware modules with Silicon Labs EFR32 Series 2 (EFR32MG21) MCU SoC if you do not want to buy Silabs official EFR32xG21 Wireless Gecko Starter Kit (SLWSTK6006A) for $479 US-dollars on your own:

Though three developers could co-purchase such a kit to split as it contains three complete development boards and EFR32MG21 Zigbee radio modules, plus a bonus is that purchasing the starter kit also it gives your Silabs registered account access to the Zigbee stack which is not publicly available otherwise.

SLWSTK6006A kit is sold worldwide by Farnell, Digikey, Mouser, Arrow/Verical, Newark, and Element14.

However, if it would be good enough to use a Silicon Labs EFR32 Series 1 (EFR32MG12) module in a DIY development kit instead, if so then check out this Ebyte E180-ZG120B module and the E180-ZG120B-TB (EFR32 Test Board) which can both be found relatively inexpensive from ex. Aliexpress or eBay.

At least Silicon Labs seem to use the same SDK and Zigbee stack for all EFR32; EFR32 Mighty Gecko Wireless SoC Series 1 = EFR32MG1/EFR32MG12/EFR32MG13/EFR32MG14, and EFR32 Wireless Gecko Series 2 =EFR32MG21 "Mighty Gecko". Same Zigbee API too however a newer version API.

Hardware-wise all Wireless Gecko Series 1 MCUs obviously has less RAM and FLASH memory as well as being based on Arm Cortex-M4 instead of an Arm Cortex M33 CPU that Wireless Gecko Series 2 has.

FYI, alternative hardware platforms for development platforms was also suggested/discussed here:

mtx512 commented 3 years ago

I'm currently working with a few EFR32 modules ((MGM111A256V2, MGM13P12F512GA) through my work and have access to the Zigbee stack and can generate a UART NCP build if required or help in any other way. May save you having to purchase the Silabs dev kit.

I reviewed the protocol dumps by @s-hadinger and initially thought the serial protocol was based on EZSP SPI interface which also starts with a leading 0xFE however the rest of payload doesn't match the EZSP protocol definition. So it looks like its a custom serial protocol that is integrated with the Ember NCP stack.

I suggest using Simplicity Commander to try to take a flash backup of the EFR32. Unfortunately I don't have a Sonoff Zigbee Bridge otherwise I would test it.

@s-hadinger I suspect the EFR32 may be using the Gecko Bootloader, to access it you can connect a serial console 115200,8,N (the bootloader may be configured for XMODEM).

  1. ETX - Pin PB01 ERX Pin PB00 ( 2nd & 3rd pin from top on left hand side of module)
  2. Ground PA00 (4 pin from top on left hand side of module)
  3. Temporary ground the reset pin Z_RST (nRST) to reset (top pin of right handside of module)

Hopefully the bootloader prompts appears,

@s-hadinger Also when your flashing the ESP try setting both IO0 & LOG low and IO15 high to ensure they stay constant through the flash.

grobasoz commented 3 years ago

Looking at the messaging on the CLI ("MCU Logs" over ZigBee Usart) it seems like Sonoff are using a custom application on the EFR32 and not the Silabs NCP (ie EZSP protocol). It's not that common for the Silabs NCP to have a CLI interface either... the "Network Up" etc messages are normally posted on the Host side. This would make sense due to the memory constraints of the ESP and the effort required to create the NCP support application in the ESP. Sonoff also use a similar packet structure to the TI ZNP interface (though TI use a payload length and Sonoff a packet length in byte position 2).

Since there is already Tasmota to ZigBee firmware based on the TI ZNP protocol, it would make sense to build an EFR32 app that works in a similar fashion to the ZNP and uses the ZNP packet structure, perhaps 'upgraded' to ZigBee 3.0 with Green Power support.

As the EFR32 in the Sonoff product is probably not running the Silabs NCP firmware, I suspect they have also used the Gecko 'Application' Bootloader as opposed to the 'Standalone' XModem bootloader as suggested above. The EFR32 has enough flash to support internal storage of bootload firmware of about 512k... so you could potentially run the ZigBee/Bluetooth app and allow firmware updates over Bluetooth.

image

The CLI is on the standard EFR32 USART0 port (TXD = PA5, RXD = PA6), and the ESP serial on PB0 and PB1 as per the image above. They are probably disabled in the EFR32 app before updating the ESP.

Hope this helps... Gary.

Hedda commented 3 years ago

@mtx512 if and when you do build compatible Zigbee coordinator firmware for the EFR32MG21 that is in Sonoff ZBBridge please consider uploading/hosting the firmware images in a GitHub repo?

That is, something similar to what @SillyDay does here https://github.com/SillyDay/EFR32

@SillyDay created that repo as part on the discussion in https://github.com/Koenkk/zigbee-herdsman/issues/168

Hedda commented 3 years ago

it seems like Sonoff are using a custom application on the EFR32 and not the Silabs NCP (ie EZSP protocol). It's not that common for the Silabs NCP to have a CLI interface either... the "Network Up" etc messages are normally posted on the Host side. This would make sense due to the memory constraints of the ESP and the effort required to create the NCP support application in the ESP. Sonoff also use a similar packet structure to the TI ZNP interface (though TI use a payload length and Sonoff a packet length in byte position 2).

Since there is already Tasmota to ZigBee firmware based on the TI ZNP protocol, it would make sense to build an EFR32 app that works in a similar fashion to the ZNP and uses the ZNP packet structure, perhaps 'upgraded' to ZigBee 3.0 with Green Power support.

@grobasoz would it then as an alternative idea maybe even be possible to build EFR32 app(s) that implements the bellows library and maybe also the zigpy library on the EFR32 MCU so that Tasmota would instead interface with them instead of implementing support for Silabs EZSP protocol directly in the Tasmota firmware?

I understand that bellows can run as a stand-alone application without zigpy and then you could choose if you want also would want to implement zigpy in an EFR32 app or in Tasmota or not at all?

Note! bellows don't yet support later versions of Silabs EZSP protocol so have to be updated. Read:

grobasoz commented 3 years ago

@Hedda, Sorry I don't know anything about zigpy/bellows so will need to look at it first and maybe do some testing.

Hedda commented 3 years ago

@grobasoz well for starter those are written in Python so the first question if Python based applications can run or can be made to run on an EFR32 MCU or easily ported to something that will?

I'm not one of its developers (nor do I have the skill to be one myself) but as I understand it the purpose of the bellows started out as a high-level wrapper that abstract Silabs EZSP interfaces as well as have give you ZDO and ZCL functionalities (with CLI) as well as include an application framework with device state persistence and present it as a CLI client.

zigpy (which is a refactoring of bellows) is an Zigbee stack integration project gives you the option to split out the non-proprietary ZDO and ZCL functionalities (with CLI), as well as the application and device state management parts (with CLI) from bellows to the separate zigpy library so that other projects can implementation it in order to support many "radio libraries" in a common way as each "radio library" will only handle the proprietary interface protocols from different manufacturers.

So, in this case, you would really only need to use the bellows library in a stand-alone implementation and not the zigpy library, however, if Tasmota could run the zigpy library (and if an ESP8266 has enough resources) then it could potentially be less complicated to implement support in Tasmota for other Zigbee radios from different manufacturers.

As far as I know Home Assistant's "ZHA" integration component is the only project fully using zigpy

However, I read that more projects do use bellows in a stand-alone implementation without zigpy.

s-hadinger commented 3 years ago

zigpy/bellows is actually an EZSP client implementation.

@mtx512 thanks for the tip, I didn't know GPIO13 & GPIO15 had an influence when flashing. I will try but not before mid next week.

@grobasoz Thanks a lot for the pinout of the module.

So the complete EFR32 module pinout and ESP8266 connection is as follows:

Additional pads for ESP8266:

grobasoz commented 3 years ago

@Hedda - thanks for the zigpy/bellows summary... In short - Micropython on EFR32 is not easy - though has been done...

@s-hadinger - thanks for the pinout summary. I have managed to cobble together a similar system here for development as my Sonoff ZigBee Bridges are still "on their way"...

mtx512 commented 3 years ago

@s-hadinger thanks for the pinout summary, so my instructions to flash ESP8288 need a correction ( I thought LOG was GPIO2):

  1. Ensure (IO0) GPI00 & (IO15) GPIO15 are both low
  2. Ensure GPI02 is high (I would assume its pull high by default)
mtx512 commented 3 years ago

Based on the pinout summary as a first step we could create the EZSP NCP firmware configured so its outputs to Z_TX/Z_RX since these aren't used by ESP. With this approach you can attach a usb to serial to Z_TX/Z_RX and access the NCP from a Linux machine. I can build a version of Z3GatewayHost that will allow command line access to the NCP this way you can test the capabilities of the EZSP NCP.

Since you have to erase the EFR given the debug lock, I would also need to generate a new gecko bootloader as that will be required. Once the bootloader is deployed it be would possible to upload the NCP firmware through the bootloader if we enabled it through PA00 (GPIO15).

s-hadinger commented 3 years ago

@mtx512 This sounds like a plan. I couldn't figure out the Flash size of the EFR32. Do you habe this informatio?

mtx512 commented 3 years ago

@mtx512 This sounds like a plan. I couldn't figure out the Flash size of the EFR32. Do you habe this informatio?

Should be the EFR32MG21A020F768IM32 so 768kB flash and 64kB Ram that is my guess. If you have SimplicityCommander then 'device info' icon will show the MCU info.

mtx512 commented 3 years ago

@s-hadinger created a bootloader and ncp if you want to test, see here.

Afer the EFR flash is wiped you can flash the bootloader with JFlashLite (JLink) or SimplicityCommander. Since there is no application the bootloader should jump to its upload menu (connect usb serial to Z_TX/Z_RX) :

Gecko Bootloader v1.A.3 1. upload gbl 2. run 3. ebl info BL > `

If that works then you can flash the ncp-uart-sw.gbl using option 1 and it launch a xmodem session or flash ncp-uart-sw.s37 using JLink.

On the serial console you should see something like this in hex if successful :

1a c2 02 8b c2 8a 7e

s-hadinger commented 3 years ago

Back to business, I flashed a second Sonoff device successfully. The first had definitely a faulty flash memory.

And booting the EFR32 with PA00 low, here is what I see on the console output:


Gecko Bootloader v1.9.1.04
1. upload gbl
2. run
3. ebl info
BL >

Tada! There is a usable bootloader

s-hadinger commented 3 years ago

@mtx512 Is it possible to use the existing Gecko bootloader?

Next question is: how to launch a XMODEM session via ESP8266?

mtx512 commented 3 years ago

@mtx512 Is it possible to use the existing Gecko bootloader?

Yes select 1 and try the ncp-uart-sw.gbl with xmodem transfer .

May want to make a backup of the ERF flash before flashing this one.

s-hadinger commented 3 years ago

Ok, sending 1: 310D0A responds begin upload and then it sends C every second which I suppose is XMODEM protocol.

I don't see any option to make a backup of the ERF flash. Can XMODEM pull data from flash?

mtx512 commented 3 years ago

For XMODEM if your using minicom CRTL-A S (Send file) then select 'x-modem' and then you need to select the file to send. You need to complete all this before the bootloader times out andyou need to select option 1 gain.

To backup the EFR flash see this link. If your willing to sacrifice one device then you don't need to do it.

s-hadinger commented 3 years ago

Thanks. I tried to backup already with JLink but it failed, probably because of the Debug Lock. It's still unclear to me how you choose to flash the bootloader or the application (there is only 1 option). Also I'm not familiar with S37 file format.

If the upload fails in the middle of the transfer, I guess the new app is not flashed, right?