Problem with example fpu_fft sdk13 nRF52832

RE: Problem with example fpu_fft sdk13 nRF52832

bjorn-spockeli — Wed, 03 May 2017 11:47:30 GMT

Happy to help. If the answer solved your issue then I would appreciate if you caould mark the answer as correct/accepted by clicking the checkmark in the grey circle to the left of the answer.

RE: Problem with example fpu_fft sdk13 nRF52832

stefano.luna — Wed, 03 May 2017 08:00:10 GMT

Thank you, very useful

RE: Problem with example fpu_fft sdk13 nRF52832

bjorn-spockeli — Wed, 26 Apr 2017 09:33:54 GMT

It is log issue. Our UARTE can send only 255 bytes of data. UART API is prepared to handle at most 256B (see nrf_drv_uart_tx). Log subsystem can handle more data, but there is lack of some assertion on uart backend (see serial_tx function in nrf_log_backend_serial, mixing uint32_t with uint8_t in nrf_drv_uart_tx).

The best solution to deal with huge amount of data on log output is use RTT to receive. You'll have to switch the NRF_LOG backend from UART to RTT, this is done by change the following values values in sdk_config:

NRF_LOG_BACKEND_SERIAL_USES_UART 0

NRF_LOG_BACKEND_SERIAL_USES_RTT 1

NRF_LOG_BACKEND_MAX_STRING_LENGTH 2048(or more if You want to draw more)

NRF_LOG_BACKEND_RTT_OUTPUT_BUFFER_SIZE 2048(or more if You want to draw more)

SEGGER_RTT_CONFIG_DEFAULT_MODE 2

And of course switch to RTT Viewer, which should automatically find RTT buffers.

RE: Problem with example fpu_fft sdk13 nRF52832

bjorn-spockeli — Tue, 25 Apr 2017 09:38:37 GMT

Hi Stephano, I am able to reproduce the behavior and I have asked the developer that made the example look into the issue. I will update my answer as soon as I hear back from him.