Problems with UART running ble_app_uart_c on nRF52832

[kont40]

Hello, I am trying to run the ble_app_uart_c example that is part of the nRF5_SDK_13.1.0_7ca7556 on a custom board with nRF52832 using IAR. Hardware seems healthy, I succeeded to run LEDs and make them blink... I am having troubles with running the UART, however:

Initialization of UART is as follows:

const app_uart_comm_params_t comm_params =
  {
    .rx_pin_no    = RX_PIN_NUMBER,
    .tx_pin_no    = TX_PIN_NUMBER,
    .rts_pin_no   = RTS_PIN_NUMBER,
    .cts_pin_no   = CTS_PIN_NUMBER,
    .flow_control = APP_UART_FLOW_CONTROL_DISABLED,
    .use_parity   = false,
    .baud_rate    = UART_BAUDRATE_BAUDRATE_Baud115200
  }; 

and also:

#define RX_PIN_NUMBER  NULL
#define TX_PIN_NUMBER  7 
#define CTS_PIN_NUMBER NULL
#define RTS_PIN_NUMBER NULL
#define HWFC           false

After running uart_init(); passes with success (I have played with LEDs to get the result), however the debug lines

printf("BLE UART central example started.\r\n");
NRF_LOG_INFO("BLE UART central example started.\r\n");

do not produce any output on the TX pin.

Also, in the main loop I have the following:

for (;;)
{
    //power_manage();
  
  bsp_board_led_off(0);       
  bsp_board_led_on(1);
  nrf_delay_ms(3000);
  bsp_board_led_off(1);
  bsp_board_led_on(0);
  nrf_delay_ms(3000);  

}

When the uart_init() is commented/disabled I can get the two LEDs blinking, if uart_init() is not commented and gets executed only one LEDs is always lit, which means the nrf_delay_ms is not executed properly.

Since I am dealing with ble_app_uart_c for first time, I am not quite sure where to search for the problem, any advice would be helpful.

[kont40]

Also, is there any descritpion what settings need to be adjusted to run ble_app_uart_c on a custom board? For now I try to use it on my board without success. I have confirmed the oscillators (32kHz and 32 Mhz) are both functional, also the Tx pin is functional. Therefore, at least to see some output from the uart should be a matter of project configuration, where I am missing something, obviously...

[kont40]

Although external oscillators seem to work, would it be a good idea to try using internal oscillators to avoid one potential source of the problem?

[kont40]

Now I am trying the simple code for UART given below, and receiving Error 9 (invalid length1?) after the APP_UART_FIFO_INIT ... What should this error refer in the particular case?

"....
const app_uart_comm_params_t comm_params =
  {
      RX_PIN_NUMBER,
      TX_PIN_NUMBER,
      RTS_PIN_NUMBER,
      CTS_PIN_NUMBER,
      APP_UART_FLOW_CONTROL_DISABLED,
      false,
      UART_BAUDRATE_BAUDRATE_Baud115200
  };

APP_UART_FIFO_INIT(&comm_params,
                     UART_RX_BUF_SIZE,
                     UART_TX_BUF_SIZE,
                     uart_error_handle,
                     APP_IRQ_PRIORITY_LOW,
                     err_code);
sprintf(int_str, "error %d", err_code); 
SEGGER_RTT_WriteString(0, int_str);
APP_ERROR_CHECK(err_code);

...."

[endnode]

It's so simple, just read SDK documentation (how APP_UART_FIFO_INIT looks like in components\libraries\uart\app_uart.h which leads to signature/header of app_uart_init function at line 207 and onwards):

@retval      NRF_ERROR_INVALID_LENGTH  If a provided buffer is not a power of two.

As you can see in app_uart module this Nordic SDK library/driver works only with Tx/Rx buffer lengths of power of two (2/4/8/16/32/64/128/256/512/1024/2048/4096/8192/...).

[kont40]

Thanks, I indeed overlooked that and it solved the error condition. The matter is I am still struggling to make my board working. I observed a strange "phenomena" - after many attempts yesterday, this morning I tried to run the ble_app_uart_c and this time it simply worked! When I tried, however, to reprogram the softdevice, I entered into the same problems I had so far - at some point the application simply hangs somewhere... So that suggests the following conclusions:

• my pcb generally is fine or almost fine;
• the application I am loading is fine. Perhaps there is something related to the softdevice or project settings I am overlooking, but I simply can't find what is it. Is it possible the MCU be damaged during soldering and behaving strangely?!(but I have about 4 non-working boards now, that behave the same way, so perhaps not a hardware issue)