Updated EM357 NCP firmware "IKEA battery draining fix"

[MattWestb]

ZHA is having problems with IKEA controllers is draining there batteries and wasn't finding the problem for that but its looks being Sonoff Zigbee bridge that is triggering it most (EFR32 second gen). Tasmoat devs have disabled attribute reporting for all IKEA controllers for trying going around the problems. Last week is also reported that Philips HUE dimmer switch is making the same => disabling attribute reporting in tasmota. Also deCOZ is having problems with Samsung and IKEA controllers is draining batteries and have pinpointing that the pull control is not being setted up OK and making the devices staying in short pull mode for infinity so they is redoing the pull control for this devises.

Then having finding the silabs NCP bug in the 6.7.8.0 release i have getting one firmware update for Sonoff zigbee bridge (unsigned then the we dont thwe the cert for signing it) and my "IKEA Billy EZSP". Both firmware is tested by our cooker but not verified to working from the user base but should being OK.

Then its one ZHA user with EM357 stick that is also having the battery draining problems that we cant explaining :-((

So i have asking the cooker if hi can doing one new firmware for that chip also and hi have done it. Its not tested on the specific hardware then hi dont have time for doing it for the moment.

So i asking can some of the experien EM3XX user trying it out if its working and if OK adding it in this repro and if not then we is deleting the files then its bad if they is circulating and crashing / making problems for users.

Link to the firmware: https://github.com/grobasoz/zigbee-firmware/tree/master/EM357

2 things: USB serial was disabled by Silabs in app bilder but is still in the code base so little tricky to get it working. Its one EZSP protocol version 8 and not backward compatible with lower protocols !!

Pleas informing us if its working or not !!

Mvh Mattias

[walthowd]

Do you know off hand if the legacy bootloader on the EM3581 accepts s37 xmodem transfers? Verified the pinout looks good, and tried to transfer the file via ncp.py but it wasn't happy -- Looks like I can convert the s37 format to ebl but need the windows toolkit side of Simplicity Commander to do so.

[MattWestb]

My experience from EFR32 first generation is no :-(( I have only getting GBL files flashed thru bootloader on my IKEA Billy EZSP with gecko bootloader. I have converting s37 files to bin files and it was working OK. And if I dot remember wrong its possible converting s37 to GBL files but i don't knowing if it possible to EBL.

I pinging gary hi have little more experience of EM35X chips.

@grobasoz Wath files can the old Ember bootloader flashing ??

[MattWestb]

If the S37 file is OK then the command 6.6.3 EBL File Creation should working to creating one EBL file for bootloader flashing. ug162-simplicity-commander-reference-guide.pdf

Simplicity commander you can download for different platforms at https://www.silabs.com/mcu/programming-options

Edit: And for converting to one GBL file: 6.7.1 GBL File Creation

[MattWestb]

Was testing converting and its looks working but i cant testing the file then i dont have the hardware.

PS C:\Users\Mattias\Documents\ICCA1\Simplicity Commander> .\commander.exe ebl create NCP_USW_ETRX3_USB_678-115k2.ebl --app NCP_USW_ETRX3_USB_678-115k2.s37 --device em357
QCommandLineParser: option not defined: "certificate"
Parsing file NCP_USW_ETRX3_USB_678-115k2.s37...
QObject::connect: No such signal EblHandler::warning(QString)
Parse .s37 format for flash

Approximate Usage Information:
RAM Usage:
  APPLICATION_CONFIGURATION_HEADER usage: 0x20000000-0x2000148f (5264 bytes)
  Available for future use:               0x20001490-0x200019e7 (1368 bytes)
  Call Stack:                             0x200019e8-0x20002347 (2400 bytes)
  Globals and Statics:                    0x20002348-0x20002fef (3240 bytes)
  NO_INIT and Debug Channel:              0x20002ff0-0x20002fff (16 bytes)
Flash Usage:
  Reserved for Bootloader:                0x08000000-0x08001fff (8192 bytes)
  CODE and Tables:                        0x08002000-0x0802654f (148816 bytes)
  CONST and INITC:                        0x08026550-0x08026cd2 (1923 bytes)
  Available for future use:               0x08026cd3-0x08026fff (813 bytes)
  Reserved for SIMEE:                     0x08027000-0x0802ffff (36864 bytes)

Usage Summary:
  12288 total bytes RAM, 10920 used, 1368 available
  196608 total bytes Flash, 195795 used, 813 available

Setting AAT timestamp to current time: 0x6001f0f6
Create ebl image file
Wrote image stamp into AAT.
DONE

EM357test.zip

Attached the 2 converted file in one zip file.

[grobasoz]

@MattWestb - I have put the ebl files into my repository. Unfortunately I couldn't get your ebl to flash correctly on my test system :( @walthowd - The EM357 files won't work on EM3581 - I only have EM3555, EM3585, EM3587 and EM3588 to test with, no EM3581 - though I seem to recall EM358x being semi-compatible... If I get some time today I will check and create NCP for EM358x. Regards, Gary.

[MattWestb]

Thanks Gary and as you knowing Cimplicity Commander is not one friend of my but i think its little bad its was writing the operation was OK.

I keeping one eye on the progress and reporting back the the original ZHA EM357 user if all is going well.

And I also hoping walthhowd is getting one working 6.7.8.0 update for his EM3581 stick :-))

As normal one big thanks for sharing your knowledge and efforts to the community ! !

Mvh Mattias

Edit: Was not silabs putting the EM35X USB-serial support out of app builder (but living the code tree) in some earlier 6.7.X release ?

[walthowd]

No dice.

root@85d4811845a1:/tmp/silabs# ./ncp.py flash -p /dev/ttyUSB1 -f /data/NCP_USW_ETRX3_USB_678-57k6.ebl 
Restarting NCP into Bootloader mode...
CEL stick
EM3581 Serial Bootloader v5.4.1.0 b962

Successfully restarted into bootloader mode! Starting upload of NCP image... 
ERROR:xmodem.XMODEM:send error: expected ACK; got '\x18' for block 2
ERROR:xmodem.XMODEM:send error: expected ACK; got '\x18' for block 2
ERROR:xmodem.XMODEM:send error: expected ACK; got '\x18' for block 2
ERROR:xmodem.XMODEM:send error: expected ACK; got '\r' for block 2
ERROR:xmodem.XMODEM:send error: expected ACK; got '\n' for block 2
ERROR:xmodem.XMODEM:send error: expected ACK; got 'S' for block 2
ERROR:xmodem.XMODEM:send error: expected ACK; got 'e' for block 2
ERROR:xmodem.XMODEM:send error: expected ACK; got 'r' for block 2
ERROR:xmodem.XMODEM:send error: expected ACK; got 'i' for block 2
ERROR:xmodem.XMODEM:send error: expected ACK; got 'a' for block 2
ERROR:xmodem.XMODEM:send error: expected ACK; got 'l' for block 2
ERROR:xmodem.XMODEM:send error: expected ACK; got ' ' for block 2
ERROR:xmodem.XMODEM:send error: expected ACK; got 'u' for block 2
ERROR:xmodem.XMODEM:send error: expected ACK; got 'p' for block 2
ERROR:xmodem.XMODEM:send error: expected ACK; got 'l' for block 2
ERROR:xmodem.XMODEM:send error: expected ACK; got 'o' for block 2
ERROR:xmodem.XMODEM:send error: expected ACK; got 'a' for block 2
ERROR:xmodem.XMODEM:send error: NAK received 17 times, aborting.
NCP upload failed. Please reload a correct NCP image to recover.
Rebooting NCP...

Regular upload works fine --

root@85d4811845a1:/tmp/silabs# ./ncp.py flash -p /dev/ttyUSB1 -f ncp-uart-sw-6.6.5.ebl
Restarting NCP into Bootloader mode...
CEL stick
EM3581 Serial Bootloader v5.4.1.0 b962

Successfully restarted into bootloader mode! Starting upload of NCP image... 
Finished!
Rebooting NCP...

[MattWestb]

So EM357 firmware not working on EM3581(from bootloader version). :-(

The bootloader is sending back its menu then it have backing out the x-modem download.

Have you trying with terminal like minicom ?

[walthowd]

Yeah, minicom didn't like it either:

But once again regular image transfers via minicom and xmodem without issues:

[MattWestb]

Perhaps its one bootloader problem (I dont have reading the release notes of the EBL) that is not compatible. I think its better waiting for Gary getting time for cooking one EM3581 firmware and getting the right EBL file for EM3581 device.

Do you think this firmware its working for users that is having real EM357 devices ? Perhaps Gary also have time testing it on one EM357 device (I dont have any experience of EM35Xx devices)

And is it mutch users having the EM357 or is all having the newer EM3581 ?

[walthowd]

I pinged my one EM357 tester to see if he's willing to try it out. . .

[grobasoz]

I have added EM358x NCP firmware to my repository. I have tested both EM357 and EM358x on standard Zigbee Z3GatewayHost from Silicon Labs. Have fun, Gary.

[MattWestb]

Great thanks for getting updated firmware for our device !!!

Hope you get time to sleep little between your deep diving in the hard and software jungle.

Mvh Mattias

[grobasoz]

No time for sleep - @Hedda keeps me busy ;) - have to work on Zigbee2MQTT for EFR32! Now need to upgrade my to new stack (I have found bugs in new stack though :( )

[macfly92]

I've succesfully upload NCP_USW_ETRX3_USB_678-57k6.ebl firmware on my Telegesis ETRX357USB adapter. $ python ncp.py scan Connecting to.. /dev/ttyUSB0 57600 True False {"ports": [{"stackVersion": "6.7.8-373", "deviceType": "zigbee", "pid": "8293", "port": "/dev/ttyUSB0", "vid": "10C4"}]} (Previously 6.6.5)

I've also pairing again my Ikea ON/OFF switch to test battery draining. I will report back if I found any problem. Thanks you very much for your hard work !

[MattWestb]

@macfly92 Great work done !!!

After adding and changing binding of your IKEA E1743 do one "reconfigure this device" from the device card so its being sure the pull control setting is being OK in the remote (dont forgetting waking it up before executing the command).

If its not helping the battery draining you have getting one newest possible firmware with many bad bugs fixed and i think you is getting one more stabile system.

You is one of our most brave users trying one nearly untested (not recommended) firmware on you adapter but i like it !!!

Report back if its going well or getting problem here so the devs can putting the firmware on the recommended list or if its bad on the blacklist.

Mvh Mattias W

[MattWestb]

@grobasoz Im vers sorry that my former countryman @Hedda is keeping you busy and i was thinking hi was busy by hunting ice beers in the north !!

And one more time thanks for the great cooking of firmwares for our adapters. 3 is up and running (Tasmota, IKEA Billy and EM357) on one more need being confirmed :-))

And I hope you getting enough time for getting Z2M working with EZSP compatible adapters (i think only protocol version 8 is enough then nearly all adapters is getting new updated firmware) so the users can have more choices on the host system side and its good for the development of the HA community (but bad for commercial deCONZ).

Now is only waiting for good or bad new for the EM358X firmware and then its up to the devs to recommending the 6.7.8.0 or not.

Have one great time and grating to the tequila drunk penguins on the beach !

Mvh Mattias

[macfly92]

@macfly92 Great work done !!!

After adding and changing binding of your IKEA E1743 do one "reconfigure this device" from the device card so its being sure the pull control setting is being OK in the remote (dont forgetting waking it up before executing the command).

If its not helping the battery draining you have getting one newest possible firmware with many bad bugs fixed and i think you is getting one more stabile system.

You is one of our most brave users trying one nearly untested (not recommended) firmware on you adapter but i like it !!!

Report back if its going well or getting problem here so the devs can putting the firmware on the recommended list or if its bad on the blacklist.

Mvh Mattias W

Ok I will do reconfigure right now. Can I somewhere check if it is correctly configured ? No problem for the test, someone must do it and I hesitated to buy another Zigbee dongle so this test was the last hope of my ETRX357USB and I'm happy to contribute. All seem to be good, so I can stick with my Telegesis a little bit more.

Again thanks a lot.

[MattWestb]

If you was waking it up shor before sending the commands you dont getting any warning / errors in the log = OK. If its was sleeping you getting errors / warning in the logs (if i remember right !!).

Its great to knowing its working with the upgrade so can recommending to other users and not braking their favorite hardware and making the user very sad !

So you is being the only one with one most up to date EM357 around in the community :-)))

[macfly92]

If you was waking it up shor before sending the commands you dont getting any warning / errors in the log = OK. If its was sleeping you getting errors / warning in the logs (if i remember right !!).

Ok, I have done the reconfigure but without debug on the ZHA log. I will check the battery drain, and if it is not good, I will dig more.

Its great to knowing its working with the upgrade so can recommending to other users and not braking their favorite hardware and making the user very sad !

So you is being the only one with one most up to date EM357 around in the community :-)))

Ahah, great ! I hope I will not be the only one, but the first one for sure ;)

[igalarzab]

I just flashed the file NCP_USW_EM358x_678_57k6.ebl from here to my HUSBZB-1, thinking it was the same chip... and now I cannot access it anymore... did I just break my USB stick? :_D

[sreknob]

@igalarzab - if you're not getting a response from the stick, you could try recovery instructions in the readme.

[igalarzab]

@sreknob thanks! Yes, I saw the instructions but I don't think I have the right tools for it (also, they seem to be a bit out of my low-level knowledge :D)

Also, out of curiosity... what would have been the right firmware to patch?

[walthowd]

You can pop open the case and recover with just a paperclip shorting the two shown points or a set of tweezers.

Correct firmware is here: https://github.com/walthowd/husbzb-firmware#selecting-the-correct-firmware-file

[igalarzab]

Thanks for the help @walthowd, I appreciate it

I used a paperclip to touch both TP17 and GND and I can see this in the dmesg output:

[182735.503101] usb 1-1.2: new full-speed USB device number 22 using xhci_hcd
[182735.610247] usb 1-1.2: New USB device found, idVendor=10c4, idProduct=8a2a, bcdDevice= 1.00
[182735.610268] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=5
[182735.610280] usb 1-1.2: Product: HubZ Smart Home Controller
[182735.610292] usb 1-1.2: Manufacturer: Silicon Labs
[182735.610303] usb 1-1.2: SerialNumber: C1301256
[182735.623742] cp210x 1-1.2:1.0: cp210x converter detected
[182735.632709] usb 1-1.2: cp210x converter now attached to ttyUSB0
[182735.635440] cp210x 1-1.2:1.1: cp210x converter detected
[182735.644176] usb 1-1.2: cp210x converter now attached to ttyUSB1

Now the problem is that I'm not very sure how to follow... sorry if my questions seem a bit stupid :) I've tried using minicom to upload the ebl file but I must be doing something wrong as I can only see

Sending /tmp/silabs/ncp-uart-sw-6.6.5.ebl, 1167 blocks: Give your local XMODEM receive command now.
Xmodem sectors/kbytes sent:   0/ 0k
Retry 0: Timeout on sector ACK
...

What are exactly the steps after shorting TP17 and GND?

Again, thanks for the help, and sorry for hijacking this issue! 😓

[walthowd]

You should see a bootloader menu in minicom first -- Select upload ebl (option 1, I believe) and then send your file.

Connect minicom to the /dev/ttyUSB1 (115200 no flow, 8/n/1) -- pull stick, short TP17 to GND, plug stick back in, unshort TP17, hit enter a few times on keyboard, see if you get to the menu. If not, repeat.

[igalarzab]

amazing, it works... thank you very much, really!! 🎉 🎉

I created a PR with some detailed instructions just in case it's useful to someone in my same situation :)

Also, going back to the initial matter of this ticket... I flashed the wrong image (v6.7.8) trying to fix the battery drain of the Ikea lights. I guess there is no firmware with the fix for this specific device released yet, am I right?

[walthowd]

Here is the correct file for EM3581/Nortek GoControl users to test:

https://github.com/grobasoz/zigbee-firmware/blob/master/EM358x/NCP_USW_EM358x_678_57k6.ebl

Let me know your results -- You will need to reconfigure your end devices (ikea) after installing to reconfigure polling mode.

[igalarzab]

Uhmm... that's the image I patched last time and it broke the stick (I lost access to it)... :/

Edit: Yeah, I tried again with that file and it broke the stick again (I had to reset it one more time), so there is something wrong with that file

[grobasoz]

@igalarzab - Would you be able to send me a closeup picture of your USB Stick showing the main chip? The firmware I created for the EM3581 had standard EM35xx pinouts for the serial ports. I test all my firmware before releasing but will test that version again - just to be sure :) Regards, Gary.

[igalarzab]

@grobasoz sure! here you have the image, please, let me know if I can help you somehow 🙂

[grobasoz]

@igalarzab - Thanks - that's a pic of the Z-Wave chip. Is there another chip on the opposite side? Thanks, Gary.

[igalarzab]

photo of the other side

[grobasoz]

@igalarzab - Thanks for the images - At this stage the firmware I have supplied will most likely NOT work with this product. As mentioned there is a Z-Wave radio, and the Zigbee (EM3581) has an additional power amplifier (from Skyworks) and I don't have the details on either. I would say it would be easier to either go with either their firmware or try a new USB stick... Regards, Gary.

[walthowd]

@grobasoz I don't know if it's useful, but the HUSBZB-1 should use the standard pin out as the EM3581 reference design, with PB0 and PB1.

Silicon Labs used to include pre-compiled firmware with each EmberZNet release (or with Simplicity Studio, I forget) and those standard pre-compiled firmwares always worked fine on the stock HUSBZB-1.

[grobasoz]

@walthowd - Thanks - that does help! The firmware I created was based on the Ember development board (Dev 0680) which uses PB1 (TXD) and PB2 (RXD), PB0 for Power Amplifier and PC1 for Antenna Control. Since pre-compiled firmware worked on the HUSBZB-1, the firmware should work as well. I don't have an EM3581 to test with (only EM3585, EM3587, and EM3588) but the EM3581 firmware I created all works on the boards I have here. I will build a Power Amplifier version and test again today... Which version of precompiled firmware works on HUSBZB-1? Perhaps I can test here to see if it works on my Ember Development Kit? Regards, Gary.

[walthowd]

@grobasoz That would be great. Most of the firmware in this repository is from the old distributed EmberZnet packages or found elsewhere on Github.

If you look here: https://github.com/walthowd/husbzb-firmware/blob/813b91b58284ebe15d7ea722b839b5a1a52f68d1/Dockerfile#L22

You can see where I originally started, downloading the publically available 6.4.1 EmberZnet release and extracting the ncp-uart-xon-xoff-use-with-serial-uart-btl-6.4.1.ebl file. That file (and other non EM357 files) in this repo all work perfectly with the HUSBZB-1.

[grobasoz]

@walthowd - Those files are for software flow control at 57k6 baud. I have them here so can test as well... Will get back to you :)

[grobasoz]

@walthowd - OK... I have tested the firmware from above (ie EM3581 version of ncp-uart-xon-xoff-use-with-serial-uart-btl-6.4.1) on my system here - ie EM3585 development board. It works fine. I have also tested the firmware I uploaded (ie NCP_USW_EM358x_678_57k6.s37) on the same development board - also works fine? I will now try using the bootloader to upload the firmware to see if that is an issue... back soon :)

[grobasoz]

@walthowd - I have added an EM3581 based NCP repository for the Long Range devices. Please could you test the firmware - as mentioned I don't have an EM3581 to test on here... If you need/want 115k2 baud, let me know. Thanks, Gary.

[sreknob]

Thanks @grobasoz for compiling this. I tried it on my HUSBZB-1 using the script as well as via XMODEM with no love.

./ncp.py flash -p /dev/ttyUSB1 -f NCP_USW_EM3581-LR_678.ebl 
Restarting NCP into Bootloader mode...
CEL stick
EM3581 Serial Bootloader v5.4.1.0 b962

Successfully restarted into bootloader mode! Starting upload of NCP image... 
ERROR:xmodem.XMODEM:send error: expected ACK; got '\x18' for block 2
ERROR:xmodem.XMODEM:send error: expected ACK; got '\x18' for block 2
ERROR:xmodem.XMODEM:send error: expected ACK; got '\x18' for block 2
ERROR:xmodem.XMODEM:send error: expected ACK; got '\r' for block 2
ERROR:xmodem.XMODEM:send error: expected ACK; got '\n' for block 2
ERROR:xmodem.XMODEM:send error: expected ACK; got 'S' for block 2
ERROR:xmodem.XMODEM:send error: expected ACK; got 'e' for block 2
ERROR:xmodem.XMODEM:send error: expected ACK; got 'r' for block 2
ERROR:xmodem.XMODEM:send error: expected ACK; got 'i' for block 2
ERROR:xmodem.XMODEM:send error: expected ACK; got 'a' for block 2
ERROR:xmodem.XMODEM:send error: expected ACK; got 'l' for block 2
ERROR:xmodem.XMODEM:send error: expected ACK; got ' ' for block 2
ERROR:xmodem.XMODEM:send error: expected ACK; got 'u' for block 2
ERROR:xmodem.XMODEM:send error: expected ACK; got 'p' for block 2
ERROR:xmodem.XMODEM:send error: expected ACK; got 'l' for block 2
ERROR:xmodem.XMODEM:send error: expected ACK; got 'o' for block 2
ERROR:xmodem.XMODEM:send error: expected ACK; got 'a' for block 2
ERROR:xmodem.XMODEM:send error: NAK received 17 times, aborting.
NCP upload failed. Please reload a correct NCP image to recover.
Rebooting NCP...

and via xmodem

Welcome to minicom 2.7.1                                                                       

OPTIONS: I18n                                                                                  
Compiled on Aug 13 2017, 15:25:34.                                                             
Port /dev/ttyUSB1, 12:47:29                                                                    
         +-----------[xmodem upload - Press CTRL-C to quit]------------+                       
Press CTR|Sending NCP_USW_EM3581-LR_678.ebl, 1181 blocks: Give your loc|                       
         |al XMODEM receive command now.                               |                       
         |Xmodem sectors/kbytes sent:   1/ 0kRetry 0: Cancelled        |                       
EM3581 Se|                                                             |                       
1. upload|Transfer incomplete                                          |                       
2. run   |                                                             |                       
3. ebl in| READY: press any key to continue...                         |                       
BL > 1   +-------------------------------------------------------------+                       
begin upload                                                                                   
CCC    

Anyone else try?

[grobasoz]

@sreknob - I am not sure what is going wrong but I have rebuilt the EM3581 firmware and updated my repository. I can't test here but have tested the EM3585 versions - they can bootload OK. It seems like there are checks when a serial bootloader is used. It would be great if you could test this version? Thanks, Gary.

[sreknob]

Thanks @grobasoz I tried again with the updated files from your repository on my HUSBZB-1 - still no go. Same results via script and xmodem as before. Maybe someone else here who is more knowledgeable is willing to try. Again, appreciate your time on this Gary!

[walthowd]

Tested as well on my HUSBZB-1/EM3581 same results as @sreknob -- seems to be something in the file that XMODEM or the receiving EM3581 does not like.

[MattWestb]

Must being something in the header that the boot loader dont like then the CRC check is being don after the complete file is revived.

Bugs in old boot loaders ?

walthowd is EM3581 Serial Bootloader v5.4.1.0 b962 Gary wot is your bootloader version ?

Workaround do the firmware in current studio in s37 format and using one older commander to converting it to EBL ??

[walthowd]

I'm using the EM3581 Serial Bootloader v5.4.1.0 b962 bootloader as well. I prefer not to flash or upgrade the bootloader as that gives easy access back into the EM3581 in the event of a bad flash.

I thought it may be something in the header as well, and started down the XMODEM path but didn't find much on a cursory examination.

Not working

/opt/husbzb-firmware$ xxd NCP_USW_EM3581-LR_678-57k6.ebl  | head
00000000: 0000 008c 0202 e350 0800 4000 f630 0ae6  .......P..@..0..
00000010: 50f3 0020 0d82 0208 9180 0208 9580 0208  P.. ............
00000020: a70a 0a01 0041 0008 0408 03ac 8067 7501  .....A.......gu.
00000030: a49a 1f60 0000 0000 0000 0000 0000 0000  ...`............
00000040: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000050: 0000 0000 ff3e b4a1 0851 ffff ffff ffff  .....>...Q......
00000060: ffff ffff 0070 0708 0000 0000 0000 0000  .....p..........
00000070: 5d3d 6fe3 eeb3 46bd ff00 0000 0000 0000  ]=o...F.........
00000080: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000090: fd03 0784 0800 4080 f0ff 0020 0000 0000  ......@.... ....

Working

/opt/husbzb-firmware$ xxd ncp-uart-sw-6.6.5.ebl  | head
00000000: 0000 008c 0202 e350 0800 4000 ad0e 44c4  .......P..@...D.
00000010: 6873 0020 2d7c 0208 f579 0208 f979 0208  hs. -|...y...y..
00000020: a70a 0a01 0041 0008 040a 03ac 5066 cc00  .....A......Pf..
00000030: 2056 1e5e 0000 0000 0000 0000 0000 0000   V.^............
00000040: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000050: 0000 0000 9474 d6ef 0850 ffff ffff ffff  .....t...P......
00000060: ffff ffff 0070 0308 0000 0000 0000 0000  .....p..........
00000070: c0aa f1f2 5e40 8465 ff00 0000 0000 0000  ....^@.e........
00000080: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000090: fd03 0784 0800 4080 f07f 0020 0000 0000  ......@.... ....

[grobasoz]

@walthowd - OK - A little more than confused at this stage... I will try using the same bootloader and see if that has any effect... Though EmberZNet Stack 5.4.1 is a little old and may be hard to come by :p At least I can run the IAR Debugger and try detect a reason for the failure... BRB :) Gary.

[grobasoz]

@walthowd - OK - Managed to get a version of EmberZNet 5.4.1 and created a bootloader for the EM3585 (modules I have here). Then ran Minicom and managed to successfully bootload the NCP firmware. Did this a few times to check.

[walthowd]

Yes, we must havesome dissimilarity or protocol difference that we are missing. The bootloader on my HUSBZB-1 will only connect at 57600 8N1 without any flow control.

Tried again uploading your firmware, tried the 115k version (sent at 57600bps) from your screenshot, same failed result:

And

root@98c1cbd19583:/tmp/silabs# ./ncp.py flash -p /dev/ttyUSB2 -f /data/NCP_USW_EM3581-LR_678-115k2.ebl 
Restarting NCP into Bootloader mode...
CEL stick
EM3581 Serial Bootloader v5.4.1.0 b962

Successfully restarted into bootloader mode! Starting upload of NCP image... 
ERROR:xmodem.XMODEM:send error: expected ACK; got '\x18' for block 2
ERROR:xmodem.XMODEM:send error: expected ACK; got '\x18' for block 2
ERROR:xmodem.XMODEM:send error: expected ACK; got '\x18' for block 2
ERROR:xmodem.XMODEM:send error: expected ACK; got '\r' for block 2
ERROR:xmodem.XMODEM:send error: expected ACK; got '\n' for block 2
ERROR:xmodem.XMODEM:send error: expected ACK; got 'S' for block 2
ERROR:xmodem.XMODEM:send error: expected ACK; got 'e' for block 2
ERROR:xmodem.XMODEM:send error: expected ACK; got 'r' for block 2
ERROR:xmodem.XMODEM:send error: expected ACK; got 'i' for block 2
ERROR:xmodem.XMODEM:send error: expected ACK; got 'a' for block 2
ERROR:xmodem.XMODEM:send error: expected ACK; got 'l' for block 2
ERROR:xmodem.XMODEM:send error: expected ACK; got ' ' for block 2
ERROR:xmodem.XMODEM:send error: expected ACK; got 'u' for block 2
ERROR:xmodem.XMODEM:send error: expected ACK; got 'p' for block 2
ERROR:xmodem.XMODEM:send error: expected ACK; got 'l' for block 2
ERROR:xmodem.XMODEM:send error: expected ACK; got 'o' for block 2
ERROR:xmodem.XMODEM:send error: expected ACK; got 'a' for block 2
ERROR:xmodem.XMODEM:send error: NAK received 17 times, aborting.
NCP upload failed. Please reload a correct NCP image to recover.
Rebooting NCP...
root@98c1cbd19583:/tmp/silabs# ./ncp.py scan
Connecting to.. /dev/ttyUSB2 57600 True False 
{"ports": [{"stackVersion": "6.6.5-204", "deviceType": "zigbee", "pid": "8A2A", "port": "/dev/ttyUSB2", "vid": "10C4"}]}

[grobasoz]

@walthowd - I have re-built the EM3581 code again using an older version of IAR compiler that should be supported by Silicon Labs as the version I use is not "officially" supported yet. If you get some time, please give it a try. I managed to program my EM3585 with the EM3581 code (only a flash size difference really) using the Simplicity Commander SWD programmer and it works fine. I can't test using the Standalone (XModem UART) Bootloader as it gets tossed out when checking the device type. Thanks, Gary.