Because of the holidays, TI E2E™ design support forum responses will be delayed from Dec. 25 through Jan. 2. Thank you for your patience.

  • State TI Thinks Resolved
  • Locked Locked
  • Replies 12 replies
  • Answers 1 answer
  • Subscribers 51 subscribers
  • Views 260 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

LP-CC2652R7: Problem displaying messages to the console from the basic_ble example

Eric Heinen
Prodigy 50 points
Part Number: LP-CC2652R7
Other Parts Discussed in Thread: SYSCONFIG

Hi,

I'm running the basic_ble example (TI RTOS 7, TI Clang) on my LL-CC2652R7 board, and encountering multiple issues trying to modify it in order to display messages in CCS on the Console tab.

First, I've tried to call printf from various places, either in the BLE code (e.g. app/Profiles/app_simple_gatt.c), or in a separate thread like I will eventually want to do in my application. In both cases, if I've already connected to the device via BLE Scanner, soon after the printf runs (and I do see the message on the console), the device disconnects with a "LINK_TERMINATED_EVENT: Peripheral role, connectionHandle = 0, reason = 8" message seen on the display driver's UART terminal.

Second, and potentially related, I've tried to get all the Display_printf messages to go to the console instead of a UART terminal via the XDS110.  So in the syscfg file, under TI DRIVERS/Display/CONFIG_Display_0, I changed "Use Hardware" to "None" and "Display Type" to "Host".  After doing so, as soon as I try to connect to the device via BLE Scanner, it immediately disconnects with a "LINK_TERMINATED_EVENT: Peripheral role, connectionHandle = 0, reason = 62" message.

Please, any help would be greatly appreciated.

Thanks,

Eric

  • 0
    TI__Expert 5150 points

    Hi Eric,

    Thank you for reaching out,

    The reason of the first disconnection 8 is a connection Timeout,

    I'm curious to see how did you implement the printf function. Did you use the Display_printf?

    The reason of the second disconnection 62 is a connection failed to be established, for this one I tried to reproduced but without success, did you change anything in the application except the display?  

    regards,

  • 0 in reply to Guillaume
    Prodigy 50 points

    For the first issue, I included stdio.h in app_simple_gatt.c and called the standard printf function, for example from the SimpleGatt_changeCB function. I'm unable to use the Display_printf function to print to the console (second issue). Even if I go to the syscfg file and add a second display (Use Hardware = None, Display Type = Host) under TI Drivers/Display, using Display_printf with that causes the disconnection 62.

    For the second issue, I changed nothing in the application except the syscfg file, as described. It successfully moves the messages from the UART terminal to the console tab, but causes the disconnection 62.

  • 0 in reply to Eric Heinen
    TI__Expert 5150 points

    So, you do not want to use the serial terminal display using UART because you want to have a completely new Display dedicated to your debug stuff? (I'm saying that as on my side I can add some display in app_simple_gatt.c without removing the default and keeping the same template. You can also remove the default display).

    You should consider to have a look at the Display example located in the drivers folder of your SDK's examples, I'm sure you'll have much more inputs.

    It seems that the display itself push the peripheral to end the connection, to know a bit more about the second issue, you need to not use the UART terminal? (Does all the display you add work properly via the serial terminal?)

    regards,

  • 0 in reply to Guillaume
    Prodigy 50 points

    I'd like for all the BLE messages to continue going to the UART terminal display as implemented, and I don't want to interfere with or overwrite anything that's there. So I want my new debug stuff to go to the Console tab, which is why I've tried using printf, or Display_printf on a new Display (Type = Host). But that doesn't appear possible without causing the device to unexpectedly disconnect. That seems to me to be a bug that you could reproduce.

  • 0 in reply to Eric Heinen
    TI__Expert 5150 points

    I understand your point, for now you'll not disturb anything by adding your debugging stuff to the UART terminal. You should consider use GPIOs or LEDs for your debugging if display is blocking you.

    regards,

  • 0 in reply to Guillaume
    TI__Expert 5150 points

    Hello Eric,

    Are you still struggling with this display issue?

    I've found more inputs tell me if it helps,  you need need two different Display TI Drivers open, and API calls for each depending on what you are looking to output. There are also TI-RTOS7 configurations to consider. You can start with gpiointerrupt like with the SLA below to get a feel for the capabilities, and then build on from there

    https://dev.ti.com/tirex/explore/node?node=A__ANhb8wLgMuaIL980opkRTQ__com.ti.SIMPLELINK_ACADEMY_CC13XX_CC26XX_SDK__AfkT0vQ__LATEST

    Hope it helps a little,

    regards,

  • 0 in reply to Guillaume
    Prodigy 50 points

    Hi Guillaume,

    When I add a second UART Display to my (basic_BLE example) syscfg file, the first one stops working. Then it seems whether I do Display_open(0, NULL), Display_open(1, NULL), Display_open(Display_Type_UART, NULL), Display_open(Display_Type_UART | 1, NULL), every Display_printf goes to the second Display. Is this still an open issue?

    CCS/CC3220SF-LAUNCHXL: Problems while using multiple UART displays - Code Composer Studio forum - Code Composer StudioTm︎ - TI E2E support forums

    Thanks,

    Eric

  • 0 in reply to Eric Heinen
    TI__Expert 5150 points

    Hi Eric,

    Did you open both display in sysconfig without any conflicts?

    What are the names of your UARTs on sysconfig?

    regards,

  • 0 in reply to Guillaume
    Prodigy 50 points

    There weren't any conflicts in the syscfg file, and none of the Display_open or Display_printf calls returned an error. The names were CONFIG_Display_0 and CONFIG_Display_1.

  • 0 in reply to Eric Heinen
    TI__Expert 5150 points

    And the value of the defines CONFIG_Display_0 and CONFIG_Display_1 are 0 and 1?

  • 0 in reply to Guillaume
    Prodigy 50 points

    Building the project doesn't seem to define those constants in ti_drivers_config.h, I think this is the same issue that I sent a link to earlier. And I don't want to have to overwrite anything in the Build/Release folder after every build, as it suggested. So I'm probably just going to write my own UART code and not use the Display driver, if it doesn't work out of the box for multiple Displays.

  • 0 in reply to Eric Heinen
    TI__Expert 5150 points

    You're right, but you can open a new UART directly in sysconfig independently from the first one (linked to the TI display), the pins are directly mentioned in sysconfig and you don't have to use the XDS 110 hardware for it.

    regards,