UNKNOWN FAULT at 0x0001C64B after adding a new if condition for checking if passed string argument is null

[kc9999]

I am using LVGL for simple Eink display UI, and trying to implement a simple if condition to check if the passed string argument is null as below:

void ui_10_draw(const char *header, const char *btn1, const char *btn2)
{
clear_screen();

lv_obj_t *bg = lv_obj_create(scr);
lv_obj_set_size(bg, 200, 120);
lv_obj_set_style_border_width(bg, 3, LV_PART_MAIN | LV_STATE_DEFAULT);


lv_obj_t *label = lv_label_create(bg);
lv_obj_align(label, LV_ALIGN_CENTER, 0, 0);
lv_obj_set_style_text_font(label, &lv_font_montserrat_22, 0);
lv_label_set_text(label, header);
lv_obj_set_style_text_align(label, LV_TEXT_ALIGN_CENTER, 0);

//works fine if only check btn1 OR btn2; but pop out error when checking btn1 AND btn2 at the same time
// BTN1
if (btn1[0] != '\0') 
{
lv_obj_t *continue_btn = lv_btn_create(scr);
lv_obj_align(continue_btn, LV_ALIGN_RIGHT_MID, -10, 0);

label = lv_label_create(continue_btn);
lv_label_set_text(label, btn1);
lv_obj_center(label);
}
// BTN2

if (btn2[0] != '\0') 
{
lv_obj_t *skip_btn = lv_btn_create(scr);
lv_obj_align(skip_btn, LV_ALIGN_BOTTOM_RIGHT, -10, -20);

label = lv_label_create(skip_btn);
lv_label_set_text(label, btn2);
lv_obj_center(label);
}

}

If I only have btn1 OR btn2 checked, then there will be no error. However, if I checked both btn1 and btn2 at the same time for their nullity, then error handler will pop at program counter      0x0001C64B.

I have no clue where I can start to debug from, and my assumption is invalid PC if it branched/jumped to an invalid location due to corrupted stack/memory. But if it is really from corrupted stack/memory, then how can it be triggered from a simple if condition? 

So my questions are:
1. What are the recommended approaches to debug this?
2. If this is extra code/data overwrites memory regions, how can I solve this if I want to keep developing on this project? 

This is the current memory allocation for this project, and it is fed up quite to its limit:

Any advice is greatly appreciated! 

Thanks,

Kevin

[Vidar Berg]

Hello Kevin,

Please also include a picture of the call stack and CPU register view after the fault has occurred to see if that may provide any clues. I assume 0x0001C64B is in the softdevice. In that case, which Sofdevice version are you using?

and my assumption is invalid PC if it branched/jumped to an invalid location due to corrupted stack/memory. But if it is really from corrupted stack/memory, then how can it be triggered from a simple if condition? 

A common symptom of stack or buffer overruns is that seemingly unrelated code changes can either mask the problem or trigger it. I other words, the problem is likely not with the if statement itself.

Best regards,

Vidar

[kc9999]

Hi Vidar,

Thanks for the response. I am using Softdevice s132_nrf52_7.2.0_softdevice with nRF5 Software Development Kit v17.1.0.

Below is the content of call stack and CPU register:

Thank you,

Kevin

[Vidar Berg]

Hi Kevin,

The "id" argument passed to the error handler is supposed to correspond to one of the switch case statements, but it doesn't. Therefore, I'm not sure we can trust the PC to be correct either.

Please try to place a breakpoint at the beginning of the app_error_handler() and check if the call stack will reveal more information.

Best regards,

Vidar

[kc9999]

Hi Vidar,

Error seems to come from the fds module provided in the SDK.

Below is how I initialize fds:

/*!
 *  @brief    Initialization of flash data storage
 *
 *  @param    void
 *
 *  @returns  ret_code_t
 */
ret_code_t fds_test_init (void)
{

    ret_code_t ret = fds_register(my_fds_evt_handler);
    if (ret != NRF_SUCCESS)
    {
        return ret;

    }
    ret = fds_init();
    if (ret != NRF_SUCCESS)
    {
        return ret;
    }

    return NRF_SUCCESS;

}

And the error comes from  fds_init() with returned error code 34314 (0x860A):

There is a previous post with same situation: 
https://devzone.nordicsemi.com/f/nordic-q-a/63396/nrf8532-fds-issue-with-nrf5_sdk_16-0-0_98a08e2

Could you please help me explain why this happens?

Below is my fds configuration:

// <e> FDS_ENABLED - fds - Flash data storage module
//==========================================================
#ifndef FDS_ENABLED
#define FDS_ENABLED 1
#endif
// <h> Pages - Virtual page settings

// <i> Configure the number of virtual pages to use and their size.
//==========================================================
// <o> FDS_VIRTUAL_PAGES - Number of virtual flash pages to use.
// <i> One of the virtual pages is reserved by the system for garbage collection.
// <i> Therefore, the minimum is two virtual pages: one page to store data and one page to be used by the system for garbage collection.
// <i> The total amount of flash memory that is used by FDS amounts to @ref FDS_VIRTUAL_PAGES * @ref FDS_VIRTUAL_PAGE_SIZE * 4 bytes.

#ifndef FDS_VIRTUAL_PAGES
#define FDS_VIRTUAL_PAGES 13
#endif

// <o> FDS_VIRTUAL_PAGE_SIZE  - The size of a virtual flash page.


// <i> Expressed in number of 4-byte words.
// <i> By default, a virtual page is the same size as a physical page.
// <i> The size of a virtual page must be a multiple of the size of a physical page.
// <1024=> 1024
// <2048=> 2048

#ifndef FDS_VIRTUAL_PAGE_SIZE
#define FDS_VIRTUAL_PAGE_SIZE 1024
#endif

// <o> FDS_VIRTUAL_PAGES_RESERVED - The number of virtual flash pages that are used by other modules.
// <i> FDS module stores its data in the last pages of the flash memory.
// <i> By setting this value, you can move flash end address used by the FDS.
// <i> As a result the reserved space can be used by other modules.

#ifndef FDS_VIRTUAL_PAGES_RESERVED
#define FDS_VIRTUAL_PAGES_RESERVED 1
#endif

Even though I reduced the FDS_VIRTUAL_PAGES from 13 to 5, it is still having the same error.

Why adding a line of code will trigger FDS_ERR_NO_PAGES?

Should we use an external flash instead of relying on the fds module if it is not consistent? 

Our device is low-powered battery device so we would like to use fds module instead of regular SPI external flash to save power.

Thank you,

Kevin