This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Debugging, NRF_LOG, Segger Embedded Studio Problems

I saw something in the list that might help but I have learned that if I go there I lose all the work I did to get here

I am having major problems with Segger Embedded Studio

  • NRF_LOG_x does not print either through the UART and putty OR RTT in SES [Manually set in the sdk_config.h file] since CMSIS Wizard is not present
  • The CMSIS Configuration Wizard is NOT present in my Tools.xml
  • Debug breakpoints are not hit unless it is in the main() part of main.c and when hit not in the code, only if a debug window to the left of the code
  • I can step line by line if I start and use F10/F11 from the start (do not use F5 and a break point) but never once I use F5 and a break point.

The only thing I can think of is that somehow the installation of SES got really corrupted or I am missing a major step. I have no idea how to fix.

Yet the code I have does partially run - it advertises, gets connected to, responds to service discovery, gets two characteristic descriptors enabled but then when I try and write from the client the write times out. I am not surprised that there are issues with the code as I have ported a SoftDevice only project from nRF51 and Keil.

But being unable to debug or even print to RTT (this is new for me) or via the UART and putty (the latter worked fine in the Keil project) is not helping.

Any help would be great. (Yes I have seen the debugging video and that's how I know my Tools.xml is corrupt).

Parents Reply Children
  • So I should remove all those \r\n unless I really want the extras? Does that NRF_FPRINTF_FLAG_AUTOMATIC_CR_ON_LF_ENABLED do anything or is it ignored? Should it be 0 for 'expected' behavior?

    Do I need to support FPRINTF at all? (I didnt have to in SDK 12.3.0)

    In the Keil version build the code size is larger in SDK 17. than the equivalent in SDK 12.3 so it no longer fits in the size-limited free version of Keil. The only difference in the two code bases are the sd_* calls and, of course, the board/MCU support.

  • Yes, removing these should also remove the extra new lines you're seeing in your log. The NRF_FPRINTF_FLAG_AUTOMATIC_CR_ON_LF_ENABLED is set to 1 by default, to ensure new lines are set when logging over UART. However it doesn't play along well with RTT, so it should be set to 0 if you do logging over RTT.

    No, you shouldn't need to support FPRINTF.

    Does it help to "optimize for size" when building the application in Keil? That should decrease the size as much as possible, but please note that the latest SoftDevice versions take more space than the ones available for SDK v12.3.0, so if you were close to the roof of the free version already, I'm afraid newer versions are likely to have blown through that.

    Best regards,

    Simon

  • if you were close to the roof of the free version already, I'm afraid newer versions are likely to have blown through that.

    I concur.

    I was able to use the free Keil with simple nRF51 projects - so SDK no later than v12.3.0 - but have never been able to fit any nRF52 project into the free Keil.

    Given that the free Segger Embedded Studio (SES) is fully supported by the more recent SDKs (in fact, it is the preferred option), I don't see any point in trying to use the free Keil.

  • My project was only off by 304 bytes and I wondered if the difference was the presence of FRPINTF which I don't recall being present in sdk 12.3.0. Also, I was using just SoftDevice so the difference was mainly between s130 and s140. Clearly s140 is going to be larger under the hood as there are more requirements in the later version of the BT spec.

    That being said there were behaviors I could not understand when it came to program size. I have these hunks of code which can be conditionally removed by un-defining certain constants. As I removed them the code became smaller until I removed one that really removed a big chunk of C-code and the size went from 33K to 38K (bigger than all code included) and then when I removed everything that I didn't need it went down to 32.4K including the one that caused the big jump when removed individually. There is really strange optimization going on down there!

    In any case, I do prefer Segger as I found setting up and installing the device packages in Keil extremely confusing and difficult. There wasn't any of that in Segger.

    I should probably add that we are developing a new generic protocol for health devices so one specification is good for all devices. This protocol is in contrast to the current BT SIG profiles for health devices which requires separate code on both the client and server side. Having something which is generic usually comes at a price - code size is bigger and it is more complex. Clearly we are trying to minimize that cost. Would like to see a pulse ox or bp cuff or what ever using this protocol competes with that using the BT SIG profiles. On the client side this protocol is an easy winner - one set of code for ALL health devices, now and in the future. And the client code is smaller than the equivalent BT SIG client code needed for a single device - at least on Android.

  • When I set the following 

    #ifndef NRF_FPRINTF_ENABLED
    #define NRF_FPRINTF_ENABLED 0
    #endif

    in the SDK_config.h file I get a list of errors when I try to build (Segger) that all look like this:

    E:\projects\utech\nRF5_SDK_17.0.2_d674dde\components\libraries\log\src/nrf_log_str_formatter.c:124: undefined reference to `nrf_fprintf'

    When looking at the source code for the file nrf_fprintf_format.c I see that all the code is grayed out due to the line #if NRF_MODULE_ENABLED(NRF_FPRINTF) at the beginning of the file which is expected. However, when I look at the file nrf_fprintf.c the source coide is NOT grayed out after the line #if NRF_MODULE_ENABLED(NRF_FPRINTF) which is not expected. This is, of course, why I am getting the build errors.

    Why is that happening? I assume that if I remove the two files from the build everything would be okay. But there must be something that is re-defining NRF_FPRINTF_ENABLED somewhere. So at the moment I have to define NRF_FPRINTF_ENABLED in the SDK_config.h file. DO I need to do something else to remove that module or is it, in fact, needed by NRF_LOG?

    I looked into some more source modules and it turns out that you have to have FPRINTF enabled if you use NRF_LOG, I see this in the source code of the file nrf_log_str_formatter.c

    static void prefix_process(nrf_log_str_formatter_entry_params_t * p_params,
                               nrf_fprintf_ctx_t * p_ctx)
    {
        if (p_params->dropped)
        {
            nrf_fprintf(p_ctx,
                        "%sLogs dropped (%d)%s\r\n",
                        NRF_LOG_COLOR_CODE_RED,
                        p_params->dropped,
                        NRF_LOG_COLOR_CODE_DEFAULT);
        }

    Should probably add both define checks at the beginning of the file. As far as I can tell its only the string formatter of NRF LOG that requires fprintf, but then again, other files call these functions that require fprintf of the string formatter.

    Long story short, NRF_LOG requires NRF_FPRINTF - they need to be enabled/disabled together.

Related