UART stalling on central based on NUS example

RE: UART stalling on central based on NUS example

ovrebekk — Mon, 02 Sep 2019 08:44:39 GMT

Hi Michael

The code you sent looks fine, yes. Assuming the while loop ends the external HF clock should be running continuously.

Maybe you could try to send an empty 'sync byte' of sorts at the start of every sample?

You should have enough UART throughput for it if you are sending 20000 bytes of data pr second, and it should make it easier to spot what is happening.

Best regards
Torbjørn

RE: UART stalling on central based on NUS example

michael1 — Fri, 30 Aug 2019 23:32:28 GMT

Hi,

[quote userid="2116" url="~/f/nordic-q-a/51425/uart-stalling-on-central-based-on-nus-example/206756"]I assume a single lost byte would lead to the byte order being flipped, since the only thing you are sending over the UART is the 16-bit ADC samples?[/quote]

This is correct even a single byte loss would flip the order since I am just sending 16bit ADC values that I get from the peripheral.

int main(void)
{
    ret_code_t       err_code;
    log_init();
    timer_init();
    leds_init();
    uart_init();
    power_management_init();
    ble_stack_init();
    gatt_init();
    db_discovery_init();
    ble_emg_service_init();

    err_code = sd_clock_hfclk_request();
    APP_ERROR_CHECK(err_code);
    uint32_t p_is_running = 0;
    while (!p_is_running)
    {
        sd_clock_hfclk_is_running(&p_is_running);
    }

    NRF_LOG_INFO("BLE EMG.");

    scan_start();

    bsp_board_led_on(CENTRAL_SCANNING_LED);

    for (;;)
    {
        idle_state_handle();
    }
}

I tried requesting the HF clock and I didn't see much of a difference (data still flipping). Can you take a look at this portion to see if I am requesting in the correct way that you were referring to?

Thanks,

Michael

RE: UART stalling on central based on NUS example

ovrebekk — Thu, 29 Aug 2019 06:45:16 GMT

Hi Michael

One tip when using UART is to request the external HF clock at all times, to ensure that the baudrate is as accurate as possible. You could try to set your terminal to the actual baudrate as well, but this shouldn't really be necessary as the deviation from the intended baudrate is very small (using the internal HF clock by comparison can lead to drift of 5% or more).

I assume a single lost byte would lead to the byte order being flipped, since the only thing you are sending over the UART is the 16-bit ADC samples?

Best regards
Torbjørn

RE: UART stalling on central based on NUS example

michael1 — Wed, 28 Aug 2019 17:52:41 GMT

I'm currently using a baud rate of 230400. I just tried upping the baud rate to 460800. When I increased baudrate, it seemed to stop stalling but there seems to be some sort of data loss or data corruption due to switching of the byte order of data. I pasted an example I copied where this occurs below showing what should be the byte order at the start and then it flips. All of the values should be less than 2048 because they are values from the ADC.

I noticed in the defines for the baudrate it gives an actual baudrate next to it. Should I be using this baudrate on my terminal program?

#define UART_BAUDRATE_BAUDRATE_Baud460800 (0x075F7000UL) /*!< 460800 baud (actual rate: 470588) */

. . .

b'\xf0\xff'

-16

b'\xf0\xff'

-16

b'\xff\xf2'

-3329

b'\xff\xf2'

-3329

b'\xff\xf4'

-2817

. . .

RE: UART stalling on central based on NUS example

ovrebekk — Tue, 27 Aug 2019 10:57:05 GMT

Hi Michael

What is the baudrate of your UART?

Have you scoped the UART lines to see if the data is being output on the UART as expected?

It should be possible for the client on the central side to disable notification on the NUS service once the buffers reach a certain point, which would hold back the data updates from the peripheral side. Then you can re-enable the services again once the UART buffers clear to allow the peripheral to send more data.

Best regards
Torbjørn