• State Not Answered
  • Replies 8 replies
  • Subscribers 63 subscribers
  • Views 11450 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 208609
Options
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

nealjack

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
  • 0

    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

     

Reply
  • 0

    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

     

Children
  • 0 in reply to Edvin

    Ok that sounds great thanks!

    As an example of where this can be problematic, I'm trying to build an Openthread application that uses UART1 for printf functionality, since UART0 is already used in the Openthread code that's compiled within the library. I get a linker error as follows:

    ../../make/../sdk/nrf5_sdk_15.0.0_thread/external/openthread/lib/gcc/libopenthread-nrf52840-sdk.a(libopenthread_nrf52840_sdk_a-uart.o): In function `UARTE0_UART0_IRQHandler':
/build/KNG-OL-JOB1/openthread/examples/../examples/platforms/nrf52840/uart.c:273: multiple definition of `UARTE0_UART0_IRQHandler'
_build/nrfx_prs.o:nrfx_prs.c:(.text.UARTE0_UART0_IRQHandler+0x0): first defined here
collect2: error: ld returned 1 exit status
../../make/Makefile:675: recipe for target '_build/thread_hello_world_blank.hex' failed
make: *** [_build/thread_hello_world_blank.hex] Error 1

    I am almost certain I've set up my sdk_config.h correctly. I've disabled UART0, UARTE0, and ensured nrf_drv_uart and app_uart use UART1. Here is my sdk_config.h just in case I missed a define or two and someone is willing to look it over. I'm having a very hard time tracing down where UARTE0_UART0_IRQHandler is defined within all the platform/device macros. I don't see where it would be defined in nrfx_prs.c.

  • 0 in reply to 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?

  • 0 in reply to nealjack

    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

     

  • 0 in reply to ozanoner

    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

Related