This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Building Zigbee cli example 4.0

For a customer I am developing a Zigbee coordinator / Gateway with the nRF52840. As hardware I am using the nRF52840 Preview Development Kit. As software basis I use the “Zigbee cli example”. I started with the Thread and Zigbee SDK v3.2.0.  Since I had some problems here I wanted to switch to v4.0 and see if the problems are solved in the new version. Building the project, I ran into a problem:

Compiling the “cli” example stops with error message:

Compiling file: zb_nrf52_transceiver.c

In file included from ../../../../../../../../external/nRF-IEEE-802.15.4-radio-driver/src/fem/nrf_fem_protocol_api.h:49,

from ../../../../../../../../external/nRF-IEEE-802.15.4-radio-driver/src/nrf_802154.h:49,from ../../../../../../../../external/zboss/osif/zb_nrf52_transceiver.c:51:

../../../../../../../../external/nRF-IEEE-802.15.4-radio-driver/src/fem/nrf_fem_control_config.h:35:10: fatal error: nrf_fem_config.h: No such file or directory

#include "nrf_fem_config.h"

compilation terminated.

make: *** [../../../../../../../../components/toolchain/gcc/Makefile.common:272: _build/nrf52840_xxaa/zb_nrf52_transceiver.c.o] Error 1

Is there a reason why the file "nrf_fem_config.h" is missing? What should I do to fix the problem?

Parents
  • Hello,

    First, check that the file is actually located in SDK\external\nRF-IEEE-802.15.4-radio-driver\src\fem\none\nrf_fem_config.h. If it isn't there, try placing it there. (unzip a new SDK to get the file)

    If it is already a file called nrf_fem_config.h, then I suspect that the path to this file is too long. Try to move the entire SDK closer to your C-drive, e.g.:

    C:\Nordic\SDKs\SDK4

    If SDK4 is your Thred and Zigbee SDK v4.0.0, then the paths in the SDK should be short enough for the compilers to find all the files within the SDK.

    Try this, and let me know if it still doesn't work.

    Best regards,

    Edvin

  • Hello Edvin.

    Thanks for quick response. The file “SDK\external\nRF-IEEE-802.15.4-radio-driver\src\fem\none\nrf_fem_config.h” is present in the folder. Moving the SDK closer to the C-drive made no difference. After that I checked out a completely new SDK v4 and tried to build it. It worked. I also found the difference:

    In the makefile the link to the Include folder “ $(SDK_ROOT)/external/nRF-IEEE-802.15.4-radio-driver/src/fem/three_pin_gpio \” was missing. I really don’t know why.

    After fixing this building the project worked.

    But: When I start the cli program, the application stops reacting after I start the coordinator with “bdb start”

    > bdb role zc

    Coordinator set

    Done

    > bdb start

    Started coordinator

    Done

    Do you have an Idea, what can cause this?

    Best regards,

    Lutz

  • Ok, the Eclipse part is working fine. I got everything up and running in Eclipse. Development with the SDK v3.2 also worked fine here. So, no help needed for that Part.  

    Yes, it does also happen if I just compile with the armgcc compiler. After compiling I flashed the device with the J-Link Commander using similar commands to erase and program it. If you think it makes any difference I can also try to flash with the nRF Command Line Tools.

    Next step for me will be the part with the RTT Viewer.

    I only want to point out that I was working with the SDK v3.2 for the last 6 month and never had in issue like that. Are there any changes between the SDKs that could lead to something like my problem?

  • So, here is the RTT Viewer output of the CLI commands (bdb role zc; bdb start). I am not sure what to make out of if.

    00> <info> zboss:  DE AD 0A 02 1B 00 00 00|........

    00>

    00> <info> zboss:  77 00 6C 01 DE AD 26 02|w.l...&.

    00>

    00> <info> zboss:  1B 00 01 00 77 00 72 01|....w.r.

    00>

    00> <info> zboss:  BC 0C 00 00 C4 00 00 00|........

    00>

    00> <info> zboss:  10 00 00 00 E8 02 00 00|........

    00>

    00> <info> zboss:  50 02 00 00 98 01 00 00|P.......

    00>

    00> <info> zboss:  28 02 00 00 DE AD 0E 02|(.......

    00>

    00> <info> zboss:  1B 00 02 00 77 00 73 01|....w.s.

    00>

    00> <info> zboss:  01 00 00 00 DE AD 0A 02|........

    00>

    00> <info> zboss:  21 1B 0C 00 2B 08 18 01|!...+...

    00>

    00> <info> zboss:  DE AD 0A 02 21 1B 0D 00|....!...

    00>

    00> <info> zboss:  2B 08 6E 02 DE AD 1E 02|+.n.....

    00>

    00> <info> zboss:  21 1B 0E 00 A7 F8 13 01|!.......

    00>

    00> <info> zboss:  00 00 00 00 00 00 00 00|........

    00>

    00> <info> zboss:  00 00 00 00 00 00 00 00|........

    00>

    00> <info> app: Production configuration is not present or invalid (status: -1)

    00>

    00> <info> zboss:  00 00 00 00 DE AD 0E 02|........

    00>

    00> <info> zboss:  21 1B 0F 00 2B 08 06 08|!...+...

    00>

    00> <info> zboss:  01 00 00 00 DE AD 1E 02|........

    00>

    00> <info> zboss:  21 1B 10 00 A7 F8 13 01|!.......

    00>

    00> <info> zboss:  35 00 7D 00 DE AD 12 02|5.}.....

    00>

    00> <info> zboss:  22 1B 19 00 60 08 5F 00|"...`._.

    00>

    00> <info> zboss:  26 01 00 00 23 07 00 00|&...#...

    00>

    00> <info> zboss:  DE AD 0E 02 21 1B 18 00|....!...

    00>

    00> <info> zboss:  7A 6E 7D 01 04 00 00 00|zn}.....

    00>

  • That is odd, because when I flash the example, the log that shows from my CLI example is:

     0> <info> app: Production configuration is not present or invalid (status: -1)
     0> <info> app: Zigbee stack initialized
     0> <info> app: Device started for the first time
     0> <info> app: Start network formation
     0> <info> app: Network formed successfully, start network steering (Extended PAN ID: f4ce363a240ce3f6, PAN ID: 0x0866)
     0> <info> app: Joined network successfully (Extended PAN ID: f4ce363a240ce3f6, PAN ID: 0x0866)

    The Zboss logging is a feature that is a possible feature, but it shouldn't be turned on by default. 

    What was your ZIGBEE_TRACE_LEVEL and ZIGBEE_TRACE_MASK set to?

    The fact that these were changes makes me suspect that the SDK you were using isn't clean. Try downloading it from nordicsemi.com (link here).

    What IDE do you use? Did you try the armgcc compiler? Without Eclipse? Just run the make command from a cmd terminal when you have a clean SDK.

  • Sorry my fault. I already tried to get some output on the console. ZIGBEE_TRACE_LEVEL was 4

    and ZIGBEE_TRACE_MASK was 0.

     

    Now I have clean SDK.

     

    I ran the make command from a terminal to build the CLI example and flashed the firmware manually (with J-Link Commander) without my Eclipse IDE.

    The output in RTT Viewer now looks like this:

     

    00> <info> app: Production configuration is not present or invalid (status: -1)

    00>

    00> <info> app: Zigbee stack initialized

    00>

    00> <info> app: Device started for the first time

    00>

    00> <info> app: Start network formation

    00>

     

    The result is still the same: It isn’t possible to write to the CLI window after “bdb start”

  • Hello,

    I discussed this with one of my colleagues, which had a PDK on his desk. He got the same behavior as you do, but on the nRF52840 DK (not preview DK), the issue is not present. He also pointed out that the release notes of the Thread and Zigbee SDK, it says that:

    "

    Supported boards:
    - PCA10056 (from version 1.0.0)
    - PCA10056e
    - PCA10059
    - PCA10068
    - PCA10100
    - PCA10112

    "

    So unfortunately, you need to get hold of a non-preview version of the DK. I don't know the exact reason, but the PDK contains engineering samples, so there are HW changes on the nRF52840 chip between the PDKs and the DKs.

Reply
  • Hello,

    I discussed this with one of my colleagues, which had a PDK on his desk. He got the same behavior as you do, but on the nRF52840 DK (not preview DK), the issue is not present. He also pointed out that the release notes of the Thread and Zigbee SDK, it says that:

    "

    Supported boards:
    - PCA10056 (from version 1.0.0)
    - PCA10056e
    - PCA10059
    - PCA10068
    - PCA10100
    - PCA10112

    "

    So unfortunately, you need to get hold of a non-preview version of the DK. I don't know the exact reason, but the PDK contains engineering samples, so there are HW changes on the nRF52840 chip between the PDKs and the DKs.

Children
Related