unable to use ble_uart using nrf52810

[_bhanu]

Hi,

I'm using app_ble_uart  example using nrf52810 for nrf52810 UART RX &  TX  pins are (P0.15 - P0.14)  while configuring using i got a problem with RX transmission ,when i changed to  Rx pin as p0.15  the nrf52810 module is not working.

[Einar Thorsrud]

Hi,

I have some questions:

• In what way does it not work?
• Can you explain in detail how you changed the pin, perhaps by uploading a diff of your code compared to the SDK example?
• Also, which module do you have and how do you use it (anything particular with P0.15, for instance)?
• Which SDK are you using)?

[_bhanu]

1. I'm using ble_app_uart example  using NRF52810  custom board  and nRF5_SDK_17.1.0_ddde560. IN SDK  config  i just changed the RX and TX pins  to (P0.15 & P0.14)   after  upload the coded to NRF52810 custom board  the custom board not working like its not  going to "powered on" .

If i just change only (TX pin to  P0.14)  NRF52810 module  is going to powered on its advertising the ble and it only transmitting the data .when if i change  RX pin  also even the NRF52810 module not going to powered on .

Here i changed the TX and RX pin in my code

static void uart_init(void)
{
    uint32_t                     err_code;
    app_uart_comm_params_t const comm_params =
    {
        .rx_pin_no    = 15,
        .tx_pin_no    = 14,
        .rts_pin_no   = RTS_PIN_NUMBER,
        .cts_pin_no   = CTS_PIN_NUMBER,
        .flow_control = APP_UART_FLOW_CONTROL_DISABLED,
        .use_parity   = false,
#if defined (UART_PRESENT)
        .baud_rate    = NRF_UART_BAUDRATE_115200
#else
        .baud_rate    = NRF_UARTE_BAUDRATE_115200
#endif
    };

    APP_UART_FIFO_INIT(&comm_params,
                       UART_RX_BUF_SIZE,
                       UART_TX_BUF_SIZE,
                       uart_event_handle,
                       APP_IRQ_PRIORITY_LOWEST,
                       err_code);
    APP_ERROR_CHECK(err_code);
}

[Einar Thorsrud]

Hi,

You need to ensure that the inputs are not floating. If the UART lines are always connected to another device on the board, and this always drives the input lines to the nRF ( Rx and optionally CTS), then there is no need for pullup(s). If not, you can enable the internal pullup. See this post.

[_bhanu]

Hi,

Hear my UART lines  TX and RX are connected to "QUECTEL" module  when the Quectel module is on  nRF device working fine, when i turned of the Quectel module which is connected to UART  then nRF is also going to turn off automatically. 

[Einar Thorsrud]

Hi,

I see. Then there should not be a need for any pull resistors (and if you double-check and see that in some corner cases the inputs are floating, you can always just enable internal pullups on the nRF).

[_bhanu]

Hi,

Einar Thorsrud said:

you can always just enable internal pullups on the nRF

I tried to do RX pin as internal pullup using "nrf_gpio_cfg_input(RX pin, NRF_GPIO_PIN_PULLUP)" but then also I'm facing same issue,

is their any alternative way to internal pullup the UART RX pin.

[Einar Thorsrud]

Hi,

If you enabled the internal pullups as described, then you have pullups so that should be good (and if the other device always drives the pins it is not even required). So I suggest you start looking in another direction.

I am not sure I have the full picture here. Can you elaborate more on which issue you are seeing now and in what way things are not working? Also, what have you found from debugging?

[_bhanu]

Hi,

Einar Thorsrud said:

Can you elaborate more on which issue you are seeing now and in what way things are not working?

as i said earlier I'm transferring  and receiving the data through Quectel m66 module  using  NRF UART,

after the completion of transferring and receiving the data  I'm  going to turn off the Quectel module .

when i turn off the Quectel module NRF52810 also turning off automatically 

Einar Thorsrud said:

what have you found from debugging?

<error> app: ERROR 4 [NRF_ERROR_NO_MEM] at C:\nrf_sdk\nRF5_SDK_17.1.0_ddde560\examples\ble_peripheral\ble_app_uart\main.c:429
PC at: 0x0001A393
<error> app: End of error report

This is the error I found while debugging.

[Einar Thorsrud]

Aha, so you are simply seeing that an error check has caught an error. That is a very good starting point. What does your code look like around line 429 in your main.c? Most importantly, which function returned this error code (NRF_ERROR_NO_MEM)?

[_bhanu]

Hi,

Einar Thorsrud said:

What does your code look like around line 429 in your main.c?

Einar Thorsrud said:

Most importantly, which function returned this error code (NRF_ERROR_NO_MEM)?

I assume In "uart_event_handle(app_uart_evt_t * p_event)" function this error occurs

[Einar Thorsrud]

Yes, that is it. You got an APP_UART_COMMUNICATION_ERROR, and the error_mask holds the value of the ERRORSRC from the UARTE peripheral. The error handler assumes standard SDK error codes to it interprets that number as NRF_ERROR_NO_MEM, but that corresponds to 4, which is then the value of ERRORSRC. Looking at the UARTE chapter in the product specification you can see that this represents the FRAMING bit. So there has been a framing error on the UART.

A framing error is typically caused by a mismatch between the baud rates on the two devices (UART is asynchronous after all, and if the clocks are too different you will get framing errors). So you need to ensure that the frequency is right:

1. Have you configured the same baud rate on the nRF and the other device? That is a must.
2. Have you started the HFXO on the nRF? If not, the HFINT oscillator is used and that is often not accurate enough (particularily for longer UART transactions, or simply if you have bad luck and go ta device with a large frequency offset as there is significant chip-to-chip variation, and also temperature variation).