Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Ble_nus characters not sent to emStudio Terminal using ble_app_uart_c

I am using SDK v15.3 and modifying the ble_app_uart_c example to setup ble_nus connection between nRF DK board and a custom peripheral.  I can use nRF Connect to send and receive various length hex strings to/from the peripheral device.  When using ble_app_uart_c and nRF DK I can see the uart transmit buffer created in main.c has the correct information in it but the peripheral device doesn't respond to the data.  How do I find out if the buffer is actually being sent?  I traced through the ble_nus_c_string_send() function in main.c and it seems to be working.

Also, I do not get any hex characters displayed on the terminal emulator from the peripheral device. The peripheral device sends a hex string every 3 seconds. 

Parents Reply Children
  • I am using the Segger emTerminal to enter information that I want sent over the BLE NUS service to the peripheral device.  I am using the Segger RTT debug messaging to do a HexDump of the UART transmit buffer.  This buffer contains the ASCII character representation of the hex characters that I am trying to send to the peripheral device as hex.  I will try RealTerm to see if it transmits raw hex values.  However, I would like to find a function in your source that does convert ASCII characters to hex.  When I try to do this, the uart_event_handle() routine in main.c of the ble_app_uart_c example, to my surprise, it causes the routine to be called with every character I type as opposed to actually waiting for the buffer to be filled before calling the routine. I added my code under the first case statement: case APP_UART_DATA_READY: UNUSED_VARIABLE(app_uart_get(&data_array[index])); and the case statement is triggered with every character entered in the emTerminal.  I need the buffer to be full in order to convert the characters from the ASCII representation to raw hex.  

    If you can direct me as to how and where I can intercept the ASCII characters so I can convert them to hex in the transmit buffer, I would appreciate it.

  • I tried using RealTerm to send hex strings to the peripheral device using the BLE NUS service.  When I send the string using RealTerm by pressing the "Send ASCII" button, I see the UART buffer filled with the ASCII equivalent of my hex string - exactly what you'd expect.  But when I try to send the raw hex string using various combinations of hex representations such as 0xFF, 0xffff, FFFF, FF, FF FF FF, etc. the hex values never show up in the UART buffer found in function void uart_event_handle(app_uart_evt_t * p_event). 

    I have to believe that RealTerm is actually sending the hex string (sense it sends the ASCII string OK) but the example code must be parsing the console input for printable (ASCII) characters and fills the buffer only with printable characters.  Seemingly, none printable, i.e. hex, characters don't show up in the UART buffer as is displayed in the debug window with this  NRF_LOG_HEXDUMP_DEBUG(data_array, index) command.

    If the example code does parse the console input where can I find this code?

  • Maybe I'm misunderstanding your requirements, but it seems to work as expected here. I used the original UART client/server example from SDK 15.3.0 and only changed the log level to print debug 'level' messages. The screenshot below shows the input data in Realterm and when it's being received by the server.

Related