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

Thread SDK hardcodes UART pins

From what I can tell, the SDK for Thread provided from Nordic uses a precompiled Openthread library that hardcodes the UART pin configuration. This means that users of this SDK must modify and recompile the library manually if they want to use the Thread SDK on their own boards with different pin configurations. The Openthread library is meant to compile as a platform independent binary, and the Nordic supplied SDK should include the specific lower layer code separately. This along with an application/board specific sdk-config.h file would allow the required flexibility.

Are there any plans to support this?

Thanks!

Parents
  • Hello,

    It looks like you are correct. Please let me check with the guys working on our OpenThread solution, and I will let you know. For all I know they are already planning to do this. "Our" OpenThread (the one used in the Thread SDK) library is still in the development stage.

     

    I will forward your feedback, and I will get back to you!

     

    Best regards,

    Edvin

     

  • Is there any update on this? I can't even get an app that uses I2C/TWI to compile with the OpenThread binary, since the SPI component already defines the 'SPIM0_SPIS0_TWIM0_TWIS0_SPI0_TWI0_IRQHandler'. While I could do without UART, I need TWI/SPI to interface with sensors on my system.

    Is there at least a workaround that will allow my compilation to override the handler defined in the library?

  • Hello,

    I have asked our Thread team. Their explanation is that the solution was built on old peripheral drivers, but the plan is to port it to the new nrfx drivers, to make it easier to configure. Unfortunately, we (both in customer support and the thread team) is quite short staffed during the summer,  due to vacation season. They will look into this as soon as they can.

     

    Regarding the SPI, they gave a short answer:

    "When it comes to the second problem with SPI, there is a simple solution. He needs to build the OpenThread library with DISABLE_SPI=1 flag.

    The instruction is here:
    http://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.thread_zigbee.v1.0.0%2Fthread_intro.html&cp=4_2_0_1_0_4&anchor=thread_qsg_libraries

    To keep full compatibility with the released SDK, customer would need to use the same OpenThread commit as it is in our release notes. 

    The full command is:

    $ make -f examples/Makefile-nrf52840 COMMISSIONER=1 JOINER=1 COAP=1 DNS_CLIENT=1 MTD_NETIAG=1 BORDER_ROUTER=1 MAC_FILTER=1 TMF_PROXY=1 DISABLE_SPI=1

    I verified using GCC."

     

    So you can try this to get the SPI working.

     

    Best regards,

    Edvin

     

Reply
  • Hello,

    I have asked our Thread team. Their explanation is that the solution was built on old peripheral drivers, but the plan is to port it to the new nrfx drivers, to make it easier to configure. Unfortunately, we (both in customer support and the thread team) is quite short staffed during the summer,  due to vacation season. They will look into this as soon as they can.

     

    Regarding the SPI, they gave a short answer:

    "When it comes to the second problem with SPI, there is a simple solution. He needs to build the OpenThread library with DISABLE_SPI=1 flag.

    The instruction is here:
    http://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.thread_zigbee.v1.0.0%2Fthread_intro.html&cp=4_2_0_1_0_4&anchor=thread_qsg_libraries

    To keep full compatibility with the released SDK, customer would need to use the same OpenThread commit as it is in our release notes. 

    The full command is:

    $ make -f examples/Makefile-nrf52840 COMMISSIONER=1 JOINER=1 COAP=1 DNS_CLIENT=1 MTD_NETIAG=1 BORDER_ROUTER=1 MAC_FILTER=1 TMF_PROXY=1 DISABLE_SPI=1

    I verified using GCC."

     

    So you can try this to get the SPI working.

     

    Best regards,

    Edvin

     

Children
  • Hello,

    The UART0 is configured in the OpenThread library. It is set up as default, with pins P0.06 and P0.08. Only UART0 is used, so you can set up and use the other instances of the UART as you like. If you want to change the UART0, however, you need to rebuild the OpenThread library.

    See the section "Building the latest OpenThread libraries" section in our Thread documentation.

    If you build the latest version of the OpenThread library, the examples from the SDK will probably not work out of the box anymore. If you build with the same version used to build the library as the SDK uses, you shouldn't need to change anything in the description.

    In the 2.0.0 version of the Thread SDK, it is mentioned in the nRF5_SDK_for_Thread_and_zigbee_2.2.0_29775ac\external\openthread\project\readme.txt what commit that is used:

    "OpenThread libraries projects are based on the following commit of OpenThread: 704511c96e0d093139e4b80ef0739ed2d701afb1"

    So if you want to change the UART0 instance used in the OpenThread library you need to modify and rebuild the OpenThread library.

    Best regards,

    Edvin

  • Thanks for the reply, Edvin! I think I changed my mind about recompiling openthread for the moment. I tried to enable UARTE1 and use it, but I got another error: "multiple definition of `UARTE0_UART0_IRQHandler'" although I disabled all UART0 and UARTE0 flags in the sdk_config.h. The reason seems "#define NRFX_PRS_BOX_4_ENABLED 1" in the sdk_config.h. when I disable it, the code compiles but I am not sure about the result, I will test it again. 

  • Hello,

    I don't know what example you started with, but I see that e.g. the light_control\light_switch has NRFX_PRS_BOX_4_ENABLED = 1, and this uses UARTE0_UART0_IRQHandler.

    However, this compiles. I am not sure exactly what the OpenThread uses UART0 for, but it is probably related to this.

    Have you added another UARTE0_UART0_IRQHandler in your project? You should probably change it to UARTE1_UART1_IRQHandler if you are trying to use UARTE1.

    BR,

    Edvin

Related