LOG_DBG causes system to stop working properly

RE: LOG_DBG causes system to stop working properly

zazas321 — Wed, 20 Dec 2023 09:56:12 GMT

Now it is finally clear to me. Thanks!

RE: LOG_DBG causes system to stop working properly

Håkon Alseth — Wed, 20 Dec 2023 08:58:40 GMT

Hi,

[quote user="zazas321"]

Apologize for asking many silly questions, bare with me a few more moments!

If the variables are stored in stack and I am trying to print them in the scope of the variable it should work without any issues since the variables are not cleared out of stack.

[/quote]

Consider this pseudo code:

int *ptr;

void pin_interrupt_function()
{
    printk("%d", *ptr);
}

int some_function()
{
    int a = 5;
    ptr = &a;
    return 0;
}

int main()
{
    some_function();
    rest_of_setup();
    ...
}

"a" is out of scope once the pin_interrupt_function is called, thus the variable ptr is pointing to is no longer valid.

What I stated previously, is that in some cases, you will still see "5" being printed, as no other function has exceeded the previous stack usage, ie. the value is not yet overwritten in RAM.

But, the above scenario is still undefined behavior.

Kind regards,

Håkon

RE: LOG_DBG causes system to stop working properly

zazas321 — Tue, 19 Dec 2023 14:37:51 GMT

Apologize for asking many silly questions, bare with me a few more moments!

If the variables are stored in stack and I am trying to print them in the scope of the variable it should work without any issues since the variables are not cleared out of stack.

Are you suggesting that whenever I use LOG, I should only use them with GLOBAL scope variables and never variables that are placed in stack? For example, if I do the following:

void my_function(){
	int a; //this is a variable that is created on the stack 
	a = 5;
	LOG_DBG("Printing variable a = %i",a);
}

Are you suggesting that the above is not correct since the variable is placed on the stack?

RE: LOG_DBG causes system to stop working properly

Håkon Alseth — Tue, 19 Dec 2023 13:18:32 GMT

Hi,

No, it worked by chance with printk. Once the variables are declared static, it also works with log.

The issue is as described above. You must have the variables in question in global RAM, and not in the stack.

Kind regards,

Håkon

RE: LOG_DBG causes system to stop working properly

zazas321 — Tue, 19 Dec 2023 13:11:17 GMT

[quote userid="2115" url="~/f/nordic-q-a/106583/log_dbg-causes-system-to-stop-working-properly/461065"]It does not matter if you use LOG or printk[/quote]

It does though because it works with printk and does not with LOG.

So can we consider that this is a bug in the sensor_trigger_set function?

RE: LOG_DBG causes system to stop working properly

Håkon Alseth — Tue, 19 Dec 2023 13:08:29 GMT

It does not matter if you use LOG or printk. The problem is that the memory provided via function "sensor_trigger_set" was stacked auto-variable, ie. short-lived memory. The function assumes that memory given is global RAM, meaning; it must be global or static declared.

Kind regards,

Håkon

RE: LOG_DBG causes system to stop working properly

zazas321 — Tue, 19 Dec 2023 13:00:15 GMT

[quote userid="2115" url="~/f/nordic-q-a/106583/log_dbg-causes-system-to-stop-working-properly/461059"]When LOG subsys is enabled, it will use more stack depth, ie. more RAM when a log-print is called. Once a variable goes out-of-scope, it is not usually overwritten until something else in your system stacks more memory.[/quote]

I cant fully understand what you mean by that. From what you said, I understood that LOG is not recommended for use and I should stick with printk as it is simply much more reliable and simple and it will help me avoid simillar problems in the future. However, in the devzone course it has been recommended to use LOG system to log the information but now after having this issue I am not too sure about that.

RE: LOG_DBG causes system to stop working properly

Håkon Alseth — Tue, 19 Dec 2023 12:57:12 GMT

When LOG subsys is enabled, it will use more stack depth, ie. more RAM when a log-print is called. Once a variable goes out-of-scope, it is not usually overwritten until something else in your system stacks more memory.

Kind regards,

Håkon

RE: LOG_DBG causes system to stop working properly

zazas321 — Tue, 19 Dec 2023 12:51:55 GMT

Ok I understand but what does LOG prints have to do with it?. Why it works with printk and not with LOG_DBG. From what I understand, LOG statements are pretty much the same as printk except they add a bit more additional information to the prints.

RE: LOG_DBG causes system to stop working properly

Håkon Alseth — Tue, 19 Dec 2023 12:49:58 GMT

Glad to hear that this worked on your end as well.

When you set a trigger using sensor_trigger_set(), the input variable is used in different contexts, meaning that you get the same address (ie. variable) returned in your callback "trigger_handler". Since this was stacked memory, it is effectively out-of-scope once you returned from your main-function.

Kind regards,

Håkon

RE: LOG_DBG causes system to stop working properly

zazas321 — Tue, 19 Dec 2023 12:44:15 GMT

Not a problem at all. I highly appreciate you working on this.

I have declared trig_motion and trig_stationary structs as static as shown below:

void main(void)
{

	if (!device_is_ready(adxl1362_sens))
	{
		LOG_ERR("sensor: device %s not ready", adxl1362_sens->name);
		return;
	}

	if (IS_ENABLED(CONFIG_ADXL362_TRIGGER))
	{
		LOG_DBG("Configuring triggers");
		static struct sensor_trigger trig_motion = {
			.chan = SENSOR_CHAN_ACCEL_XYZ,
			.type = SENSOR_TRIG_MOTION,
		};
		if (sensor_trigger_set(adxl1362_sens, &trig_motion, trigger_handler))
		{
			LOG_ERR("SENSOR_TRIG_MOTION set error");
		}

		static struct sensor_trigger trig_stationary = {
			.chan = SENSOR_CHAN_ACCEL_XYZ,
			.type = SENSOR_TRIG_STATIONARY,
		};
		if (sensor_trigger_set(adxl1362_sens, &trig_stationary, trigger_handler))
		{
			LOG_ERR("SENSOR_TRIG_STATIONARY set error");
		}
		ext_sensors_accelerometer_threshold_set(5.0, true);
		ext_sensors_accelerometer_threshold_set(0.5, false);
	}
}

It seems to really fix the issue as I am able to get some proper readings:

ø*** Booting nRF Connect SDK v2.5.0 ***
[00:00:00.270,507] [1B][0m<dbg> main: main: Configuring triggers[1B][0m
[00:00:00.271,270] [1B][0m<dbg> main: ext_sensors_accelerometer_threshold_set: threshold value to be set : 510[1B][0m
[00:00:00.271,362] [1B][0m<dbg> main: ext_sensors_accelerometer_threshold_set: threshold value to be set : 51[1B][0m
[00:00:00.273,925] [1B][0m<dbg> main: trigger_handler: x: 0.1, y: -0.2, z: -10.7 (m/s^2)[1B][0m
[00:00:00.273,956] [1B][0m<dbg> main: trigger_handler: Inactivity detected[1B][0m
[00:00:02.036,041] [1B][0m<dbg> main: trigger_handler: x: 0.5, y: -1.0, z: -5.2 (m/s^2)[1B][0m
[00:00:02.036,071] [1B][0m<dbg> main: trigger_handler: Activity detected[1B][0m
[00:00:02.038,970] [1B][0m<dbg> main: trigger_handler: x: 0.1, y: -0.8, z: -5.0 (m/s^2)[1B][0m
[00:00:02.039,001] [1B][0m<dbg> main: trigger_handler: Inactivity detected[1B][0m
[00:00:02.095,092] [1B][0m<dbg> main: trigger_handler: x: -2.3, y: 14.0, z: -3.8 (m/s^2)[1B][0m
[00:00:02.095,123] [1B][0m<dbg> main: trigger_handler: Activity detected[1B][0m
[00:00:02.118,652] [1B][0m<dbg> main: trigger_handler: x: -0.3, y: -1.6, z: -10.2 (m/s^2)[1B][0m
[00:00:02.118,682] [1B][0m<dbg> main: trigger_handler: Inactivity detected[1B][0m
[00:00:03.364,013] [1B][0m<dbg> main: trigger_handler: x: 2.6, y: -1.3, z: -5.2 (m/s^2)[1B][0m
[00:00:03.364,044] [1B][0m<dbg> main: trigger_handler: Activity detected[1B][0m
[00:00:03.387,573] [1B][0m<dbg> main: trigger_handler: x: 2.5, y: -1.6, z: -6.6 (m/s^2)[1B][0m
[00:00:03.387,603] [1B][0m<dbg> main: trigger_handler: Inactivity detected[1B][0m
[00:00:03.452,575] [1B][0m<dbg> main: trigger_handler: x: 2.2, y: -0.8, z: -1.5 (m/s^2)[1B][0m
[00:00:03.452,575] [1B][0m<dbg> main: trigger_handler: Activity detected[1B][0m
[00:00:03.526,153] [1B][0m<dbg> main: trigger_handler: x: 0.2, y: -1.0, z: -9.9 (m/s^2)[1B][0m
[00:00:03.526,184] [1B][0m<dbg> main: trigger_handler: Inactivity detected[1B][0m
[00:00:05.785,705] [1B][0m<dbg> main: trigger_handler: x: -0.7, y: 0.6, z: -4.6 (m/s^2)[1B][0m
[00:00:05.785,736] [1B][0m<dbg> main: trigger_handler: Activity detected[1B][0m
[00:00:05.850,555] [1B][0m<dbg> main: trigger_handler: x: 0.7, y: -0.3, z: -9.9 (m/s^2)[1B][0m
[00:00:05.850,585] [1B][0m<dbg> main: trigger_handler: Inactivity detected[1B][0m
[00:00:08.783,172] [1B][0m<dbg> main: trigger_handler: x: -6.3, y: 6.5, z: -9.8 (m/s^2)[1B][0m
[00:00:08.783,203] [1B][0m<dbg> main: trigger_handler: Activity detected[1B][0m
[00:00:08.815,582] [1B][0m<dbg> main: trigger_handler: x: -2.0, y: -0.6, z: -11.9 (m/s^2)[1B][0m
[00:00:08.815,582] [1B][0m<dbg> main: trigger_handler: Inactivity detected[1B][0m
[00:00:08.874,603] [1B][0m<dbg> main: trigger_handler: x: -1.7, y: 0.1, z: -6.6 (m/s^2)[1B][0m
[00:00:08.874,603] [1B][0m<dbg> main: trigger_handler: Activity detected[1B][0m
[00:00:08.916,015] [1B][0m<dbg> main: trigger_handler: x: -1.5, y: -1.9, z: -2.8 (m/s^2)[1B][0m
[00:00:08.916,046] [1B][0m<dbg> main: trigger_handler: Inactivity detected[1B][0m
[00:00:08.930,816] [1B][0m<dbg> main: trigger_handler: x: 0.0, y: -3.8, z: -8.2 (m/s^2)[1B][0m
[00:00:08.930,816] [1B][0m<dbg> main: trigger_handler: Activity detected[1B][0m
[00:00:08.983,856] [1B][0m<dbg> main: trigger_handler: x: -0.5, y: 0.2, z: -9.2 (m/s^2)[1B][0m
[00:00:08.983,856] [1B][0m<dbg> main: trigger_handler: Inactivity detected[1B][0m
[00:00:24.189,758] [1B][0m<dbg> main: trigger_handler: x: -13.8, y: 10.3, z: -9.4 (m/s^2)[1B][0m
[00:00:24.189,788] [1B][0m<dbg> main: trigger_handler: Activity detected[1B][0m
[00:00:24.216,308] [1B][0m<dbg> main: trigger_handler: x: -0.1, y: -1.9, z: -10.8 (m/s^2)[1B][0m
[00:00:24.216,308] [1B][0m<dbg> main: trigger_handler: Inactivity detected[1B][0m

Could you please help me understand in a simple terms what exactly caused this weird behaviour? It is really strange to me that such a simple change can cause such a big issue

RE: LOG_DBG causes system to stop working properly

Håkon Alseth — Tue, 19 Dec 2023 11:32:01 GMT

Hi,

Sorry it took a bit of time.

Could you try declaring "trig_motion" and "trig_stationary" as static or move them to global scope and see if this fixes the issue on your side as well?

Looks like these are stored in the sensor API, and cannot be a stacked variable.

Kind regards

Håkon

RE: LOG_DBG causes system to stop working properly

Håkon Alseth — Mon, 18 Dec 2023 13:51:57 GMT

Hi,

Thank you for your patience in this matter.

I have been looking into what this can be, even to the extent where I have disabled adxl372 (+ set its csn pin inactive), but I have not been able to find the root-cause of this behavior when logging is enabled.

Given that this is the parameter input to the function:

(gdb) print *drv_data.inact_trigger
$4 = {type = 60672, chan = 57344}

There is clearly something occurring in the driver side of the adxl362 implementation.

I will continue to dig deeper.

Kind regards,

Håkon

RE: LOG_DBG causes system to stop working properly

zazas321 — Mon, 18 Dec 2023 05:23:12 GMT

Hello. I am glad that you are able to reproduce the issue. Have you been able to look into this more?

RE: LOG_DBG causes system to stop working properly

Håkon Alseth — Wed, 13 Dec 2023 14:57:54 GMT

Hi,

I am able to reproduce the issue. First thought was the floats in the log debug prints, but that should not explain the strange events that is printed.

I am digging deeper to see what can have caused this, and will get back tomorrow with more relevant debug info.

Kind regards,

Håkon