Can you fix NRF_LOG* in SDK 11?

[Richard von Lehe]

Not sure if forums or MyPage support requests are better for this.

It seems NRF_LOG has taken a step backward from what was used in the previous nRF52 0.9.2 SDK. What I've discovered is that there is no buffering at all taking place. If the remote terminal emulator is not pulling the characters off as fast as the hardware (nRF52 board) is writing them, the message that is being logged gets truncated. For me at the hard-coded 38400baud rate, this means one character gets logged and the rest of the message is lost.

If you look at app_uart_init, you'll see app_uart_buffers_t being passed in. This is never used in that function. So whatever you set TX_BUFFER_SIZE to is ignored. Calling NRF_LOG or one of its variants boils down to this:

A loop calls app_uart_put/nrf_drv_uart_tx with one character.
As fast as that loop runs, it will call those functions. As soon as nrf_drv_uart_tx gets called and the TX buffer isn't empty, it quits.

By fix, I mean set this up so that a transmit buffer greater than 1 is used. It used to be that TX_BUFFER_SIZE was the size of the transmit buffer.

[Richard von Lehe]

OK, all is well. I had completely forgotten that it is possible to swap out app_uart.c and swap in app_fifo.c and app_uart_fifo.c. I was able to do that with the new SDK. It seems the normal non-fifo UART functionality is not very useful, at least for my purposes. I also got RTT logging to work, and that might come in handy at some point, but it seems like it would be a bit less convenient since it ties up the JLINK connection. Maybe I need to look in to that further, as there must be a way to debug and view RTT logging simultanteously.

In any case, I'm marking this answered.