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.

[Edvin]

Hello,

 

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.

 I am not sure this is the issue, but are you using the RTT window in Segger Embedded Studio? If so, what you are seeing is a bug where it doesn't handle CR correctly. Open sdk_config.h, and check that these are set:

#define NRF_LOG_BACKEND_RTT_ENABLED 1

#define NRF_FPRINTF_FLAG_AUTOMATIC_CR_ON_LF_ENABLED 0

Do you see the log messages if these are changed? Was the logging module included in the project when you started? If not, look at one of the examples of how this is initialized and processed. 

 

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.  

This is a typical symptom of the LFCLK not configured correctly. The nrf_sdh_ble_enable() (called from ble_stack_init()) waits for the LFCLK to start. If it is set to use an external LFXTAL that isn't present, it will wait forever. I guess your board doesn't have the external LFXTAL, as this is optional. At the same time, all examples in the SDK are targeted on boards that have the LFXTAL enabled. What you need to do if you don't have the LLFXTAL is to change to the following settings in sdk_config.h:

#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

And it should work with the internal RC Oscillator instead of the external LFXTAL.

Let me know whether this solved your issues. 

I am quite sure 2) should be solved, but if 1) wasn't solved: What RTT viewer are you using? The one in Segger Embedded Studio, or the standalone JLink RTT Viewer? If you use the standalone JLink RTT VIewer, does it work with an unmodified example that uses RTT backend for logging, such as the ble_app_uart example? And does it work in the RTT monitor in Segger Embedded Studio if you set the NRF_FPRINTF_FLAG_AUTOMATIC_CR_ON_LF_ENABLED to 0 in sdk_config.h in the same example?

Best regards,

Edvin

[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.  

[matthew antonelli]

Hello.  update of some info for you.

0) I still havent gotten my custom hardware to work (SD running)

To make this debugging more simple, I've switched to the ble_app_blinky project.

1) I've loaded the ble_app_blinky project on to my dev board, to prove that I have a working project.  I don't know how to interact with it, but clearly it is running as the Device "Nordic_Blinky" appears in Nordic Connect. I also see a "DfuTarg" device

2) When I run this on my custom target, which by the way has a Fanstel BC840 module (that I previously called BT840 in error) I see a DfuTarg device but no "Nordic_Blinky"

3) So I think that this shows that something in my specific device that doesn't let the Nordic_Blinky app run.  Now, on my board I have a 32.768Khz oscillator (and some oscilloscope tests prove to me that this running), and the module has a 32Mhz oscillator.  I'm realizing that uploading correct bootloader to these nrF52840 modules may be critical.

4) I modified the LFXTAL instructions in the BLE_APP_BLINKY project and downloaded this to the custom hardware

#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

Still no "Nordic_Blinky" running

My question is: What bootloader should be running? I guess one updates the bootloader on the NRF52840 with NRF Command line utilities.    What debug steps would you follow on this?

[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

[Edvin]

Oh. If the device is advertising as DfuTarg, it means that it is a bootloader that doesn't accept your application. Did you flash the bootloader yourself, or did it come pre-programmed from the factory?

If you don't have the keys to the bootloader, you can erase it. Use nRF Command Line Tools, with the command:

nrfjprog --eraseall

to erase the flash on the nRF. (you can add your own bootloader at a later point in time, if you like). 

 

matthew antonelli said:

Now, on my board I have a 32.768Khz oscillator (and some oscilloscope tests prove to me that this running)

 What does the layout around the LFXTAL look like? I still want you to test with the RC Oscillator until you get it up and running, but can you share the datasheet on the LFXTAL you are using, and specify what capacitors that are connected to it, and how they are connected?

It should look something like the XTAL inside the rectangle saying "optional" here:
https://infocenter.nordicsemi.com/topic/ps_nrf52840/ref_circuitry.html?cp=4_0_0_6_2_0#concept_hqh_j22_fq