Porting to new hardware

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 Denis

 

I read the above and tried my best to grok it but basically there's probably too much to take in right now foe me.

 

What I am looking to do is add a port for the new TI CC2538 device. It's based on the ARM Cortex-M3 rather than the 8051.

 

I have quite a bit of experience with this device already using IAR and ZStack and I already have lots of experience with the Cortex-M3 (NXP, Energy Micro and now the CC2538). However, I want to build my work on using Eclipse + GNUC via CodeSourcery toolchain and then creating a separate wrapper project using FreeRTOS.

 

Anyway, what I am basically struggling with is working out ZBOSS's transport layer. I expected it to be fairly simple case of looking for CC25XX based code and reworking it for the CC2538. However, in Eclipse+GNUC, I found is seems not so straight forward (I don't like Makefile projects that much!). If you could right a porting guide it would be pretty useful.

 

The CC2538 is new and not yet released but I do have the documentation but cannot yet give details as TI currently have it under NDA for Commercial use only. But it is being publicly released very soon so all it's information will then be in the public domain.

 

regards,

 

--Andy

 

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.

 

Dennis,

 

Thanks for your detailed answers. I have been working on this for some time but have trouble understanding some things related to your suggestions. To recap your list, with my questions:

 

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

 

No Problem

 

2. Modifying zb_config.h to add new platfrom

 

No problem (mostly - some guesses on the #defines to use, but probably doable)

 

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

 

Any advice on how to identify the functions that are platform dependent? Navigating the nested #define's is not so easy...

 

4. Chip initialization routines.

 

No problem.

 

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

 

No problem to get it working by itself, but no so easy to understand what ZBOSS needs. Can you clarify which functions are actually called from outside the osif routines?

 

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

 

This is a problem for me, as I don't really understand the role of the transport functions. How should one think about the transport functions? I am not sure the reason for these - why different versions for serial, spi, mac, etc...

 

7. Basic testing without security (just disable ZB_SECURITY)

 

TBD

 

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

 

TBD

 

9. Security testing. Everything should work now.

 

TBD

 

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

 

TBD

 

And one final question: For the NXP chips, they have a built-in MAC/PHY layer. My thought was to take advantage of the NWK and up from ZBOSS, and the PHY and MAC from the NXP libraries. Is there an obvious reason this is a bad idea?

 

Thanks again!

 

hi m baker

 

can u tel me which are the RADIO related ISRs implemented in the zboss ?

 

in which file the radio ISRs code is located ?

 

i m trying to port the zboss to msp430f2618+cc2520 combination

 

thanks in advance

 

Stubs for all platform dependent functions (e.g. functions under CC25xx or any other platform definition) Any advice on how to identify the functions that are platform dependent? Navigating the nested #define's is not so easy...

Oh, for your situation it's easy You don'y need special transport or anything else, just rewrite everything in zb_cc25xx.c and zb_cc25xx_common.c (not sure you're really need to replace absolutely everything, but I think most of functions).

 

5. U(S)ART to get trace system work wtih simple testing. No problem to get it working by itself, but no so easy to understand what ZBOSS needs. Can you clarify which functions are actually called from outside the osif routines?

zb_8051_serial_put_bytes().

 

Replace these functions with stubs, add necessary chip-related startup routines for bring up constants from flash etc (IAR contains all necessary files, that can be used as is) and try to run it. You will most likely stop in zdo_startup_complete with fail status.

 

For the NXP chips, they have a built-in MAC/PHY layer. My thought was to take advantage of the NWK and up from ZBOSS, and the PHY and MAC from the NXP libraries. Is there an obvious reason this is a bad >>idea?

As far as I remember they have no MAC layer built into the chip (as CSR for example), just some of the functions like Clear Channel Assesment, auto-ack and retransmitting. Your CC2538 also have them.

 

B.R.

 

Denis

 

Where can i download TI CC2531 code? I want to use it as a template for NXP's JN5189.

 

Thanks.