nrdf52840 missing NRF_LOG messages and SD not running on BT840

[matthew antonelli]

Hello.  I'm developing a project using nRF52840.  I've been working with the nRF52840Dev Board and I have a BLE project that runs there.  I'm developing in Segger IDE and using J-Link Terminal. Im developing a project based around PCA10056 board and s140.

I have 2 problems, both of which seem to have some feedback here on the Nordicsemi support site, but the instructions that I see haven't led to any success:

1) NRF_LOG messages. I can never find the messages from NRF_LOG (for example NRF_LOG_DEBUG("Notify observer 0x%08X => blocking", p_observer);  They simply don't appear in the RTT Viewer, even though all the settings are intended to direct them there.  To get around this, I have been using sprintf and SEGGER_RTT_WriteString.  However, I think that exposing these messages is important because of problem 2 is a deeper problem.

2) I've developed a custom board using a BT840 module.  I expected that the project that I've made would just run there (it uses SD, as a BLE peripheral).  The project is based on BLE SDK examples (however, the first piece of code to the SD (ble_stack_init() err_code = nrf_sdh_enable_request() hangs, which is different than the dev board.  

I'm now realizing that I need to master the bootloader/SD linkage/app linkage setup in the project download, and  

I've erased the the device (BT840) and loaded the bootloader per the manufacturers instructions, I'm realizing that there is probably more to do than this.  I see some references to options for external clocks and preprocessor directives that need to be set.  

Some direction on either of these 2 problems is helpful.

[matthew antonelli]

Thanks for the response.

In response to the 2 issues that I have (only the 2nd is remaining)

1) do see NRF_LOG information now, although I don't see changing the  NRF_FPRINTF_FLAG_AUTOMATIC_CR_ON_LF_ENABLED making any difference.  I simply needed to do   NRF_LOG_FLUSH(); to make the messages appear, since the log device doesnt push these up to the screen without this kick.  

2) As more data for you I do have an external LFXTAL on my board, but I assume that I should be also able to make this work with the internal RC.  What you have described does make me worry that the external oscillator isnt running,  

a) I've tried running with the RC settings: 

#define NRF_SDH_CLOCK_LF_SRC 0
#define NRF_SDH_CLOCK_LF_RC_CTIV 16
#define NRF_SDH_CLOCK_LF_RC_TEMP_CTIV 2
#define NRF_SDH_CLOCK_LF_ACCURACY 1

that you described.  Same thing.  system hangs on ble_stack_init()

b) the default project, using XTAL (that runs on the dev board) runs with these settings

#define NRF_SDH_CLOCK_LF_SRC 1
#define NRF_SDH_CLOCK_LF_RC_CTIV 0
#define NRF_SDH_CLOCK_LF_RC_TEMP_CTIV 0
#define NRF_SDH_CLOCK_LF_ACCURACY 7

Should I explore changing some of these (like the accuracy) ? I'll findout the PPM accuracy of my crystal.  Are there any other settings that I should look to that can change going from Dev board to another nRF52840 module?

3) I assume that a known good SDK project that demos this in completion.  I can do this with BLE_Blinky or what ever you suggest.  

[Edvin]

matthew antonelli said:

3) I assume that a known good SDK project that demos this in completion.  I can do this with BLE_Blinky or what ever you suggest.  

 Any of the BLE examples should do. Just note that the BLE blinky doesn't blink any LEDs (I don't know if you have any LEDs on your board). But it should advertise, so I guess if you have figured out that the application hangs in ble_stack_init(), then it doesn't advertise. 

matthew antonelli said:

2) As more data for you I do have an external LFXTAL on my board, but I assume that I should be also able to make this work with the internal RC.  What you have described does make me worry that the external oscillator isnt running,  

 I think you should stick with the RC oscillator until you figure out what is wrong. Yes. The Internal RC Oscillator works even though you have an external LFXTAL. 

 

matthew antonelli said:

system hangs on ble_stack_init()

 Can you tell me where in ble_stack_init() it hangs? Have you tried stepping through this?

Does nrf_sdh_ble_enable() return a value? If so, what does it return? And inside nrf_sdh_ble_enable(), what does the function sd_ble_enable() return?

Please note that when the BLE stack is started, if you set a breakpoint, you need to reset the application. This is because the BLE stack is very time sensitive, so stopping in a breakpoint will cause the application to fail later, so if the application fails after a breakpoint was hit, that is almost certainly the reason. Does the application advertise if you don't set any breakpoints? What does sd_ble_enable() return when you are using the internal RC Oscillator?

matthew antonelli said:

1) do see NRF_LOG information now, although I don't see changing the  NRF_FPRINTF_FLAG_AUTOMATIC_CR_ON_LF_ENABLED making any difference.  I simply needed to do   NRF_LOG_FLUSH(); to make the messages appear, since the log device doesnt push these up to the screen without this kick.  

 Yes and no. It is correct that NRF_LOG_FLUSH() will process the log, but you usually don't need to use this. If the main loop in your application is reached, then idle_state_handle() calls NRF_LOG_PROCESS() until it returns false. This will process the log. Of course, if the main loop is not reached, this will not happen, so you can work around it using NRF_LOG_FLUSH() until you figure out what's going on. But once you solve it I recommend removing the NRF_LOG_FLUSH() calls that you added.

A simpler workaround to flush the log is perhaps to set NRF_LOG_DEFERRED to 0 in sdk_config.h. This will tell the log module to wait at every NRF_LOG_...() message until the log is actually processed, so it is no longer dependent on the NRF_LOG_PROCESS() or NRF_LOG_FLUSH().

Best regards,

Edvin