RE: BT 5.0 on ble_app_uart 2MPHY

Edvin — Thu, 02 May 2019 11:42:01 GMT

Hello,

I suggest you use the NRF_LOG_INFO(); for logging, and printf() for your UART purpose only. Your log is printed in the RTT Log. Have you used RTT Viewer to view this? Or if you use Segger Embedded.

Where do you see "Fatal"? Is that in the RTT log? If you see "Fatal", can you please try to define DEBUG in your preprocessor defines? Let me know if you:

1. Don't know how to view your log messages (NRF_LOG_INFO()).

2. Don't know how to define DEBUG in your preprocessor defines.

If you define DEBUG and monitor your log, what does the log say then?

BR,

Edvin

RE: BT 5.0 on ble_app_uart 2MPHY

Bar1 — Fri, 26 Apr 2019 10:50:19 GMT

Hi Edvin,

The error I get once I send the data with UART to the peripheral is a FIFO ERROR.

Thanks

RE: BT 5.0 on ble_app_uart 2MPHY

Bar1 — Thu, 25 Apr 2019 12:52:13 GMT

Hi Edvin,

Today I got some new result that now I try to summarize.

Before, in the instant which I sent the data at that speed from the other side I saw one, max 2 packets and then disconnected and no longer reconnected ( I will try to dig deeper on this).

Today, however, I made a small change to the code and in particular I call this function

void phy_update_request(ble_evt_t const * p_ble_evt){
    ret_code_t err_code;
    ble_gap_phys_t const phys =
    {
        .rx_phys = BLE_GAP_PHY_2MBPS,
        .tx_phys = BLE_GAP_PHY_2MBPS,
    };
    err_code = sd_ble_gap_phy_update(p_ble_evt->evt.gap_evt.conn_handle, &phys);
    APP_ERROR_CHECK(err_code);
}

In the ble_event_handler routine, under the case : BLE_GAP_EVT_CONNECTED in the main.
After that I did that I can see that it is going way better, in fact now from the "central" side (I'm sending data
from a micro-controller via UART to the peripheral) I can see the packets arriving good.
The problem now is that, if for any reason the connection fails the program from the peripheral goes in Fatal Error and
it remain there, because, even if there is no connection from the "microcontroller" side I am still sending data.
In fact, if I stop the data streaming, the program exits from the error routine and starts again.
So at this point I thought how let the micro know when there is a connection
(via a message on the UART - printf ("BLE Connection OK"), in the connection routine) and when there is no connection.

 switch (p_ble_evt->header.evt_id)
 {
        case BLE_GAP_EVT_CONNECTED:
             NRF_LOG_INFO("Connected");

             printf("\r\nBLE CONNECTION ON\r\n");

             err_code = bsp_indication_set(BSP_INDICATE_CONNECTED);
             APP_ERROR_CHECK(err_code);
             m_conn_handle = p_ble_evt->evt.gap_evt.conn_handle;
             err_code = nrf_ble_qwr_conn_handle_assign(&m_qwr, m_conn_handle);
             APP_ERROR_CHECK(err_code);

             phy_update_request(p_ble_evt);
             break;

        case BLE_GAP_EVT_DISCONNECTED:

             printf("\r\nBLE CONNECTION OFF\r\n");

....
}


The problem is that in the BLE_GAP_EVT_DISCONNECTED routine, only the first character of the string is printed and then returns to the error routine.
at this point I thought of putting a print on the UART in the error routine:

__WEAK void app_error_fault_handler(uint32_t id, uint32_t pc, uint32_t info)
{
    __disable_irq();
    NRF_LOG_FINAL_FLUSH();

    #ifndef DEBUG
       printf("DISCONNECTED\n");
       NRF_LOG_ERROR("Fatal error");
    #else
      switch (id)
          .....

}

In this case I always have the same problem (it prints only the first character), but prints it several times
consecutive (enters several times in the error routine). In this way, I thought in setting a character
(for example -> "*" instead of printf("DISCONNECTED\n")), and once I get, for example, 5 "*" in row I have to stop the streaming from the micro controller side.


However I don't like this approach so much and I was wondering if there is a way to avoid the problem upstream,
that is maybe to interrupt the reading on the UART when the connection has not yet happened.

What do you think about this?

Anyway thank a lot for your help and your time.

RE: BT 5.0 on ble_app_uart 2MPHY

Edvin — Thu, 25 Apr 2019 12:11:11 GMT

Hello,

What is your disconnect reason on the nRFs (on both)?

My guess is that one of them is caught in an APP_ERROR_CHECK(err_code) with err_code != 0, and the other one receives a supervision timeout?

Try to define DEBUG in your preprocessor defines, and look at your RTT log (make sure that NRF_LOG_ENABLED is set to 1 in sdk_config.h, and that NRF_LOG_BACKEND_RTT_ENABLED is 1.

Do this, and monitor your log. Does any of the devices say anything useful in the log?

Best regards,

Edvin