Thread SDK hardcodes UART pins

RE: Thread SDK hardcodes UART pins

Edvin — Thu, 13 Dec 2018 08:22:50 GMT

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

RE: Thread SDK hardcodes UART pins

ozanoner — Wed, 12 Dec 2018 16:04:53 GMT

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.

RE: Thread SDK hardcodes UART pins

Edvin — Wed, 12 Dec 2018 14:37:16 GMT

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

RE: Thread SDK hardcodes UART pins

ozanoner — Wed, 12 Dec 2018 14:20:25 GMT

Is there any news about this subject? I have similar problem. Please see here: devzone.nordicsemi.com/.../merging-freertos_coap_server-and-uart-examples

RE: Thread SDK hardcodes UART pins

Edvin — Wed, 18 Jul 2018 05:52:22 GMT

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

RE: Thread SDK hardcodes UART pins

nealjack — Tue, 17 Jul 2018 02:15:44 GMT

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?

RE: Thread SDK hardcodes UART pins

nealjack — Fri, 22 Jun 2018 23:33:10 GMT

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.

RE: Thread SDK hardcodes UART pins

Edvin — Fri, 22 Jun 2018 07:46:54 GMT

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