Z-stack Firmware
Adeline Lynady
This page contains links to obtain previous versions of the Z-Stack releases. For new projects, TI recommends using the newest release in order to take advantages of all improvements and new features. The latest Z-Stack release can be found at www.ti.com/z-stack.
Hi Jason, Can you confirm that after the flashing the Sonoff Dongle-P, with the latest coordinator that all is well?
And did you have to re-pair all zigbee devices? Or is the DB of devices not cleared when flashing updated firmware?
Thank you!
There are some resources on the net you can look into if you really want to attempt this, is it possible. However it has a high probability of not only trashing your network and you having to HARD RESET every device you own, but also bricking your stick as well.
I can reliably do the process without fear of a brick etc, but even when everything goes perfectly and its the exact same make and model stick, it still results in a ton of issues with the resulting network that never fully resolve without a total rebuild of everything including Z2M.
Thanks for the update Chris, and thanks for all you do for the Zwave and ZigBee bindings! I see your name all over the place related to these open source projects, thanks again for the contributions over the years!
In my mind ZigBee 3.0 is required to unify light link and home automation devices under one Controller, but I do notice the current binding supports Hue Light bulbs, how is this possible today with the Home Automation based firmware?
I am running the same firmware and it is working well, but I want to warn you that it has a problem, you cannot change the channel or panId since the firmware will revert them back to default values and you might lose your network if you set it up using different values. More details here
I've had my Monoprice Maker Ultimate for a few months and have started doing upgrades to it. My most recent change is in upgrading the firmware to a newer version of Marlin so that I can better control the thermal settings and implement a probe in the future. For now, I intend to level the bed manually.
Well the issue I'm having now is that after flashing the firmware (Marlin Firmware 1.1.9) and attempting to home, the z axis limit switch is unresponsive. X and Y work as they should. I send M119 codes to the printer in Pronterface when holding the Z switch with my finger and get that the z axis is open. I even flipped over the machine and shorted out the two pins on the board leading to the switch and I get that its still open.(It is open when not pressing the switch, the switch is not inverted. If I flash the firmware back to the original, it functions fine.
I've been digging through the Marlin files learning how it works and am wondering if there are any extra steps I have to take to designate the switches in the config file. Or if a conflicting bed leveling/probe setting may be overriding with the switch's functionality. I've been searching around but haven't seen much about this issue. Wondering if someone could point me in the right direction.
After gaining more of an understanding of how Marlin works, I decided to look through the the pins file for the motherboard I am using "pins_ULTIMAIN_2.h". Sure enough, It had a the wrong pin number for the z stop specified. After changing that number, I gained full functionality.
Koenkk, the great mastermind behind Zigbee2MQTT and the Z-Stack firmware that runs on the various Zigbee Coordinators, has released a new updated firmware for the CC2652/CC1352 series chipsets. This firmware is for both Zigbee2MQTT and Home Assistant ZHA users. The changelog is as follows:
The old saying of if isn't broke then don't fix it definitely applies here for the average Zigbee network sizes. I have a mixture of various Zigbee devices of around 50 devices and I've been running this firmware in beta for a few weeks without any issues. I'm using a CC2652P2 based Sonoff Dongle-P USB coordinator with Zigbee2MQTT. Several Home Assistant ZHA users on the Github testing thread have also reported no issues during the beta period. Give it a whirl if you want to, you can always downgrade if you think it is causing issues.
The dongle answer correctly to all the command I've so far tested, but when it comes to ZB_WRITE_CONFIGURATION (code = 0x2605) instead of answering me with 0x6605 it gives me with 0x6000 ( which consulting the Z-Stack Monitor and Test API doesn't seem to exist)
ZB_WRITE_CONFIGURATION is a Simple API command which is not supported on the SimpleLink CC13XX / CC26XX devices by default. I imagine what you are observing is an error message as the SAPI does not exist in your code, hence MT_RPC_CMD_SRSP (0x60) and MT_RPC_SYS_RES0 (0x00) as generated when MT_ProcessIncoming detects MT_RPC_ERR_SUBSYSTEM. You will need to ask Koen Kanters or contact the zigbee2mqtt discussions to determine how their firmware adds this layer to the SimpleLink device solution
Here is the out-of-box ZNP firmware used for communication with the host, however I know that the zigbee2mqtt project has made several custom functions and changed network configurations to more accurately fit their application requirements, as shown in the firmware.patch file.
After updating my UZG-01 to the latest Z-Stack firmware posted on github using the ZigStar Flasher, Zigbee is no longer about to start up on my UZG-01. I tried updating the firmware again and all I am getting is ERROR: Timeout waiting for ACK/NACK after 'Synch (0x55 0x55)' from the flashing software. As I am still able to connect to the UZG-01 web interface, I am able to check the console and see -> 55 55 show up in the log.
I have tried flashing it over HA using the ZigStar TI CC2652P7 FW Flasher add-on both via network and USB, as well as reflashing it over USB via my computer using the ZigStar Flasher on Windows. In all instances I am running into the same ERROR: Timeout waiting for ACK/NACK after 'Synch (0x55 0x55)' problem.
ZigBee is a stack of protocols intended to enable IoT devices to efforlessly form mesh networks and communicate with one another wirelessly. I've been fascinated with the ZigBee platform for a long time now, but I had always been put off by how corporate-y the technology looked like (and boy, I was right).
You can also get CC2531 boards, which have an USB interface on which a CDC device is exposed functionality identical to the CC2530 UART. These seem to be preferred by people hacking with RPi's, but I can't offer much insight on them, as I don't have any.
The issue is that you can't just connect the module to your Arduino/RPi/Serial Terminal and be on your way transmitting frames. TI documents two modes of operation for the CC253x SoC's, none of which is available out-of-the-box:
The first mode of operation is what you would do to make a ZigBee product. It is better in terms of compactness and cost-effectiveness. However, it has a big disadvantage: you have to learn the SDK and the tooling from TI, which as you will see is not a particularly attractive endeavour.
With the second mode of operation, you have what TI calls a ZigBee Network Processor (ZNP), which is a CC253x running the Z-Stack ZNP firmware, and then you write your application on whatever platform you're already familiar with and you make it talk to the ZNP through an UART. The rest of this article explains how to get started with this mode of operation. To prepare your boards, you need a piece of hardware and some software.
As with all things electronics, you can also buy cheap clones from China. For about 5 EUR shipped you can get something that is recognized by TI software as a SmartRF04EB but resembles and works like a CC-DEBUGGER. It looks like this and it usually includes the cable:
In theory, you could also use an Arduino/ATmega328P (or any other microcontroller you may like, if you got the skillz!) to program the CC253x, using a special firmware, which is what I was planning to do originally. However, the associated upload software seems to work very unreliably and after a lot of wasted hours I decided to just spend 5 EUR to get on with my life.
You also need IAR Embedded Workbench for 8051, which is paid software by IAR Systems. It probably costs a lot and I bet they wouldn't even sell it to you. Luckily, the trial version is fine, but you have to make sure to select the time-limited version, as opposed to the size-limited version. I used version 10, but any version after version 8 should work ok.
Now, the more adventurous readers have probably already found out that TI ships pre-compiled binaries of the ZNP firmware in Z-Stack 3.0.2. So why have I asked you to install IAR Embedded Workbench, when we could just have flashed those?
Very simple: the binaries provided by TI are compiled with mandatory UART flow control, which is very poorly documented, and it doesn't seem to work well with FTDI adapters (which are what I use). Furthermore, there are a couple compile flags that you may want to change, depending on which boards you have and how you plan to use them.
So, fire up IAR Embedded Workbench, activate/request a trial code as needed, and then open the ZNP firmware projects from File > Open Workspace. The project we need to recompile is located under the Z-Stack directory, at \Projects\zstack\ZNP\CC253x\znp.eww. After loading the project, go to Project > Edit Configurations and select the "ZNP-with-SBL" configuration.
This flag is apparently not documented anywhere. It enables what is referred in the official documentation as the "Alternate pinout configuration", and it also disables hardware flow control. You can see it disabling flow control in the znp_app.c source file (under App). I have no idea on how it manages to change the pinout, and an SDK-wide grep didn't help at all.
Since you will be using the module with an external MCU, you should also remove the POWER_SAVING flag from the project options, otherwise in some cases the device will go to sleep immediately after commissioning, rendering the UART interface unusable. To do that, right click on the solution name in the Workspace explorer (as shown below), and select Options > C/C++ compiler. Then open the Preprocessor tab, and remove POWER_SAVING from the Defined symbols list.
e59dfda104