Ble_nus characters not sent to emStudio Terminal using ble_app_uart_c

[EricDelangis]

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. 

[EricDelangis]

It turns out that the "hex" values are actually converted to "ASCII" values.  Now the question is... How do I send hex values through SES's emTerminal?   

[Vidar Berg]

You can use the NRF_LOG_HEXDUMP_INFO(p_data, len) macro for printing the hex values. But they are converted to ASCII to make it readable in the terminal. Is that not what you want?  

[EricDelangis]

No. I am entering a hex string into the emStudio Terminal to be sent to the peripheral device.  emStudio is entering the characters that I enter into the transmit buffer as ASCII characters.  The peripheral device requires hex data to be sent, not ASCII.  I am trying to send a string like "fdfc038300651c" I've tried preceding these characters with a "0x" but the transmit  buffer is filled with the ASCII equivalent characters of "66 64 66 63 30 33 38 33 30 30 36 35 31 63".  I wrote a routine to try to convert the ASCII characters in the FIFO buffer to hex values but it causes some odd behavior with the application.  If you can tell me how to send raw hex values over the BLE NUS connection from the terminal session, that would help.  

[Vidar Berg]

Are you referring to the debug terminal in SES that displays debug messages from Segger RTT, and are you using RTT instead of UART to transfer the data? Anyway, I think it would be better to try a more advanced serial client like RealTerm which allow you to specify arbitrary values.  

[EricDelangis]

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.

[EricDelangis]

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?