Z-Stack 3 on CC2652R/CC1352P adventures

Koenkk commented 5 years ago

NOTE 2020-12-11 locked, please continue here: https://github.com/Koenkk/zigbee2mqtt/discussions/5266

Texas Instruments has recently released a new high performance Zigbee chip: the CC2652R. This chip is much faster and contains much more memory than the CC2530/CC2531.

This issue is created in order to gather feedback of users using the CC2652R AND Z-Stack 3.0 (= Zigbee 3.0)

Notes

The device can be bought here: http://www.ti.com/tool/launchxl-cc26x2r1
No additional flashing hardware is needed, it has an on-board programmer (no CC debugger needed).
The board has +- the size of a Raspberry Pi
Zigbee 3.0!
Flash using Flash Programmer v2
Firmware can be found here in the bin folder: https://github.com/Koenkk/Z-Stack-firmware/tree/master/coordinator/Z-Stack_3.x.0
It's not possible to migrate your Zigbee 1.2 network (requires repairing)
The network restore trick that we used in Zigbee 1.2 doesn't work anymore (due to better security policies). A backup of the CC2652R is taken at every shutdown of zigbee2mqtt, file can be found under data/coordinator_backup.json. This backup is automatically restored when starting with a new flashed CC2652R.
Requires latest zigbee2mqtt dev branch.

dzungpv commented 5 years ago

@kirovilya cc2630 does nor have enough memory to run Z-stack 3.0. @Koenkk CC2652R chip use in the board is a beta version, it may error from silicon itself, so we must waiting TI release production version of the chip (they say end of this month)

revnelson commented 5 years ago

I'd love to throw my hand in the mix and try this out with you guys. I've ordered a CC1352R today from taobao and it should arrive Sunday. Unfortunately they were out of the CC26x2 units. Regarding the CC1352, are the only differences the addition of sub-Ghz RF compatibility and antenna? Will Koenkk's firmware patches be applicable? In the pin out diagram they look identical aside from 2 less GPIO on the CC1352 that have presumably gone to the RF receiver. I've found only one place saying all the stacks can be run concurrently, so I don't know if this is truly the case. I know this is zigbee2mqtt, but it would be amazing if we could use this new board with Koenkk's firmware changes and zigbee2mqtt to get data from various BTLE, RF, and zigbee devices/sensors. Hopefully this is as trivial as zigbee2mqtt seeing entities paired with the CC2652/CC1352 device and generating MQTT from that regardless of what protocol they used to connect to the CC** chip, but I am admittedly well in over my knowledge-level here.

Edit: in CCStudio's znp_CC1352R1_LAUNCHXL_tirtos_ccs example project, I was able to apply @Koenkk's firmware.patch using git apply --ignore-space-change --ignore-whitespace firmware.patch and successfully build. As I haven't received the unit yet I cannot test flashing it, but I'll report back as soon as I can.

fredrikgk commented 5 years ago

@dzungpv The CC2652R was released to market on March 28th. The engineering release of the IC was discontinued in January.

fredrikgk commented 5 years ago

@RevNelson CC2652R and CC1352R are not binary compatible, SW must be compiled specifically for eachvdevice. Application code can be transferred as-is between the two projects, so without looking in detail in the SW myself I would think what you are doing will work.

If you are buying kits from any others than TI, make sure you are actually receiving the latest HW revision and not a kit containing engineering IC rev.

dzungpv commented 5 years ago

@dzungpv The CC2652R was released to market on March 28th. The engineering release of the IC was discontinued in January.

They are not public any information about release date or any press release article, i read before some one said late 1Q2019 or 2Q2019, but from the website the LAUNCHXL-CC26x2R1 use revision E of the chip, mean RTM /pre-prodution version but not production http://www.ti.com/tool/LAUNCHXL-CC26x2R1

revnelson commented 5 years ago

@fredrikgk I understand that CC2652 firmware will not work on the CC1352, but is it not correct to say that CC1352 is a superset of CC2652? That is, it can to everything the CC2652 can do in addition to sub-Ghz RF support? I did find more resources directly from TI stating the CC1352's ability to concurrently run stacks for different protocols using what they call a DMM. From TI's site: Above the radio layer and driver is the heart of TI's multi-protocol offering, the DMM. The DMM contains the scheduler that transparently marshals radio core packets between the multiple stacks running on the device using a priority table. See more here.

If it truly can function essentially as a CC2652+, and their prices being exactly the same, should we not focus more on that? Again, I'm working on the (quite possibly wrong) assumption that if the chip receives from all those protocols and zigbee2mqtt is reading the output of the chip, then suddenly zigbee2mqtt becomes zigbee/rf/ble2mqtt. Okay, not suddenly, the firmware would need to be tweaked to add DMM support and an appropriate priority table, which I know isn't even a concern now.

~~I guess I'm just not seeing a good reason to use the CC2652 over the CC1352.~~ Here are some highlights unique to each:

CC1352

Sub Ghz RF support
SMA Connector
Current support for simultaneously running BLE & sub-ghz RF stacks (but without zigbee, so irrelevant to this project)
Future support for adding zigbee stack to the concurrent stack abilities (TI rep stated development is ongoing but declined to give a timeline)

CC2652

Smaller form-factor
Future support for concurrently running the zigbee stack with the BLE stack (TI rep stated development is ongoing but declined to give a timeline)

@Koenkk, if I'm at all on a good train of thought, I'd be happy to buy you a CC1352. Let me know!

fredrikgk commented 5 years ago

@dzungpv revision E is the production version of the device. Prior to RTM the devices were still x-marked, but after RTM the pre-release marking is removed. As you can see on the product page, the device is listed as active: http://www.ti.com/product/CC2652R

Koenkk commented 5 years ago

@RevNelson I think the firmware you compiled with the applied patch should work for the CC1352P.

lolorc commented 5 years ago

will be interesting to see if cc1352p crashes as often as cc2652r. on my side, I'm using https://github.com/mvp/uhubctl and running a cron to reset cc2652r every 6 hours :)

fredrikgk commented 5 years ago

@RevNelson You are right that the CC1352R is a superset of the CC2652R also enabling sub-1 GHz connectivity.

The Dynamic Multi-protocol Manager (DMM) allows multiple radio stacks to run concurrently and schedule radio events based on protocol requirements and priority. For more information about DMM you can see here: http://dev.ti.com/tirex/explore/node?node=ADAE6by4hb0euPuHN66mKQ__pTTHBmu__LATEST

With DMM you could potentially make a Zigbee+BLE2mqtt solution, although this would require a significantly larger effort relative to the current zigbee2mqtt-SW which is based on the Zigbee 3.0 network processor example.

There is currently an example available for Zigbee Router + BLE, Zigbee Coordinator + BLE is work in progress. Keep in mind that there are trade-offs by running Zigbee Coordinator with DMM, as you basically lose radio time to the other protocol where the router would normally be in Rx.

It is true that the price for the development kits are the same, but for ICs only, the price is higher for CC1352R as this has more features. In this project context it may make sense to use the CC1352R LaunchPad due to the SMA connector (although the on-board PCB antenna is also very good).

revnelson commented 5 years ago

@fredrikgk Thank you for all the info!

Alright I got my board and it indeed is an older board (Chinese vendor on Taobao...). It doesn't even have a revision number (see picture). I compiled as listed above, but I'm not sure if there's an issue with the SDK verion because of the older silicon or what, but I can't start zigbee2mqtt.

I'm running a docker container on a Synology NAS with root privileges (to see the /dev/ folder) and the docker image is from the latest-dev branch. If I SSH into the NAS, I can see a /dev/ttyACM0 and a /dev/ttyACM1 device. I have tried both in the configuration.yaml file and with both I get the info: Error while starting zigbee-shepherd, attempting to fix... (takes 60 seconds) (Error: request timeout) error. I know there are a lot of moving parts to this issue (not even the target device of this thread, not even the final version of the silicon) but if anybody has any pointers for something else to try I'd really appreciate it. I'll be heading home to the States next month and I'll be sure to pick up a current CC1352 and CC2652 while I'm there.

I'm also attaching a screenshot of my Flash Programmer utility in case someone might spot something I did wrong there.

Koenkk commented 5 years ago

@revnelson are you running the latest dev branch?

revnelson commented 5 years ago

@RevNelson are you running the latest dev branch?

Yes

fredrikgk commented 5 years ago

@RevNelson That is indeed an older IC revision. As you can see from Flash Programmer 2, it says Chip revision C. The release version is revision E. As for the IC marking, rev number on the package was introduced right before the transition to rev. E. If there is no marking on the IC, it is definitely rev. C.

SW is not binary compatible between rev. C and rev. E. If you debug you will see that it is hanging in a ROM init function which checks the IC revision. One option is to revert to SDK 2.30, but I would rather recommend getting a new LaunchPad.

You should also notify the seller on Taobao that they should stop selling old kits.

lolorc commented 5 years ago

following ti forum, next week if it's still needed/useful I'll try to provide air dump + serial dump with cc2652r/z2m and quite a bunch of devices. I've tried something this week, instead of restarting cc2652R+z2m every 7h, I've tried to only restart z2m every 4h, but it the end the coordinator crashed.

matlab22 commented 4 years ago

There is also a CC1352P with a 19.5dBm PA. Will this firmware also work on this chip (Despite the sub1GHz extra)? Or should I wait for a "CC2652P"? BTW 433MHz2MQTT would also be a great thing ;)

antst commented 4 years ago

Use module with cc2538+cc2592. Same 19.5 dBm and with stable working firmware.

matlab22 commented 4 years ago

Use module with cc2538+cc2592. Same 19.5 dBm and with stable working firmware.

Do you mean this JISDA CC2538 CC2592 PA Zigbee Wireless Module is working with the same firmware as CC2652R?

fredrikgk commented 4 years ago

There is also a CC1352P with a 19.5dBm PA. Will this firmware also work on this chip

It will, as the CC1352P supports 20 dBm for both sub-1 GHz frequencies and 2.4 GHz. The FW must be built specifically for this device though.

Zigbee Network Processor FW for CC1352P can be found here: http://dev.ti.com/tirex/explore/node?node=AGiY4QNdVlO.8dZm4a4gYw__pTTHBmu__LATEST

matlab22 commented 4 years ago

@Koenkk does your cordinator or router firmware support the CC2538+CC2592?

antst commented 4 years ago

@Koenkk does your cordinator or router firmware support the CC2538+CC2592?

Look for details there https://github.com/Koenkk/zigbee2mqtt/issues/1568

indubwestep commented 4 years ago

Hello, I am getting the following issue. Would anyone have some insight?

Error: Cannot find module 'zcl-id'

at Function.Module._resolveFilename (internal/modules/cjs/loader.js:581:15)

at Function.Module._load (internal/modules/cjs/loader.js:507:25)

at Module.require (internal/modules/cjs/loader.js:637:17)

at require (internal/modules/cjs/helpers.js:22:18)

at Object. (/app/node_modules/zigbee-shepherd-converters/converters/toZigbee.js:5:15)

at Module._compile (internal/modules/cjs/loader.js:689:30)

at Object.Module._extensions..js (internal/modules/cjs/loader.js:700:10)

at Module.load (internal/modules/cjs/loader.js:599:32)

at tryModuleLoad (internal/modules/cjs/loader.js:538:12)

at Function.Module._load (internal/modules/cjs/loader.js:530:3)

npm ERR! code ELIFECYCLE

npm ERR! errno 1

npm ERR! zigbee2mqtt@1.4.0 start: node index.js

npm ERR! Exit status 1

npm ERR! Failed at the zigbee2mqtt@1.4.0 start script.

npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:

npm ERR! /root/.npm/_logs/2019-07-08T21_36_12_432Z-debug.log

brtwrs commented 4 years ago

Anyone got this stable? Or any other chip that can handle al 60+ devices network? :)

Koenkk commented 4 years ago

I'm still having stability issues which I'm investigating.

fnxpt commented 4 years ago

@Koenkk any update on this?

Koenkk commented 4 years ago

@fnxpt I'm still investigating the stability issues

Koenkk commented 4 years ago

Update of my investigation: https://e2e.ti.com/support/wireless-connectivity/zigbee-and-thread/f/158/t/834603

fnxpt commented 4 years ago

@Koenkk looks like the log is broken, Im getting a 404 - looks like the link has an extra ',' (without the comma it works)

Koenkk commented 4 years ago

@fnxpt thanks fixed

lolorc commented 4 years ago

hmmm, I've been reading TI's forum, is it a good news ? :-)

Koenkk commented 4 years ago

@lolorc I assume you read about the patch, I'm currently testing this in combination with z2m, if it runs for 7 days + with my test setup I assume it's stable. Currently at 1 day, will keep you up-to-date.

fnxpt commented 4 years ago

@Koenkk, looks good cam you also share a patched firmware, maybe we can also check if it works

Koenkk commented 4 years ago

https://drive.google.com/open?id=1htqBTOJxa4jmJFS3tINPq8G7lT4NZfr0

fnxpt commented 4 years ago

So far is working good, I'm also using it with zigbee-herdsman and it looks pretty fast. I found a few errors, but probably I need to pair the devices again. I will let you know if I find any issues after doing this

Koenkk commented 4 years ago

I'm gaining more and more confidence that this is it. Which would mean that we can probably also add support for the CC1352P easily.

I will let my test setup run for a few more days, after that the last thing we need to do is to increase the routing tables (to take full advantage of the powerful CC2652R hardware).

XRyu commented 4 years ago

for testing purposes i would love to upgrade to cc2652 too. i have seen the second iteration of this board https://www.ti.com/tool/LP-CC2652RB . will your CC2652R1-firmware be compatible with these too?

I am thinking about ordering CC2652R1 or CC26452RB :)

Which of the Boards/Chips is the best one for future? CC2652R1 or CC26452RB or CC1352P?

fredrikgk commented 4 years ago

This is great new @Koenkk , I am looking forward to moving over to the CC2652R myself!

@XRyu , the only difference between CC2652R and CC2652RB is the internal oscillator in the latter device. SW is not binary compatible between the two, due to the underlying differences in the clocking scheme. You should easily be able to compile the Zigbee FW for the RB though.

Koenkk commented 4 years ago

@XRyu I won't recommend that board it's for preproduction and my firmware won't be compatible with it (probably). It is also very likely that a few revisions of this board will be released. AFAIK CC2652R1 and CC1352P shouldn't matter in terms of chips; the CC1352P is technically superior as it can also communicate on sub 1-ghz (useless for zigbee2mqtt) and should have a better antenna but has a higher price tag.

I think the CC2652R1 provides the "best bang for buck" (but I haven't done a good comparison with the CC1352P). @fredrikgk what do you think (in terms of the zigbee2mqtt use-case)?

Please note that this LaunchPad™ development kit currently uses preproduction XCC2652RBRGZR silicon and is intended for evaluation use only. Software compatibility with production version is not guaranteed.

dzungpv commented 4 years ago

@fredrikgk better buy CC1352P it has builtin PA chip with 20bB TX, difference with CC2652R1 is 5db-20db.

XRyu commented 4 years ago

Thanks for the immedeate feedback guys :D Now i am definitely ordering the CC1352P :D Can't wait for the first tests and upgrading my z2m-network from CC2531 to CC1352P in the future :D

matlab22 commented 4 years ago

@Koenkk I have a TI Evalboard with CC1352P1, please let me know if there is something to test

lolorc commented 4 years ago

looks like the fix is also working here, haven't had to restart z2m+cc2652r, it's still ok after 48h. ACE !

fredrikgk commented 4 years ago

I won't recommend that board it's for preproduction and my firmware won't be compatible with it (probably). It is also very likely that a few revisions of this board will be released.

The CC2652RB will release in not too long, and there will not be any major updates to the IC or the development board. For the sake of usage with this project though, there is no point in using the CC2652RB. The main benefit with this device is that it does not need a 48 MHz crystal, so if you are planning to build millions of products with the IC, you will save cost. The biggest issue from our point of view is that there is no 802.15.4 SW available for the RB yet.

So, in other words, go with the regular CC2652R device.

AFAIK CC2652R1 and CC1352P shouldn't matter in terms of chips; the CC1352P is technically superior as it can also communicate on sub 1-ghz (useless for zigbee2mqtt) and should have a better antenna but has a higher price tag.

The on-board antenna on the development board is actually slightly better on the CC26x2R LaunchPad for 2.4 GHz frequencies. The CC1352P board on the other hand has an SMA connector which allows you to more easily attach external antenna if you would like to that. It does require soldering 1 0402 component though.

better buy CC1352P it has builtin PA chip with 20bB TX, difference with CC2652R1 is 5db-20db.

If you choose to buy the CC1352P, make sure you buy the development board version which supports 2.4 GHz for the 20 dBm output (LAUNCHXL-CC1352P-2).

Also keep in mind, strictly speaking, you are not allowed to transmit 802.15.4 data packets at 20 dBm output power in Europe. Not that anyone will ever catch you running one single device...

XRyu commented 4 years ago

Thank you for the detailed informations @fredrikgk :) I ordered the CC1352P-2 with the 20 dBm PA :D

Koenkk commented 4 years ago

Good news!

TI fixed the instability issue of the CC2652R that we experienced.
They also fixed another issue which stopped is from increasing the device tables

Both fixes will be released in their next release of Z-Stack (https://e2e.ti.com/support/wireless-connectivity/zigbee-and-thread/f/158/p/834603/3104538#3104538). After that I will test on more time and write proper documentation for it to be used with zigbee2mqtt.

papanirual commented 4 years ago

Hi Koen,

that sounds great! I am looking forward to it!

Thank you very much for all your effort!

Koen Kanters schrieb am 16.09.2019 um 21:20:

Good news!

TI fixed the instability issue of the CC2652R that we experienced.

They also fixed another issue which stopped is from increasing the device tables

Both fixes will be released in their next release of Z-Stack (https://e2e.ti.com/support/wireless-connectivity/zigbee-and-thread/f/158/p/834603/3104538#3104538). After that I will test on more time and write proper documentation for it to be used with zigbee2mqtt.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/Koenkk/zigbee2mqtt/issues/1429?email_source=notifications&email_token=ALFQYXJQNGYQKDQSPPFFEKDQJ7L7BA5CNFSM4HF2SSS2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD62HHIY#issuecomment-531919779, or mute the thread https://github.com/notifications/unsubscribe-auth/ALFQYXJMBDWP5TWMF44DSFTQJ7L7BANCNFSM4HF2SSSQ.

fredrikgk commented 4 years ago

@Koenkk are you running default ZNP, or are any changes needed (bug fixing aside)?

Koenkk commented 4 years ago

@fredrikgk defaut + path from https://e2e.ti.com/support/wireless-connectivity/zigbee-and-thread/f/158/p/834603/3104538#3104538. However I will wait for the z-stack Q3 release before adding full support for the CC2652R in zigbee2mqtt (as this will also fix the NVOCTP bug). An initial patch can be found here: https://github.com/Koenkk/Z-Stack-firmware/blob/master/coordinator/Z-Stack_3.x.0/firmware.patch

For others: Just to get a feeling, this is a small comparison between Z-Stack 3 on CC2652R vs Z-Stack 1.2 on CC2531

direct children: 50 vs 20 routes: 100 vs 40 source routes: 200 vs 40

Note that also performance wise the CC2652R is much faster (8051 vs arm cortex m4f)

juanjux commented 4 years ago

Source routes would be the routes applying to the routing firmware?

Koenkk commented 4 years ago

@juanjux yes

Koenkk / zigbee2mqtt

Z-Stack 3 on CC2652R/CC1352P adventures #1429