Running Timesync Example on Sparkfun Breakout

nickwerline gravatar image

asked 2017-11-20 02:30:08 +0100

updated 2017-11-21 06:57:32 +0100

I would like to get the timesync example running on the Sparkfun nRF52832 Breakout board.

I can currently download it to the nRF52832 DK using Segger Studio (after making the changes suggested for the project to work with the Segger IDE) and run it without issues.

I can download other programs onto the Sparkfun board without issues.

I see different results when I debug the DK than when I debug the Sparkfun board. (Assuming the debugging in Segger Studio is actually debugging the Sparkfun board)

The Sparkfun board appears to get stuck in an infinite loop here:

// Skip any string that is pushed to the circular buffer.
while (p_header->base.generic.type == HEADER_TYPE_PUSHED)
    rd_idx       += PUSHED_HEADER_SIZE;
    rd_idx       += (p_header->base.pushed.len + p_header->base.pushed.offset);
    p_header = (nrf_log_header_t *)&m_log_data.buffer[rd_idx & mask];

which is found in the file nrf_log_frontend.c at function log_skip():

* @brief Skips the oldest, not pushed logs to make space for new logs.
* @details This function moves forward read index to prepare space for new logs.

static void log_skip(void)

    uint32_t           rd_idx = m_log_data.rd_idx;
    uint32_t           mask   = m_log_data.mask;
    nrf_log_header_t * p_header = (nrf_log_header_t *)&m_log_data.buffer[rd_idx & mask];
    nrf_log_header_t   header;

    // Skip any string that is pushed to the circular buffer.
    while (p_header->base.generic.type == HEADER_TYPE_PUSHED)
        rd_idx       += PUSHED_HEADER_SIZE;
        rd_idx       += (p_header->base.pushed.len + p_header->base.pushed.offset);
        p_header = (nrf_log_header_t *)&m_log_data.buffer[rd_idx & mask];

    uint32_t i;
    for (i = 0; i < HEADER_SIZE; i++)
        ((uint32_t*)&header)[i] = m_log_data.buffer[rd_idx++ & mask];

    switch (header.base.generic.type)
            rd_idx += CEIL_DIV(header.base.hexdump.len, sizeof(uint32_t));
        case HEADER_TYPE_STD:
            rd_idx += header.base.std.nargs;

    uint32_t log_skipping_tmp = nrf_atomic_flag_clear_fetch(&m_log_data.log_skipping);
    //update read index only if log_skip was not interrupted by another log skip
    if (log_skipping_tmp)
        m_log_data.rd_idx = rd_idx;

Does anyone know what is the issue or of a modification that could be made? Even if it has to remove a portion of the functionality, that's fine.


I now get a hard fault exception regardless if NRF_LOG_ENABLED is set to 0 or 1. The previous infinite loop is no longer happening. I am also using the Segger project that was uploaded to the time sync example GitHub.

Here is a screenshot of the call stack after the exception. My cursor is on the event I assume is the first occurrence of the exception. The same error occurs when running the standard UART example.

image description

You can also see in the debug terminal an ERROR 4 [NRF_ERROR_NO_MEM] goes on to say at line 603 in main. Here is an image of that section of code.

image description

edit retag flag offensive close delete report spam



Does it make any difference if you turn off logging ? I.e. in sdk_config.h , set NRF_LOG_ENABLED to 0.

Sigurd ( 2017-11-20 12:37:33 +0100 )editconvert to answer

I have appended the original post with more information and screenshots. I no longer get the previous behavior for some reason. Now I consistenly see an ERROR 4 [NRF_ERROR_NO_MEM]

Nick ( 2017-11-21 06:52:07 +0100 )editconvert to answer

So if the APP_ERROR_HANDLER() is triggered on line 603, you have the event APP_UART_COMMUNICATION_ERROR.

Looking at the app_uart_evt_t::error_communication documentation here, it stated that This field contains the value in the ERRORSRC register for the UART peripheral. This register tells us that the value 4 means that:

Framing error occurred: A valid stop bit is not detected on the serial data input after all bits in a character have been received.

Are you using any USB<->UART bridge on your breakout board?

Sigurd ( 2017-11-21 09:59:31 +0100 )editconvert to answer

I am using the Beefy 3 3.3v. I don't have experience with using it for communications so I wouldn't know how to diagnose or fix it.

Nick ( 2017-11-22 00:15:34 +0100 )editconvert to answer

Are you using flow-control ? Maybe try to enable/disable it? You could also try to reduce the baudrate, and see if that have any effect.

Could it be that you have left the RX line floating? Here is a relevant thread: UART Peripheral Dead?

Sigurd ( 2017-11-22 11:35:02 +0100 )editconvert to answer

You are right that the RX pin was not being pulled up. I added

nrf_gpio_cfg_input(RX_PIN_NUMBER, NRF_GPIO_PIN_PULLUP);

after the call to APP_UART_FIFO_INIT() This fixed the issue and I can now connect to the device via Bluetooth, thank you.

However, I cannot communicate with the Sparkfun board over serial. I can use Termite with the DK for sending messages back and forth. Doing the same method with the Sparkfun board has nothing showing up. Lowering the baud rate and trying flow control didn't change anything.

Nick ( 2017-11-23 05:48:44 +0100 )editconvert to answer

One interesting note is even though flow_control is set to APP_UART_FLOW_CONTROL_DISABLED in the project, I had to enable RTS/CTS in Termite in order to send messages to the DK. I could receive messages with or without flow control set.

Nick ( 2017-11-23 05:48:51 +0100 )editconvert to answer

Do you have the Beefy 3 model with rx/tx leds? Do they light ? Also double check your connections/pins. Maybe installing the FTDI drivers helps ?

Sigurd ( 2017-11-23 14:44:53 +0100 )editconvert to answer

I can use the Sparkfun board with the Beefy 3 for serial communication in an Arduino sketch. The leds come on when receiving and transmitting.

When I try to use it with the time sync demo, I do get the rx led when sending from Termite, but I do not see it appear in the nRF Toolbox UART app. I do not get the tx led when trying to send from the nRF Toolbox UART app. The app works with the DK.

Nick ( 2017-11-24 06:20:54 +0100 )editconvert to answer

I see the APP_UART_TX_EMPTY event in the uart_event_handler when trying to send something from the UART app.

I do not see the APP_UART_DATA_READY event when sending something via Termite to the board.

I see both of these events with the DK.

Nick ( 2017-11-24 06:31:30 +0100 )editconvert to answer

APP_UART_TX_EMPTY indicates that UART has completed transmission of all available data in the TX FIFO.

If you are not getting APP_UART_DATA_READY , you are not receiving any data.

A logic analyzer (e.g. Saleae) could help with further debugging.

Sigurd ( 2017-11-28 14:59:04 +0100 )editconvert to answer

Thank you for the help on everything. I will stick to the development kits for now and revisit this. The information has been valuable.

Nick ( 2017-11-28 19:27:31 +0100 )editconvert to answer