Giter Site home page Giter Site logo

ezsp-firmware's People

Contributors

adminiuga avatar florianludwig avatar walthowd avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

ezsp-firmware's Issues

EmberZNet NCP EZSP UART firmware signed with ITead key for EFR32 in Sonoff ZBBridge

FYI, Tasmota project has ITead key signed version of EmberZNet NCP application firmware for the EFR32 inside Sonoff ZBBridge:

https://github.com/arendst/Tasmota/tree/development/tools/fw_zbbridge

Procedure for use with Home Assistant's ZHA:

https://www.digiblur.com/2020/07/how-to-use-sonoff-zigbee-bridge-with.html

Alternatively can use ser2net like this:

https://www.zigbee2mqtt.io/how_tos/how_to_connect_to_a_remote_adapter.html

Problem on flash ELR023 firmware

Hello,

I try to update firmware of my Elelabs adapter.
I get this stack :

root@jeedup:/opt/elelabs/elelabs-zigbee-ezsp-utility# python3 Elelabs_EzspFwUtility.py flash -f firmware/efr32mg13p-v8-6910-57600.gbl -p /dev/ttyUSB0
2021/07/14 15:32:27 Elelabs_EzspFwUtility:   Elelabs adapter detected:
2021/07/14 15:32:27 Elelabs_EzspFwUtility:   Adapter: ELR023
2021/07/14 15:32:27 Elelabs_EzspFwUtility:   Firmware: 6.7.0-149
2021/07/14 15:32:27 Elelabs_EzspFwUtility:   EZSP v8
2021/07/14 15:32:27 Elelabs_EzspFwUtility:   Launch in bootloader mode
2021/07/14 15:32:34 Elelabs_EzspFwUtility:   EZSP adapter in bootloader mode detected:
2021/07/14 15:32:34 Elelabs_EzspFwUtility:   Gecko Bootloader v1.A.0
2021/07/14 15:32:35 Elelabs_EzspFwUtility:   Successfully restarted into X-MODEM mode! Starting upload of the new firmware... DO NOT INTERRUPT(!)
send error: expected ACK; got b'\x18' for block 1
send error: expected ACK; got b'\x18' for block 1
send error: expected ACK; got b'\x18' for block 1
send error: expected ACK; got b'\r' for block 1
send error: expected ACK; got b'\n' for block 1
send error: expected ACK; got b'S' for block 1
send error: expected ACK; got b'e' for block 1
send error: expected ACK; got b'r' for block 1
send error: expected ACK; got b'i' for block 1
send error: expected ACK; got b'a' for block 1
send error: expected ACK; got b'l' for block 1
send error: expected ACK; got b' ' for block 1
send error: expected ACK; got b'u' for block 1
send error: expected ACK; got b'p' for block 1
send error: expected ACK; got b'l' for block 1
send error: expected ACK; got b'o' for block 1
send error: expected ACK; got b'a' for block 1
send error: NAK received 17 times, aborting.

2021/07/14 15:32:42 Elelabs_EzspFwUtility:   Firmware upload failed. Please try a correct firmware image or restart in normal mode.

This is normal ? Or just my adapter don't compatible ?

Regards,

E104-BT11

Hello!

Is it possible to use E104-BT11 (MG21 with 1024Mb) with firmware from E180-Z120B?
Maybe you have Zigbee firmware ready for E104-BT11

Adding manufacture tokens in the firmware file.

If making one file with this information:

MFG_STRING                    : "IKEA of Sweden"
MFG_BOARD_NAME                : "Billy EZSP by MW"
MFG_MANUF_ID                  : 0x110C

And flashing it with:

.\commander.exe flash --tokengroup znet --tokenfile .\tokens-MW.txt -d EFR32MG1P132F256IM32
WARNING: The string for token MFG_BOARD_NAME (Billy EZSP by MW) fills all 16 bytes of the token space. The string will not be zero terminated.
Writing 2048 bytes starting at address 0x0fe00000
Comparing range 0x0FE00000 - 0x0FE007FF (2 KB)
Erasing range 0x0FE00000 - 0x0FE007FF (1 sector, 2 KB)
Programming range 0x0FE00000 - 0x0FE001FF (512 Bytes)
Programming range 0x0FE00200 - 0x0FE003FF (512 Bytes)
DONE

I is getting from belows:

Manufacturer: IKEA of Sweden
Board name: Billy EZSP by MW
EmberZNet version: 6.9.0.0 build 178

The same file can being used and adding the information to the chip user data that is not being erased then doing one flash erase but with chip erase is deleting it or writing on new or "erase" as data.

Also possible adding in one new firmware with the commands:

$ commander convert blink.s37 --tokengroup znet --tokenfile tokens.txt --device EFR32MG1P --outfile blink.hex
Converts blink.s37 to hex format, while simultaneously defining the tokens defined in tokens.txt and on the command line.

I have not testing the convert but it shall working its only having the s37 file as input and one other as out put file. Also GBL shall working.

Way not adding somthing like this in the ZHA-NG firmware: ??

MFG_STRING                    : "ZHA-NG Made"
MFG_BOARD_NAME                : "Code Master"

Tube0013 is on the way implanting it in one or other way in his devices.

Also serial number can being written but bellows is not using it for the moment but it can coming later ;-))

"Standard" EZSP GP firmware settings for EFR32MG first gen

EZSP 6.8.0.2 have adding one "NCP UART HW GP MULTIRAIL (Hardware Flow Control)" sample that shall implanting GP functionality in the NCP.

Its need 2 GP parameters in the firmware for making it possible "talking with GP devices" and also some extra commands is implanted for making it easier to doing the GP things.

For EFR32MG2X its shall not being any problem cooking firmware for but for earlier device its running out of flash and ram then trying compiling it.

I was trying doing one "Billy" by HW configuration UART0 pins and SW flow control and its resulting in:

======================================================================
======== LINKER ERROR: Not enough flash (Application space)
======================================================================

c:/ssv5/developer/toolchains/gnu_arm/7.2_2017q4/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/bin/ld.exe: 

======================================================================
======== LINKER ERROR: Not enough RAM
======================================================================

That was expected then Silabs have putting the NVM3 to unrealistic values (as in all examples in SS 3.1).

By setting:

NVM3 Library provider:
NVM3 Flash pages: 8

Green Power Stack library:
Green Power Proxy Table Size: 50
Green Power Sink Table Size: 50

I can still compiling OK (with GNU ARM tool change) and have some free space in the flash.
I have not testing the normal NCP functionality only if its was possible compiling it and all parameters is left default.

Its also possible doing on "light" firmware with only the GP setting in one EZSP 6.7.9.0 and skipping NVM3 and the GP commands and doing the commands in the host system if cant getting enough resources for normal NCP operations but i think its not one good way to going.

Before "some persons" is starting spamming different firmware with strange setting / not working i think its better that the "zigpy core" is looking for good settings for normal functions and also for GP that is working good together and can being used of all community firmware cooker and also putting working firmware (with OK settings) in the zigpy Wiki on recommended coordinator firmware.

If its possible doing on EZSPGP for EM35X devices i dont knowing and if its worse the work testing and implanting it and it can being that first gen shall not getting support if its not working OK with the normal (core) function of the NCP but i leaving it to Zigpy core devs to make decisions in those cases.

Perhaps different levels of GP:
GP1 = Reduced connectivity (first gen / EM35X) 20 GP devices.
GP2 = High connectivity (Second gen / first with extended hardware (521 or more flash) 100 GP devices.

And config parameters in ZHA with GP0 = no GP and GP1 for reduced and GP2 for full GP or testing how many GP proxy / sink table its possible allocating in the NCP ?

Tips on SWD flashing bootloader firmware on Ebyte E180-ZG120B-TB dev board (~$9) or E180-ZG120B module (~$7)?

Any tips on SWD flashing a standard Silabs bootloader FW on Ebyte E180-ZG120B-TB evaluation board and E180-ZG120B module?

Ebyte E180-ZG120B-TB evaluation board has a powerful Silicon Labs EFR32 MG1 with a 20 dBM powerful Zigbee 3.0 radio

Ebyte E180-ZG120B is a SMD (Surface Mount Device) module with the same SoC/MCU chip as on E180-ZG120B-TB evo board:

Please post any tip here and we can try to put together a step-by-step how-to guide for an easy and inexpensive way to flash it.

For reference, EByte does not appear to ship Ebyte E180-ZG120B-TB or Ebyte E180-ZG120B with any bootloader from their factory.

The newest standard bootloader for EFR32 from Silicon Labs is called "Gecko Bootloader" and older bootloader types is sometimes referred to by Silabs as "legacy bootloader" (UART DFU) and "legacy OTA bootloader" (OTA DFU). The legacy bootloader is a one stage simple bootloader that has very limited capabilities compared to Gecko Bootloader, but all have XMODEM in them for flashing the application firmware. UART DFU is able to upgrade the firmware via UART, OTA DFU is able to upgrade the firmware via Bluetooth connection. Legacy bootloaders are not supported by Silabs in newer SDK, so today the manufacturer should really add Gecko Bootloader to their project to overwrite the legacy bootloader when providing updates.

What is needed?

Hardware needed?

  • What hardware tools are needed? Suggested inexpensive debug / jtag / J-Link / probe adapters that should be compatible?

Software needed?

EByte-E180-Z120B comes with a proprietary firmware. To update it with an EZSP based firmware you have to use a SWD Flasher at least once to upload the bootloader.
When uploading the bootloader for the very 1st time, use the combined.s37 image.
How to program the bootloader is out of the scope, however how-to updates are welcome. See https://github.com/myelin/arduino-cmsis-dap and Open On-Chip Debugger

SoC specification

The module core is a EFR32MG1 SoCs (Mighty Gecko Series 1) specifically IC = EFR32MG1B232F256GM48 (EFR32MG1B 256K)

Ebyte E180-ZG120B-TB evaluation board feature a CP2102G / CP2102 (CP210x) USB to UART/serial converter chip.

Reference copied from my original post in zigpy/bellows#243

Maybe someone can test EFR32MG12 based E180-ZG120B module from Ebyte works with bellows?

Ebyte makes an inexpensive development board called "E180-ZG120B-TB" for testing E180-ZG120B

This Zigbee 3.0 capable module has some very powerful MCU and radio specifications for its price:

This development is sold by cdebyte for less than $9 US-dollar on Aliexpress or about twice on eBay:

You can also buy them on bulk from Alibaba for less:

Looks like you can remove some jumpers to disable the USB converter if want to use serial directly.

E180-ZG120B by Chengdu Ebyte (CDEYTE) has 20 dBM powerful Zigbee 3.0 radio for 2.4GHz capable based on an EFR32MG1 Series 1 MCU SoC / chip, specifically EFR32MG1B (IC = EFR32MG1B232F256GM48), from Silicon Labs EFR32 ("Mighty Gecko") family.

EFR32MG1B232F256GM48 includes a 40 MHz ARM Cortex-M4 microcontroller with 256 Flash, 32 RAM and a rich peripheral set in a QFN48 package. With 19.5 dBm maximum output power and receive sensitivity of -101 dBm (250 kbps O-QPSK DSSS). Key Specs: 19.5 Output Power Max (dBm) / 120.5 Total Link Budget (dB).

I understand this also is classified as an Ember based radios using the EZSP (EmberZNet Serial Protocol) serial protocol (UART bus) interface so could therefore be made compatible with the bellows library for zigpy if the E180-ZG120B module is flashed with the right firmware?

I guess that my follow-up question will be which exact firmware to use on the E180-ZG120B module?

Ebyte is now making two EFR32MG1B based modules called E180-ZG120A and E180-ZG120B

E180-ZG120B (and old E180-ZG120A) module is sold by cdebyte on eBay and Aliexpress at low prices.

Example:

EZSP 6.7.8.0 released with some bug fixes.

Zigbee EmberZNet SDK 6.7.8.0 GA

Fixed in release 6.7.8.0
ID # Description

  • 480336
    621122
    Fixed an issue where SPI NCP reset on wake from sleep. Per AN711 Host must toggle nWAKE prior to setting sleepMode to Idle. halNcpWakeUp() provided as reference function.
  • 494873
    An issue has been fixed where an end device would fail to rejoin its parent if the parent sent a Beacon with no end device capacity. The issue was exposed only when a previous rejoin attempt failed for another, legitimate reason. A subsequent rejoin attempt should succeed even if the parent reports no capacity in its beacons, since the end device was a previous child of the parent.
  • 635430 Fixed a corrupted message being detected as an address conflict in rare circumstances.
  • 638989 Fixed an issue in the host-ncp sleepy end device configuration, where it continued short polling if the parent connectivity was lost temporarily during data transfer.

No large things but the last can being interesting with the IKEA controlling device battery draining problems.

If you is making one new release for Elelabs modules, can I requesting one for the IKEA Billy 2 ?
I think its only needs different com pins RX PB15, TX PB14 and force bootloader pin PA0 (for compatibility with the E1743).

I think this is one of the latest bug fixing release for EZSP Protocol Version 8 for devices with 256 kB flash but perhaps 2021 is bringing one or 2 more urgent bug fixing releases (6.8.X and 6.9.X. looks being more or less uninterested for first gen geckos).

Thanks in advance.

Firmware request for EByte-E180-Z120B

Its looks like all new EZSP 6.7.8.0 firmware with SW flow control at 115200 is working well also for the EM35X family.
For making it easier for "normal" and "not so normal" users it would being better getting all EZSP adapters up and running on 115200 with SW flow control (except tuya ZBGW that Socat is doing the "converting" between from HW in the module side to SW on the ZHA side).
Its only EByte-E180-Z120B that still only having 57k6 firmware and bootloader.
I have not seen any "sign" that the hardware have problems with higher speed and SW flow control but its easy tested then have cooking on firmware for it. Also if some user is needing the 57k6 its still possible using it.
If you is cooking one 115k2 set for it all can using the same default setting in ZHA and making its easier for all users.

I have adding one working method for changing the adapter speed without deleting ZHA and installing it in the Zigpy wiki.

I also recommending changing the default speed for EZSP adapters in ZHA to 115k2 for making its working out of the box then adding the integration in HA.

All is only recommendations but i see its being better for nearly all user is making those changes.

Mvh Mattias.

And great thanks for making all work on ZHA !!

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.