Error-check with printf() and NRF_LOG() not working

RE: Error-check with printf() and NRF_LOG() not working

Ray Breslin — Thu, 30 Mar 2017 12:46:08 GMT

Yes of course - I will do that!

RE: Error-check with printf() and NRF_LOG() not working

FormerMember — Thu, 30 Mar 2017 07:59:48 GMT

Could you create a new question regarding the NRF_LOG_DEFERRED problem?

RE: Error-check with printf() and NRF_LOG() not working

Ray Breslin — Wed, 29 Mar 2017 16:54:43 GMT

While I can actually live with the current usability of NRF_LOG(), I would be very much interested in figuring out why the NRF_LOG_DEFERRED-option is causing such problems. So far I couldnt find anything specific here on the forum or on the info-center, but I am assuming that I might be missing something f.ex. in the sdk_config.h or during initialization...

RE: Error-check with printf() and NRF_LOG() not working

Ray Breslin — Wed, 29 Mar 2017 16:48:32 GMT

d) After some tests I figured out that I would see an advertising-timeout causing a state-switch to BLE_ADV_EVT_IDLE, which then would result in a sleep_mode_enter()-call where it doesnt return (by default).

e) What happened here was precisely as I already guessed, since the 2 logging-functionalities where "overlapping" each other. Since I just use the NRF_LOG()-functionality now, I can see all the log-messages from myself and from within the SDK in just the order they are supposed to be in. Compared to my log-output above, I am getting the "SDH:INFO:sd_ble_enable: RAM START at 0x20002128"-message directly after "BLE Stack Initialized"-message and that is how it should be.

f) Basically it was already answered with e), so there is no overlapping-anymore. Regarding the timestamps I previously used a self-created print_timestamp()-function that was returning a char-pointer!

RE: Error-check with printf() and NRF_LOG() not working

Ray Breslin — Wed, 29 Mar 2017 16:41:22 GMT

Thank you for your answer Kristin and my apologies for not responding earlier!

Here are some updates from my side:

a) I decided to just go with the NRF_LOG-API using a wrapper-function for NRF_LOG_RAW_INFO(), that seems to work quite nicely. One reason for that is a somehow "undefined" behaviour of printf() - including the retarget-functionality - while using a GCC-toolchain as various other topics in the development forum pointed out.

b) I went also for the same options you mentioned, since having NRF_LOG_DEFERRED enabled (easy switch in my wrapper-function from a)) caused some kind of not-responding-error after some time. I even played around with the buffer-sizes, but it always failed pretty much at the same location where it would just continue when being disabled!

c) Thanks for the info - couldnt find any code-line though that specifically uses assert_nrf_callback().

RE: Error-check with printf() and NRF_LOG() not working

FormerMember — Thu, 16 Mar 2017 12:13:24 GMT

a) On the nRF52, there is only one UART. It means that you can either use NRF_LOG over UART or "your own" UART. If you want to use NRF_LOG in parallel with "your" UART, you should use NRF_LOG over RTT instead.

b) The default settings for NRF_LOG are:

UART_DEFAULT_CONFIG_HWFC: Disabled
NRF_LOG_DEFERRED: Disabled
NRF_LOG_BACKEND_SERIAL_UART_FLOW_CONTROL: Disabled

If using UART in combination with the softdevice, I would recommend you to enable HWFC in order to avoid loosing data over UART.

c) Yes, the softdevice will use assert_nrf_callback().

d) There should not be any troubles related to 180 s advertising timeout. In on_timeout(), which error code does ble_advertising_start() return?

e) I didn't think that logging works before it has been initialized, that sounds strange.

f) What does your initialization code looks like? When using "bare" printf, there will normally not be any timestamps. But I guess, since NRF_LOG also is enabled that there is something that somehow overlaps.