ble_thread_dyn_mtd_coap_cli_pca10056_s140 with 2 UARTES

[Andre]

Hello

I would like to use both UARTES in the exemple "ble_thread_dyn_mtd_coap_cli_pca10056_s140". 

I tried to adapt this example using the example "nRF5_SDK_for_Thread_and_Zigbee_v4.0.0_dc7186b \ examples \ peripheral \ serial_uartes" but I have link problems with libraries that are in common between my program and the SoftDevice ...

How can I fix it?

Thank you

[Jørgen Holmefjord]

Hi,

The OpenThread libraries are by default built with support for UART (for NCP and CLI). If you want to use UART0 for another purpose, you need to build the libraries without UART. These steps should work:

1. Start with a fresh copy of the SDK, and make sure you place it as close to the ROOT of the hard drive as possible.
2. Modify the file in external\openthread\project\nrf52840\openthread_nrf52840\softdevice\uart\armgcc\Makefile and comment out/remove all lines involving UART:
   1. #  $(PROJ_DIR)/../openthread/examples/platforms/nrf528xx/src/uart.c \
   2. #CFLAGS += -DOPENTHREAD_CONFIG_NCP_UART_ENABLE=1
   3. #CFLAGS += -DUART_AS_SERIAL_TRANSPORT=1
   4. #ASMFLAGS += -DOPENTHREAD_CONFIG_NCP_UART_ENABLE=1
   5. #ASMFLAGS += -DUART_AS_SERIAL_TRANSPORT=1
3. Open command line and go to [nRF5 SDK for Thread and Zigbee v4.0.0 ROOT]\external\openthread\project.
4. Enter the following commands:
   

   git clone https://github.com/openthread/openthread.git
   cd openthread
   git checkout 8a1992e2e42fb707babe9491a6a1456e553490e8
   cd ..
   make -C nrf52840\openthread_nrf52840\softdevice\uart\armgcc

5. Open the SES project. Under directory 'OpenThread' in the project browser, remove the file named 'libopenthread-nrf52840-softdevice-sdk.a'.
6. Add the file external\openthread\project\nrf52840\openthread_nrf52840\softdevice\uart\armgcc\libopenthread-nrf52840-softdevice-sdk.a to the project.
7. Remove the following preprocessor symbols in the SES project settings:
   1. CFLAGS += -DNRFX_PRS_ENABLED=0
   2. CFLAGS += -DUART0_ENABLED=0
   3. CFLAGS += -DUART1_ENABLED=1

Best regards,
Jørgen

[Jørgen Holmefjord]

The error seems to come from the file you should remove in step 5. Did you remove it and add the newly built file?

[Andre]

You are right: because the file 'libopenthread-nrf52840-softdevice-sdk.a' was not present and the file "libopenthread-nrf52840-softdevice-sdk.a" was already present, I had not deleted it. 

I replace the file and it compiles now :)

To do as in the example "examples \ peripheral \ serial_uartes", I added the files "nrf_drv_power.c" and "nrfx_power.c". But I think that there are a problem with these files. 
When I run my new project (ble_trhead_dyn_mtd_coap_cli_pca10056_s140 with my modifications for having 2 UARTES), I have this error :

I haven't problem if I "exclude from build" the files  "nrf_drv_power.c" and "nrfx_power.c" (but these files are necessary for the UARTES) and I comment my function uart_init() :

Here are my definitions:

Do you have any idea why I have this problem?

[Andre]

In fact the problem appears when the instruction "NRF_LOG_INFO (...)" is called : do you know how to fix it ?

[Jørgen Holmefjord]

Did you enable the UART backend for NRF_LOG? It looks like the error handler is called, which should not happen by calling NRF_LOG_INFO. Can you try to build the application in debug mode, and check if you get the error code and origin of the erroneous function call output on the RTT log?

If not, can you upload your project for me to debug it?

[Andre]

Hello 

NRF_LOG_BACKEND_UART_ENABLED = 0

For the test, I proceeded like this:


And when it arrives at the "if (buf_prealloc (...))" function, the answer is always "false":

This is my project:

ble_thread_dyn_mtd_coap_cli.zip

[Jørgen Holmefjord]

Hi,

This is caused by the NRF_LOG macros being called before the NRF_LOG module has been initialized. If you move log_init() to the start of main(), you should not see this issue.

The NRF_LOG macros have also been used within the app_timer2.c implementation, which causes hardfaults if it is built in debug mode (with assertions enabled) and is called before initialization of the logger module. This issue should be fixed in the next SDK release.

Best regards,
Jørgen

[Andre]

Thank you for your proposal but I'm sorry, I still have the same problem ...

I organized my functions like this now: