This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Problems with UART running ble_app_uart_c on nRF52832

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.

Parents
  • 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).

Reply
  • 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).

Children
No Data
Related