BLE_APP_UART (Nordic UART Service) example not working as expected

[Watermelon]

Hello,

I'm working on Keil with SDK 15.0 and Softdevice S132 6.0. I'm trying to run the Nordic UART Service example. I have two nRF52832 boards (the BMD-300 Evaluation Kit and the SparkFun nRF52832 Breakout).

When I run the peripheral example ble_app_uart on the BMD-300 Evaluation Kit it works perfectly and I can connect to it in Nordic's nRF UART v2.0 app on my Android phone. When I run the central example ble_app_uart_c on the BMD-300 Evaluation Kit the LED flashes to indicate that it is scanning for a peripheral.

The problems start when I try to run these on the Sparkfun nRF52832 Breakout board. When I run the peripheral example ble_app_uart the LEDs don't flash at all and I can't see it in the Nordic app, so technically nothing happens. When I run the central example ble_app_uart_c the LED immediately becomes steadily on as if it is connected to a peripheral even though I don't have a board running the peripheral example.

I have ran other examples from the SDK on both boards and they've all worked perfectly. This is all really confusing. Does the board have to have a UART connection for this to work? Or should it still show up in the app anyway? I'm a beginner so forgive me if there's an obvious answer to this. I have a project that is due soon so I'll really appreciate it if anyone could help me out.

Thank you.

Update: I tried flashing the device (Sparkfun nRF52832 Breakout board) with the precompiled hex file and with the makefile as well. Both didn't work either.

[Einar Thorsrud]

Hi,

The precompiled .hex files in the SDK may not work on the SparkFun nRF52832 Breakout, for a few reasons:

• Referring to the schematics of the board, you need to make sure that you have the JP4 and JP5 enabled so that the LF xtal is connected. If not, the precompiled firmware from the SDK will hang when initializing the SoftDevice, waiting for the crystal to start. (Alternatively, you can modify the projects sdk_config.h so that you set NRF_SDH_CLOCK_LF_SRC to NRF_CLOCK_LF_SRC_RC.)
• Additionally, the LEDs and buttons etc. are connected to different GPIO pins on the SparkFun board than on the nRF52 DK. You need to adjust this so that it reflects the HW you are using. You can for example make a board file for your board, as instructed here.

[Watermelon]

The LF xtal is connected. I tried changing NRF_SDH_CLOCK_LF_SRC 1 and NRF_SDH_CLOCK_LF_ACCURACY 1 in the sdk_config.h file anyway but it didn't work.

I am taking into account the that the LEDs and buttons are connected to different GPIO pins on the SparkFun board. The ble_app_hrs and ble_app_hrs_c codes work fine, but not the ble_app_uart and ble_app_uart_c.

[Einar Thorsrud]

I see. Can you hook up a debugger and see if any APP_ERROR_CHECK has been hit? It could for instance be that you are getting a NRF_DRV_UART_EVT_ERROR or similar if you have a floating UART RX pin. If that is the case, then a pull-up might be a good idea (either by enabling the internal pull-up resistor on that GPIO pin or by using a external pull-up resistor).

[Watermelon]

Yes the UART Rx pin is floating!

Would I enable the internal pullup like this?

nrf_gpio_cfg_input(8, NRF_GPIO_PIN_PULLUP);

Where should I put this line of code? In sdk_config.h?

[Einar Thorsrud]

Yes, you can enable pull with nrf_gpio_cfg_input(). It does not go in sdk_config.h, but in your implementation (some .c file), for example right after you have initialize the UART driver using nrf_drv_uart_init().