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]

Could it be softdevice and application addresses mismatch? if so why I am not getting any error message while downloading applicaiton? Also, I am using the project settings given by default in the ble_app_uart_c example , could it be they need adjustment?

[endnode]

These are probably the hardest issues to debug and almost impossible over the forum. The only thing which lead to success in such cases for me was to sit down and do very careful small iterations meaning first do some FW without SoftDevice, verify that all things like HF and LF clock, GPIOs/LEDs/Buttons, wired interfaces such as UART/SPI/TWI/I2S work. One thing at a time, minimal FW to be sure what is happening. Only then go with radio so deploying FW and SD together - if any problem occurs then again using stripped-down FW which only has BLE and debugging UART (or RTT) and go step by step with as few code as possible to eliminate any side-effects and consequences of having too many things running or adding too many code and SDK modules that it's almost impossible to say which of them caused it not working (as it was in previous step).

[kont40]

And still: when I comment out uart_init and printf the other parts run and the LED behaves quite intelligently, so I could guess the application otherwise runs well. So just need to figure out what is the problem with the UART init, and why I was able to observe the whole app (including the UART) work well once. The code of the ble example I am trying:

int main(void) { timer_init(); SEGGER_RTT_WriteString(0, "Hello World!\n"); //uart_init();

log_init();
buttons_leds_init();
db_discovery_init();
ble_stack_init();
gatt_init();
nus_c_init();

// // // Start scanning for peripherals and initiate connection // // with devices that advertise NUS UUID. //printf("BLE UART central example started.\r\n"); NRF_LOG_INFO("BLE UART central example started.\r\n"); scan_start();

for (;;)
{
    power_manage();
}

}

[endnode]

Forget about BLE for a second, no db_discovery or ble_stack, just compile UART driver example from SDK (examples\peripheral\uart\) without Soft Device and try to get some output to terminal. Until you succeed with that it has no value to try complex FWs.

[kont40]

That is really a good advice! I tried, and when using app_uart_put('p'); I can get the proper character in the terminal. However, when using the printf, I am getting blanks - 0x0D. So perhaps this time there is something about printf, I can guess...