Some error occurred, i want to see some information in debug mode , but why can't i "step" to "app_error _save_and_stop" function?

[Jerryxu]

Hi,

In my main function, I just call a acceleration_read function to get data from the accelerometer sensor   and   call a NRF_LOG_INFO function.

But there're something wrong with the logs. Details are as below:

the code in the cycle in main function:

for (;;)
    {
		
			
			icm_x_acc[0]=ICM_Get_Accelerometer(ICM20602_ACCEL_XOUT_H);//0x43
	icm_x_acc[1]=ICM_Get_Accelerometer(ICM20602_ACCEL_XOUT_L);
	NRF_LOG_INFO("ACCEL_XOUT_H is£º%x\n",icm_x_acc[0]);
  NRF_LOG_INFO("ACCEL_XOUT_L is£º%x\n",icm_x_acc[1]);
       
			nrf_delay_ms(5);
			idle_state_handle();
    }

the log sequence: (at the beginning, there's only ACCEL_XOUT_L  existing, after a while, "[1;31mLogs dropped (1)[0m " occurred. I have no idea why this happened and ACCEL_XOUT_H was not there)

<info> app: ACCEL_XOUT_L is：0

<info> app: ACCEL_XOUT_L is：0

<info> app: ACCEL_XOUT_L is：0

<info> app: ACCEL_XOUT_L is：0

<info> app: ACCEL_XOUT_L is：0

<info> app: ACCEL_XOUT_L is：0

<info> app: ACCEL_XOUT_L is：0

<info> app: ACCEL_XOUT_L is：0

<info> app: ACCEL_XOUT_L is：0

<info> app: ACCEL_XOUT_L is：0

<info> app: ACCEL_XOUT_L is：0

<info> app: ACCEL_XOUT_L is：0

<info> app: ACCEL_XOUT_L is：0

<info> app: ACCEL_XOUT_L is：0

<info> app: ACCEL_XOUT_L is：0

<info> app: ACCEL_XOUT_L is：0

<info> app: ACCEL_XOUT_L is：0

<info> app: ACCEL_XOUT_L is：0

Logs dropped (1)
<info> app: ACCEL_XOUT_L is：0

Logs dropped (1)
<info> app: ACCEL_XOUT_L is：0

Logs dropped (1)
<info> app: ACCEL_XOUT_L is：0

Logs dropped (1)
<info> app: ACCEL_XOUT_L is：0

Logs dropped (1)
<info> app: ACCEL_XOUT_L is：0

Logs dropped (1)
<info> app: ACCEL_XOUT_L is：0

Logs dropped (1)
<info> app: ACCEL_XOUT_L is：0

Logs dropped (1)
<info> app: ACCEL_XOUT_L is：0

Logs dropped (1)
<info> app: ACCEL_XOUT_L is：0

Logs dropped (1)
<info> app: ACCEL_XOUT_L is：0

Logs dropped (1)
<info> app: ACCEL_XOUT_L is：0

Logs dropped (1)
<info> app: ACCEL_XOUT_L is：0

Logs dropped (1)
<info> app: ACCEL_XOUT_L is：0

Logs dropped (1)
<info> app: ACCEL_XOUT_L is：0

Logs dropped (1)
<info> app: ACCEL_XOUT_L is：0

Logs dropped (1)

So, i try to use debug mode to find out error information. I set breakpoint at nrf_delay_ms and idle_state_handle, as below.

i click on "step " in debug mode when the code call the nrf_delay_ms(5),  then the code went to "app_error_weak.c" and stopped as the picture below.

I tried to click the "step" button and see the error information in "app_error_save_and_stop(id, pc, info)" , but i found that after  "step" the code didn't go to  "app_error_save_and_stop(id, pc, info)"  and keil also changed its status，

I want to why the code can't go to the "app_error_save_and_stop"function (so that i can't get the error information)??

please help me,thanks.

Jerry

[Jerryxu]

Supplement:

Jerryxu said:

i click on "step " in debug mode when the code call the nrf_delay_ms(5)

after that , the log were as the picture below:

[Karl Ylvisaker]

Hello Jerry,

Please make sure that you have DEBUG defined in your preprocessor defines, like shown in the included image.

This will write out a detailed error message and the generated error code to your log, if a non-NRF_SUCCESS error code is passed to an APP_ERROR_CHECK.

From the other pictures you share I see that you have dropped logs. How big is your logs buffer, and how often is the NRF_LOG_PROCESS function actually called?

You mention that the SoftDevice asserts when you try to use the debugger - this is correct. If you halt the CPU (like the debugger does) while the SoftDevice is enabled, it will miss its critical deadlines and assert. This is as intended, even though it makes stepping through the code infeasible while it is enabled. Since you are now debugging a non-BLE problem, you could therefore disable the SoftDevice for the time being, so that you may debug by stepping through the code.

Looking forward to resolving this issue together!

Best regards,
Karl

[Jerryxu]

Hi,Karl

Refer to what you said, i found logs buffer was too small, i made it bigger, and it worked.

But i still had a question. At the beginning, the acceleration_read function and its logs were in "timeout_handler ()" actually ,but these code in timeout_handler made the whole system abnormal. Details were here, i asked this question several days ago. Hope some advice. thanks a lot

Jerry

[Karl Ylvisaker]

Hello Jerry,

Jerryxu said:

Refer to what you said, i found logs buffer was too small, i made it bigger, and it worked.

I am happy to hear that you made the change, and that it is now working as expected, great!

Jerryxu said:

But i still had a question. At the beginning, the acceleration_read function and its logs were in "timeout_handler ()" actually ,but these code in timeout_handler made the whole system abnormal. Details were here, i asked this question several days ago.

Yes, you should keep the code happening during your interrupt handling to a minimum.
If you are using the deferred logging option then you may queue logs for processing in the timeout handler, and then process them later - in the main context. If you are not using the deferred logging option then I would not recommend that you call logging functions in your interrupt handlers, as they might disrupt your program flow (by taking to long to execute). If you are using the deferred logging option, you can process the loggings in the main context by calling NRF_LOG_PROCESS(). Please see the idle_state_handler function of the ble_peripheral examples, to see how this may be implemented for reduced power consumption.

For future reference, it is best to post new questions in new tickets, to keep the forum tidy and easy to navigate. Since the question has been raised in a separate ticket, I suggest that you keep the conversation going there.

Best regards,
Karl