Denis Akopov

Hello,

ZBOSS can be built by unpacking stack and running the following commands from the stack folder:

ln -s build-configurations/Platform-linux Platform

ln -s build-configurations/Options-linux-debug Options

make rebuild

To make sure, that stack works you can run any of tests from ./tests folder and check logs and/or .pcap files.

Please check readme.build file in the stack folder and documents from the corresponding area of ZBOSS site for the detailed instructions on running and verifying the tests.

B.R.

Denis

Hi,

Yup, CC2530 should work from the box.

As well as TI sniffer works perfectly (it can't parse some of the packets as well as all of the security, but it's the TI Sniffer's limitations)

The only thing you should care about is channel. Have you tried switching channels on your Packet Sniffer? It's in the "Radio Configuration" tab on TI PS interface.

By default ZBOSS works on a 14th channel, please check ZB_APS_DEFAULT_CHANNEL_MASK in ./include/zb_config.h to find the channel mask that ZBOSS uses for

formation and discovery procedures.

Well. Stack by default doesn't perform any actions. It's an application part that defines the behavior.

ZBOSS contains a lot of samples which implement different tests. It can be used to understand how ZBOSS works.

You have compiled one of these tests and as far as I understood, the same test role for both devices. So, the only

thing you can see with it is an initial part of active scan procedure. You can try to compile different roles (usually named like

*_zc and *zr or *zed) to see the whole procedure. I recommend you to use zdo_startup test which implements commissioning and sample data exchange.

And about GTS. GTS as you probably know is a part of IEEE 802.15.4, which is a base for the Zigbee MAC layer. But Zigbee doesn't include any time slots interactions (Because it uses only part of IEEE 802.15.4, as well as some parts are used in different way from the initial specification)

Yes, ZBOSS is a Zigbee stack, not 802.15.4, so it doesn't support GTS. Zigbee 2007/PRO is a beaconless network. So, no other BO and SO allowed.

Beacons in Zigbee are used only for sending/gathering network information during commissioning.

You can check initial and MAC section of Zigbee PICS or/and the Zigbee specification.

Hi Yves,

Yes, it's possilbe to disable both traffic dump and trace messages. But as far as I remember, we didn't test this configuration with TI Chips.

Is association passed normally with these settings?

B.R.

Denis

Does it mean that association is OK without trace/dump?

And about your questions:

1. Yes, we did it. As well as we have a dozen of different interoperability tests.

2. IAR is a great tool, so, you could check ZStack stack usage for idle stack, and if it's above 80% - the simpliest way is to increase it. Or you can try to

find the reason of such behavior by analyzing your ZStack application and ZStack settings as well. I'm not sure about latest ZStack, but previously we had to add some tuning to ZStack (but I think you've done it already, because you can join). I can provide some of these tests to you, if you're interested in interoperability with TI.

Hello John,

• Well, I don't know ready-to-use solution for forwarding ZigBee packets to the IP network, but for ZBOSS it can be easily done by using built-in traffic dump functionality. For each supported platform all inbound/outbound traffic can be saved to .dump file (with very simple binary structure) and then if needed converted to wireshark .pcap file using dump_converter utility which is provided with ZBOSS. I think for prototype you can use command-line wireshark interface to filter packets that you need to forward and all further actions is up to your application.
• Yes, ZBOSS works with CC2530 from the box.
• Unfortunately, I don't have a chance to try XBee solutions. And for the first glance these transceivers looks quite high-power-consuming for 802.15.4. Porting to the Xbee doesn't looks very complex, because work with UART and SPI transports already implemented in the ZBOSS.

B.R.

Denis

Hello,

All you need to port stack is to modify chipset startup parameters, transport and peripherals.

Absolutely most of these routines located in OSIF directory. For Jennic's chip I think it's better to use

TI CC2531 code as a template, because it's OSLess and has direct transport and similar security accelerator.

Please check CC25XX pre-processor directive. All platform dependent code located under this directive and

almost all functions should be replaced or modified.

So, briefly plan could look like this (assuming, that you already have standalone tests for peripherals):

1. Base project structure: JN5149 it's GNU toolchain samples

2. Modifying zb_config.h to add new platfrom

3. Stubs for all platform dependent functions (e.g. functions under CC25xx or any other platform definition)

4. Chip initialization routines.

5. U(S)ART to get trace system work wtih simple testing.

6. Transport functions (filling JNxxxx Frame buffer, reading from Frame Buffer, RX/TX Interrupt Declaration, channel switching, scans)

7. Basic testing without security (just disable ZB_SECURITY)

8. Software security implementation (it's already present in stack and can be used instead of hardware engine)

9. Security testing. Everything should work now.

10. Security engine related implementation. It can help to save some code-space and increase performance.

B.R.

Denis.

Hi Andy,

We also in good relationships with TI and I have a couple of CC2538 chips. Interesting and perspective solution, SE2.0 on-board looks good for some applications.

Unfortunately, TI closed almost all hardware related functions in ZStack and it's not very helpful to port ZBOSS.

I think IDE means nothing in this kind of projects, and CodeSourcery works with m3 (have some issues with linker, afair, but I don't think it will be blocking issue for you)

FreeRTOS is very simple OS. It's more like an advanced scheduler than OS, tbh. You can find tons of examples of using it with TI chips.

Currently we don't have plans to write a detailed porting guide, because, you know, it will be too different for each platform and transport. As for me, WBS will looks like following:

1. Standalone tests for 2538. You need UART, Timer and Transceiver. They should be interrupt-driven to make port easy.

2. ZBOSS has very simple build system. You can use makefile that just compiles all sources, because platform determined by directives in the zb_config.h but not by the some special directives. Just replace toolchain and add separate directive like ZB_CC2538 to zb_config.h for the platform to build all platform-dependant code. You can use CC25XX directive as an example. zb_config.h - is the key.

3. Now your path lay to the osif directory:

• For UART: zb_8051_serial.c and zb_8051_serial_init.c. Very simple and clear code.
• Timers: just add initialization procedure to zb_time_8051_init.c. It will be very similar to the existing.

4. For transceiver you should rewrite all RF-related functions in zb_cc25xx.c and zb_cc25xx_common.c (interrupt handler)

5. You can add specific initialization code to zb_sysinit.c. Or use any other low level initialization functions. As far as I know 2538 does not require specific platform initialization. All you need can be done during peripherals initialization.

6. That's all. Probably you will need to implement security engine, but probably modified 253x can be used. You can find it in zb_TI_cc25xx_secur_ccm.c.

For the basic porting you can disable ZB_SECURITY setting and ZBOSS will perfectly work w/o it.