This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

zigbee init with nrf_connect_sdk

I switched to SDK. In the zigbee bulb example, the initialization function "zigbee_init" in "zb_nrf_platform.c" is started, which sets the address and role of the device. If I am correct, then for manual configuration you need to enable the "CONFIG_ZB_TEST_MODE_MAC" config. What is the correct way to do this without changing the SDK files? I enabled this option by adding "zephyr_compile_definitions(CONFIG_ZB_TEST_MODE_MAC)" to CMakeList.txt, how is it intended by the developers? I don't know much about CMake.

Parents
  • Hello,

    Do you use command line + west to compile your samples, or do you use nRF Connect for Visual Studio code?

    Either way, if you copy the sample folder to a folder outside the SDK, and then compile it from there. Then you are free to add CONFIG_ZB_TEST_MODE_MAC, or any other config for that matter, to the prj.conf file in your copied project, without having to change anything in the SDK.

    Best regards,

    Edvin

  • Hello,

    But CONFIG_ZB_TEST_MODE_MAC is not handled in Kconfig files, so if I add CONFIG_ZB_TEST_MODE_MAC=y to the prj.conf file, an error occurs. I'm using VS code.

    I can ask again like this: how to correctly set the user address and role of the zigbee device using the example code. In the example, the address and role are set in the zb_nrf_platform.c file.

  • Hello,

    Sorry, I misunderstood the question in my first reply. I thought it was just a question on how to store personalized varants of the samples. After looking into the files that you refer to, I understand the issue. 

    There are a couple of KConfigs that you can use to set the address to a custom address. 

    CONFIG_IEEE802154_NRF5_UICR_EUI64_ENABLE

    and

    CONFIG_IEEE802154_NRF5_UICR_EUI64_REG

    I tested this setting these in my prj.conf file:

    CONFIG_IEEE802154_NRF5_UICR_EUI64_ENABLE=y
    CONFIG_IEEE802154_NRF5_UICR_EUI64_REG=0

    The first one simply says that we want to get the address from our UICR registers. The second specifies the first of two consecutive registers that the address will be fetched from. 

    Setting it to 0 means it will use UICR->CUSTOMER[0] and UICR->CUSTOMER[1], while setting it to e.g. 5 means it would have use UICR->CUSTOMER[5 and 6].

    So it means that you need to populate the UICR->CUSTOMER registers in addition to your application.

    I tested this using nRF Command Line Tools:

    nrfjprog --memwr 0x10001080 --val 0x12345678
    nrfjprog --memwr 0x10001084 --val 0x9abcdef0

    And this is what I used in my main loop to check what address that was actually used:

    void main(void)
    {
        ...
        zb_ieee_addr_t ieee_addr;
        char ieee_addr_string[20];
        ...
        
        while(1) {
            ...
            zb_osif_get_ieee_eui64(ieee_addr);
            err = ieee_addr_to_str(ieee_addr_string, 20, ieee_addr);
            LOG_INF("err %d", err);
            LOG_INF("addr: %s", ieee_addr_string);
        }
    }

    Note the byte order in the acutally used address and how you enter the address using nrfjprog --memwr. 

    Best regards,

    Edvin

Reply
  • Hello,

    Sorry, I misunderstood the question in my first reply. I thought it was just a question on how to store personalized varants of the samples. After looking into the files that you refer to, I understand the issue. 

    There are a couple of KConfigs that you can use to set the address to a custom address. 

    CONFIG_IEEE802154_NRF5_UICR_EUI64_ENABLE

    and

    CONFIG_IEEE802154_NRF5_UICR_EUI64_REG

    I tested this setting these in my prj.conf file:

    CONFIG_IEEE802154_NRF5_UICR_EUI64_ENABLE=y
    CONFIG_IEEE802154_NRF5_UICR_EUI64_REG=0

    The first one simply says that we want to get the address from our UICR registers. The second specifies the first of two consecutive registers that the address will be fetched from. 

    Setting it to 0 means it will use UICR->CUSTOMER[0] and UICR->CUSTOMER[1], while setting it to e.g. 5 means it would have use UICR->CUSTOMER[5 and 6].

    So it means that you need to populate the UICR->CUSTOMER registers in addition to your application.

    I tested this using nRF Command Line Tools:

    nrfjprog --memwr 0x10001080 --val 0x12345678
    nrfjprog --memwr 0x10001084 --val 0x9abcdef0

    And this is what I used in my main loop to check what address that was actually used:

    void main(void)
    {
        ...
        zb_ieee_addr_t ieee_addr;
        char ieee_addr_string[20];
        ...
        
        while(1) {
            ...
            zb_osif_get_ieee_eui64(ieee_addr);
            err = ieee_addr_to_str(ieee_addr_string, 20, ieee_addr);
            LOG_INF("err %d", err);
            LOG_INF("addr: %s", ieee_addr_string);
        }
    }

    Note the byte order in the acutally used address and how you enter the address using nrfjprog --memwr. 

    Best regards,

    Edvin

Children
No Data
Related