Missing UART bytes during transmission

RE: Missing UART bytes during transmission

critbit — Tue, 05 Jan 2021 18:08:36 GMT

I've resolved the issue in the previous thread.

RE: Missing UART bytes during transmission

critbit — Tue, 05 Jan 2021 18:07:26 GMT

So I've done as I said, now the data to be broadcasted via UART is passed to the main() context via nrf_queue. This has solved the problem of missing bytes.

I still don't know the cause of the missing bytes, I guess the lesson for today is to never cut corners in such multi-context applications.

Thanks for your cooperation.

RE: Missing UART bytes during transmission

critbit — Tue, 05 Jan 2021 13:47:31 GMT

Hey,

The project is quite fresh, I'm using 17.0.2. I could migrate to anything at this point.

I'm using the crystal, bit errors happen so infrequently they could be caused by cosmic rays at this point. Bytes not sent at all happen way more often.

Thanks for the info about libuarte, this appears more familiar, when compared to STM32 ecosystem. However, it requires quite some refactoring from me.

I'll post the results later, and whether I managed to sucesfully switch to libuarte.

Best regards,
Jakub

RE: Missing UART bytes during transmission

ovrebekk — Tue, 05 Jan 2021 08:26:53 GMT

Which SDK version are you using?

The best UART driver in later versions of the SDK is the nrf_libuarte driver, which is designed to take full advantage of the EasyDMA feature of the UARTE driver.

Also, unless you are requesting the external HF crystal to be used it could be that the UART baudrate deviates quite a bit between the nRF device and the receiver. Normally this would lead to bit errors rather than dropped bytes, but it is worth checking out.

Best regards
Torbjørn

RE: Missing UART bytes during transmission

critbit — Mon, 04 Jan 2021 16:44:06 GMT

Hey, thanks much for your time.

I tried to find an correlation with amout of data sent. There are a little more characters lost when interface is more busy. But there seem to be to correlation with TX_FIFO size.

The "counter" counts chars sucesfully sent between errors. Example log dump:

17:11:22 ERROR lbga_serial.c:335: counter: 73724
17:11:26 ERROR lbga_serial.c:335: counter: 2419
17:12:33 ERROR lbga_serial.c:335: counter: 48811
17:13:43 ERROR lbga_serial.c:335: counter: 47623
17:14:32 ERROR lbga_serial.c:335: counter: 35296

Regarding your idea about fault counting, I'm not using the uart_event_handle() at all.

After having another look at app_uart_fifo.c I think I'll just reimplement the TX fifo my way, or maybe implement message-based communication, so there's no context mishmash, and everything is sent from main() context.

I'll check-in with the results here.

RE: Missing UART bytes during transmission

hmolesworth — Sat, 02 Jan 2021 23:03:35 GMT

Oh, one other issue which is more relevant. app_uart_put() is in a different thread and priority level (BLE SoftDevice) to app_uart_get() (user code serial interrupt handler). Now I recall you mentioned that app_uart_put() is also invoked from the user code uart handler. This introduces a race hazard since there is no locking and the code is not safely re-entrant, which may be more plausible than the end-of-buffer issue. I had the exact same issue now I recall; the answer is to only put and get from within the main() or other single context; incoming BLE packets are better buffered in an intermediate buffer before collecting and processing that buffer from the main context. I think this is your solution, and of course confirms your original suspicion.

You can prove this:

in main.c:
volatile bool SignalAlreadyInInterrupt = false;
volatile uint32_t FaultCount = 0UL;

in ble_nus_c_evt_handler():
        case BLE_NUS_C_EVT_NUS_TX_EVT:
            // Check if interrupt was interrupted
            if (SignalAlreadyInInterrupt) FaultCount++;
            ble_nus_chars_received_uart_print(p_ble_nus_evt->p_data, p_ble_nus_evt->data_len);
            break;

in uart_event_handle()
{
        /**@snippet [Handling data from UART] */
        case APP_UART_DATA_READY:
            if (sending anything to uart) SignalAlreadyInInterrupt = true;
            Blah Blah
            SignalAlreadyInInterrupt = false;
            
in other uart transmits
        similat to above

I'm spending time on this since it potentially affects medical devices I have designed.

RE: Missing UART bytes during transmission

hmolesworth — Sat, 02 Jan 2021 20:49:37 GMT

>4k means 4096 I take it, assuming you are using the FIFO which requires a power of 2 buffer size. Since 1/4096 = .02% a single byte error on FIFO buffer wrap would be roughly the same order as the observed error rate (about 0.01%) which raises suspicions of a bug in the library code. Perhaps you could try changing the buffer size to see if it affects the error rate?

Looking at the fifo code I see this dubious code:

/**@brief Put one byte to the FIFO. */
static __INLINE void fifo_put(app_fifo_t * p_fifo, uint8_t byte)
{
    p_fifo->p_buf[p_fifo->write_pos & p_fifo->buf_size_mask] = byte;
    p_fifo->write_pos++;
}

Notice how p_fifo->write_pos is not checked for overflow; does it matter? Maybe not if always used with the mask, but I would describe that as unsafe code and now p_fifo->write_pos will wrap at 2^32 instead of TX_BUFFER_SIZE. p_fifo->write_pos is 32-bit, p_fifo->buf_size_mask is 16-bit. Does it work? Probably, but dodgy code methinks

Look at this:

static __INLINE uint32_t fifo_length(app_fifo_t * p_fifo)
{
    uint32_t tmp = p_fifo->read_pos;
    return p_fifo->write_pos - tmp;
}

No sign of the mask being used here; does it matter? Hmm .. differencing two indices which are both beyond the end of the buffer they refer to is not good practice; when write wraps at 2^32-1 before read, what then? Maybe (with mask) 1 character is lost every 4096

/**@brief Look at one byte in the FIFO. */
static __INLINE void fifo_peek(app_fifo_t * p_fifo, uint16_t index, uint8_t * p_byte)
{
    *p_byte = p_fifo->p_buf[(p_fifo->read_pos + index) & p_fifo->buf_size_mask];
}


/**@brief Get one byte from the FIFO. */
static __INLINE void fifo_get(app_fifo_t * p_fifo, uint8_t * p_byte)
{
    fifo_peek(p_fifo, 0, p_byte);
    p_fifo->read_pos++;
}

peek uses mask, get does not, so no correct wrap on read.

So, maybe try reducing the buffer size which should increase the error rate in proportion. Or I'm wrong :-)

My notes above were for SDK v15.3.0, but I see the FIFO handling was changed in SDK v17.0.2 so maybe just try that; it wasn't clear from the post which version was used originally.

RE: Missing UART bytes during transmission

critbit — Sat, 02 Jan 2021 11:23:11 GMT

I forgot to mention, the UART_TX_BUF_SIZE is >4k

While I agree that your scheme of transmission might work better in production, that doesn't change anything in my case, as app_uart_put() always returns NRF_SUCCESS for me.

Just for the reference, i checked it, doesn't seem to fix the issue.

RE: Missing UART bytes during transmission

hmolesworth — Fri, 01 Jan 2021 23:31:12 GMT

Try replacing:

        APP_ERROR_CHECK(app_uart_put(c));

with this:

         do
         {
            err_code = app_uart_put(c);
            if ((err_code != NRF_SUCCESS) && (err_code != NRF_ERROR_BUSY))
            {
               // NRF_LOG_ERROR("Failed Tx Uart message. Error 0x%x. \r\n", err_code);
               // APP_ERROR_CHECK(err_code);
            }
         } while (err_code == NRF_ERROR_BUSY);

Also make UART_TX_BUF_SIZE big, say 2048

I've used the above BLE-to-uart at both 230,400 and 1MBaud on large data transfers with no issues