Unpredictable behavior with Segger Embedded Studio with SDK17.02

[Manjunath S]

Hi All,

I am new to this community. Apologies if this is getting posted in the wrong part of the community.

I am using nRF52840 as a bare-metal with SDK17.02 along with Segger Embedded Studio for ARM v5.20a for development.

I am trying to create a sample timer using app_timer and trying to capture the timeout after set tickcount.

below are the things done

Creating timer

APP_TIMER_DEF(m_conn_int_timer_id);
uint32_t TimeoutValue = 0;

Initializing and starting the timer

nRet = app_timer_create(&m_conn_int_timer_id, APP_TIMER_MODE_REPEATED, connection_interval_timeout_handler);
nRet = app_timer_start(m_conn_int_timer_id, APP_TIMER_TICKS(1000), NULL);

Timer handler

static void connection_interval_timeout_handler(void * p_context)
{
  UNUSED_PARAMETER(p_context);
  TimeoutValue++;
}

after starting the timer I enter a while loop and intend to break after TimeoutValue >10 with below logic

while(1)
{
    if(TimeoutValue >= 10)  break;
}
app_timer_stop(m_conn_int_timer_id);

Now refer to the attached image. I use J-link to debug and flash. While debugging the loop doesn't break, in fact the TimeoutValue keeps increasing 11,12,13..... and so on.

And after some point I enter NRF_BREAKPOINT_COND; and cannot continue further.

If I flash and run the program it neither crashes nor breaks the loop.

I would like to know what could be going wrong here. I don't know what to suspect SES studio or nrf or j-link.

Thank you.

Incase the above image size is reduced,

the loop where I hit the breakpoints

The value at the time of hitting breakpoint 

[Vidar Berg]

Hello,

The 'TimeoutValue' variable should be defined with the 'volatile' keyword inform GCC that this variable may change outside the scope of the current function (in this case, from the app timer interrupt).

Notice how 'r3' is never reloaded with the updated TimeoutValue from RAM in the dissamembly view on the left.

Best regards,

Vidar

[Manjunath S]

Hi,

Thanks for the reply. 

I will check that and update you.

And also I checked the optimization level. It was set to Optimize to Size.

After I changed it to None, it seems to work fine.

What is the ideal optimization level that needs to be used?

[Vidar Berg]

Hi,

No problem. Yes, the SES build "Release" configuration sets the code optimization to "Optimize for size" by default, while the "Debug" configuration has it set to None. Debugging is generally easier with code optimization turned off, but it typically results in more memory usage and  cpu cycles for doing the same task.