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