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

Coexistence examples: SDK UART coexistence example

Greetings...

Please help me understand why PB-GATT support is removed from SDK UART coexistence example?

The dilemma I am facing is as follows:

1. No PB-GATT for SDK UART coexistence example;

2. Mesh LPN supports only PB-GATT;

How can I solve this problem such that I can have a Mesh Network which supports LPN nodes provisioning?

Thank you!

M.

  • Hello,

    You can take a look at this site:

    https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.meshsdk.v3.2.0%2Fmd_doc_getting_started_gatt_proxy.html&cp=5_2_1_5_1

    But it may be easier to add the NUS service to any of the other examples than adding the provisioning service to the coexistence example. 

     

    Min said:
    It is beyond my ability to answer for now since I just started working  with nRF for about couple weeks. But I am sure you may figure it out from the call stack above.

     Unfortunately I can't tell what's going on from the callstack. If you .zip the project folder, that would make it easier to see.

    Best regards,

    Edvin

  • Hi Edvin,

    Thanks for the response and I agree with you. I will wait for the future Nordic Mesh release on this one...

    I was able to add uart to the server code in light_switch example under Mesh 3.2.0 + SDK 15.3.0 release.

    It received data from UART fine, however, all the printf calls go directly to SES Debug Terminal instead of an UART terminal as you can see as follows:

    <t: 0>, main.c, 439, ----- BLE Mesh Light Switch Server Demo -----
    <t: 13022>, main.c, 357, Initializing and adding models
    <t: 13025>, main.c, 252, App OnOff Model Handle: 2
    <t: 17898>, mesh_app_utils.c, 65, Device UUID (raw): C3D12D8D4134B54C8DDF96A0D164F5B8
    <t: 17901>, mesh_app_utils.c, 70, Device UUID : 8D2DD1C3-3441-4CB5-8DDF-96A0D164F5B8
    data received from uart: ttttt

    data received from uart: eeeee

    data received from uart: sssss

    data received from uart: ttttt

    .....

    I am totally lost as why this happens. Will you be able to shed some light on this?

    How do we direct printf calls to uart instead of SES debug terminal in Mesh server code?

    Thanks!

    M.

  • Hello,

    I believe I have to see your implementation to understand why this happens. Is it possible to zip the project folder and send it? That is, the folder which includes the Segger Embedded Studio (SES) project file, as well as the src folder which includes the main.c file.

  • Hi Edvin,

    I believe I found where the problem is. I have to enable the module RETARGET to make it work!

    Thanks for the help!

    M.

  • Hello,

    I wasn't able to compile your project. I had to add some include paths in order to compile, so I guess the folder structure is a bit different on your project, or you moved some files. It shouldn't really matter. 

    But when I had all the .c and .h files included, I couldn't really replicate your issue:

    It looks normal here. Can you try to unzip your project in a set of unmodified SDK for Mesh and normal SDK and see if it still behaves the same? It shouldn't print the characters three times. 

    To be sure, you can try the attached .hex file (remember to flash the softdevice as well).

    light_switch_server_nrf52840_xxAA_s140_6.1.1.hex

    If you test this, you can monitor the RTT Viewer by using JLink RTT Viewer.

    If the characters are still quadruple it means that there is something wrong with your uart terminal.

    Best regards,

    Edvin

Related