Here we going a gen :-(((

[MattWestb]

Sorry for abusing you more then i wold like to do !!

I have problem with flashing tuya Zigbee GW with one working EZSP.

I have using your https://github.com/grobasoz/zigbee-firmware/tree/master/MG1B232 and i can flashing it OK from the bootloader.

The problem is that tuya have implanting hardware flow control in the NCP and boot loader and in in the SOC side. One user have doing one socat server that making it possible coveting it to ZHA and its working with one older version of EZSP:

2021-02-12 20:34:43 INFO (MainThread) [bellows.zigbee.application] EZSP Radio manufacturer:
2021-02-12 20:34:43 INFO (MainThread) [bellows.zigbee.application] EZSP Radio board name:
2021-02-12 20:34:43 INFO (MainThread) [bellows.zigbee.application] EmberZNet version: 6.5.0.0 build 188

I was getting you firmware being flashed but the socat is blocking the committing but one helpful user have cooking one socat with software flow control so it very likely i can coming out of the brick state without flashing the original firmware back (I like having it as original as possible for getting it working for experience user). The modules hardware from GDB:

(gdb) mon sw
Target voltage: 2980mV
Available Targets:
No. Att Driver
 1      EFR32MG1B 232 F256 Mighty Gecko M3/M4
(gdb) at 1
Attaching to Remote target

(gdb) mon efm_info
DI version 1 (silabs remix?) base 0x0fe08000

EFR32MG1B 232 F256 = Mighty Gecko 256kiB flash, 32kiB ram
Device says flash page size is 2048 bytes, we're using 2048 bytes

Radio si0

(gdb) info mem
Using memory regions provided by the target.
Num Enb Low Addr   High Addr  Attrs
0   y   0x00000000 0x00040000 flash blocksize 0x800 nocache
1   y   0x0fe00000 0x0fe00800 flash blocksize 0x800 nocache
2   y   0x0fe10000 0x0fe12800 flash blocksize 0x800 nocache
3   y   0x20000000 0x20008000 rw nocache

(gdb) dump memory TZ01.bin 0x00000000 0x00040000
(gdb) dump memory TZ01.bin 0x0fe00000 0x0fe00800
(gdb) dump memory TZ03.bin 0x00004000 0x00040000
(gdb) dump memory TZ04.bin 0x0fe10000 0x0fe12800
TZ01 = Flash
TZ02 = User data
TZ03 = APP (Flash - first and main boot loader)
TZ04 = Lockbits

I have not finding any force bootloader pin on the module so i think tuya is only using software reboot to bootloader and reset pin but then you still in the kitchen i like having on bootloader 2 if its possible.

Pinout: RXD PA1, TXD PA0 and boot pin: PB11 (for the boot loader). 115k2 SW. GBL and S37 files is enough.

If you like see some of the story you can taking on look at TYGWZ01 Smart Gateway Rooted and SSH access !! Alternative firmware ?

I have one private repro with the flash dumps but i think its not interesting for you but im inviting you to it if im being wrong. https://github.com/MattWestb/TYGWZ01

One more great thanks with all firmware you have cooked especially the hard cooked EM3581 one that i think you is one of the few in the community that have the knowledge to do.

Best regards and all the best for the best firmware cooker in the community.

Mvh Mattias W

[grobasoz]

@MattWestb - Have added the firmware as requested. It works on my EFR32MG1P and EFR32MG1V but I cannot test the serial bootloading for EFR32MG1B as I don't have any here. Regards, Gary.

[MattWestb]

Thanks thousand times Gary !!!

Im sorry but but i can having pity much crazy ideas but the good its little with help from around the world thinks can happen.

With the tuya ZBGW is one that have doing the rooting hack and compiled the Socat for the "strange" CPU and then one Dan that is very good on Unix that have helping tricking the hard and software flow control problematic. I hope its working OK with SW flow control so i dont need requesting one with HW but i knowing very soon. I shall first trying flashing back the original "tuya NCP backup" and doing one install with your firmware as clean as possible.

Then I have getting the tuya working for "normal" user that i have one tuya LES strips controller with EFR32MG21 (i dont have getting one of the new IKEA GU10 CWS that have one new Silabs modul with EFR32MG21) that im curious is its possible dumping (if tuya have protecting it or not) and if its possible its perhaps its coming more requests for NCP firmware to you but its one later project.

I see you have doing one sniffer for the EM357 :-)) I was thinking all EM35X family was having sniffing part inside the NCP firmware as the EFR32 is having.

Thanks one more time and i reporting back to you is its going good or bad.

Mvh Mattias

[Ordspilleren]

Hello @grobasoz, thank you very much for providing these firmware images! The stock NCP of the device uses HW flow control, whereas the bootloader uses SW flow control (I believe this is normal behavior). Therefore, I think it would be appropriate to also have an NCP with HW flow control so it behaves exactly like the stock firmware. Would you be able to also add this?

[grobasoz]

@Ordspilleren - I would need the GPIO pin numbers for RTS and CTS... Since Mattias didn't provide that, I could only do software flow control firmware :)

@MattWestb - I "lost" my EM3588 sniffer when testing the firmware for HUZUSB so had to find a new sniffer - and have many EM357 available :) I put the EM357 sniffer firmware in the repository so I can remember where to find it again. You can have Packet Trace in EM357 and EM358x as well and it does "sniffing" at chip level. The sniffer I use is for sniffing traffic at remote sites - maybe 1-2km away - so a standalone product is necessary. I can also use Wireshark and Nordic dongle but it is not as detailed as Silabs Packet Analyzer.

[MattWestb]

The module pins you can finding there: https://github.com/MattWestb/TYGWZ01/blob/main/EFR32_Firmware_Dumping.md

Or: 10 | UARTRTS | I/O | Reserved full-interface UART RTS | PA4 14 | UARTCTS | I/O | Reserved full-interface UART CTS | PA5

Mvh Mattias

[grobasoz]

@MattWestb - Thanks Matt - Sorry I missed it earlier :p I will build the files now...

[grobasoz]

@Ordspilleren , @MattWestb - I have uploaded the hardware flow control to the repository. Please test and let me know how it goes - I will test on EFR32MG1V in the morning - I have to rewire the flow control pins.

[MattWestb]

I testing it in one hour how its working and reporting back. I must taking care of my friend that have coming back from the hospital after one hart attack.

[MattWestb]

Uploaded and and changing the Socat to HW and rebooted the ZBGW and is getting:

2021-02-15 12:45:48 INFO (MainThread) [bellows.zigbee.application] EZSP Radio manufacturer: 
2021-02-15 12:45:48 INFO (MainThread) [bellows.zigbee.application] EZSP Radio board name: 
2021-02-15 12:45:48 INFO (MainThread) [bellows.zigbee.application] EmberZNet version: 6.7.8.0 build 373

And i can controlling the LIDL LED stripe (as long Gary have cooking one EZSP for it) :-))

So one more time great work done Gary and Lasse !!!!!!

I testing more then i also like getting the original tuya to working for doing one install as one new user is doing :-)))

Lasse do you like having access to my private git for the tuya ZBGW its no secretes there only the dumping of the flash with my device ID and keys for getting root access on my device ?

[MattWestb]

Lasse You have being invited to it. https://github.com/MattWestb/TYGWZ01 Its only WIP as one scratchpad with references, dumped files and MDs for different task as i have the same problem as Gary is having (but i still remember putting my pants down then i going on the loo so it cant being so bad :-)) ).

[MattWestb]

Gary I can see that tuya have references to the "PTI debugging port, FRC_DFRAME". Is that the interface between the radio and the SOC ? How is it working and is it possible using on no Silabs dev kits ?

You dot needed replaying but im little curious :-(

[MattWestb]

Im very sorry Gary but i have one problem not with your firmware but with tuya application. Its dont like ASH vers 8 and dont talking with the NCP bellicose its only understanding ASH ver 7. I have trying rolling back with tuyas backup (its one OTA file that is in GLB format in the tuya system) but the bootloader is not liking it.

Its not urgent thing but good if user can getting it back to one working tuya GW in one easy way. I can flashing my dumped image with SWD but normal user can not.

May I requesting one 6.5.0.0 with HW as the last one ? As i was saying no stress i have enough for testing and both SW and HW versions looks working fine but need more time for testing.

Thanks in advance all the best for our master cooker.

Mattias

[MattWestb]

Sorry i was not looking but thanks for doing the 6.5.0 !!

I was trying converting the dumped APP but was not successful (reboot in the bootloadeer = app not OK) but now i can trying one real one !!

One more time great thanks and i informing you is its going good or bad !!

Mattias

[MattWestb]

One fast feedback:

Looks working as expected and "tuya app" is up and running but i dont knowing if the GW can handle one NCP update but its being one later problem if its being so.

So now users can going back to one "original" NCP version and have there GW working as expected and not being bricked of "our" upgrade :-))

One more time large thanks for your help Gary !!!!

All the best for you and keep coding hard !!

Mvh Mattias

[MattWestb]

I was trying.\commander.exe gbl create .\BTL_TZBG.GBL --bootloader .\BTL_STD_MG1B232_TX-PA0_RX-PA1_BT-PB11.s37 -d EFR32MG and downloaded the BTL_TZBG.GBL with the bootloader and rebooted and was getting Gecko Bootloader v1.A.3 and hopefully with BL pin. I was not thinking it should working but it was !!

[grobasoz]

@MattWestb - Thanks for the updates :) Regards, Gary.

[MattWestb]

I have seeing one very nice thing in your latest cooked firmware (the EZSP 6.5.1.0) that shall being fixed in the 6.7.8.0 but it can being interesting for you to see how crazy bugs can being. https://github.com/zigpy/zigpy/discussions/604#discussioncomment-419509

I think the EZSP 6.7.8.0 is one great lift for the EFR32 / EM35X coordinators !!

I have loaded the 6.7.8.0 and is continuing sniffing for getting the pull control mechanism working in ZHA without draining the batteries and i think we have finding all pieces on the host side that is doing the bad things and the firmware things in the device only IKEA can fixing.

All the best from the upperside of our globe :-))

Mvh Mattias

Edit: Some devs have starting impalement EZSP v8 in Z2M !!

[grobasoz]

@MattWestb - Hi Mattias - Thanks for the update from the North :) "Golden Gary"... hmmmmmmm? It is best to have Open Source Z2M with EZSP - so good to hear some devs are taking it on. My Z2M is not open source due to Silabs' licensing rules, but as mentioned to Hedda, I prefer it that way - so I can use the Gecko App Bootloader to upgrade firmware OTA from my mobile device... and change device to Thread or CHIP later on... Enjoy Spring in the North! BR Gary.