Problem with repeating timer in SDK2.1.0

[richard9999999999]

Hello,
I am experiencing a problem with repeating timer in SDK 2.1.0 (I haven't seen it in SDK 1.x.x before). The problem seems happen only when timer callback function is "light" (I mean doesn't contain too much of processing):

repeating_timer_t my_sampling_timer;

bool my_timer_callback(repeating_timer_t *rt)
{
	//volatile int tmp = 0;
	//for(int i=0; i <10000; i++)
	//{
	//	tmp++;
	//}
	
	return true;
}

int main()
{	
	alarm_pool_t *pool = alarm_pool_create(2, 1);	
	alarm_pool_add_repeating_timer_ms(pool, -20, my_timer_callback, NULL, &my_sampling_timer);

	while(1)
	{
		printf("looping\n");
	}
}

If the code is as above, the callback is called only few times. If I uncomment commented part in the callback (to make functionality to spend some more time in callback), the callback is called still during main looping (as desired).
The problem happens in the RELEASE build only.
I use GCC 10.3.1 (not sure if related, probably not)

[lurch]

Possibly similar to #737 ?

[richard9999999999]

Possibly similar to #737 ?

I hope no since that problem is almost 3 years old :-) Plus that issue is marked as "completed" in 2.0.0 (well I see the problem in RELEASE configuration only: is there a possibility that fix of #737 was tested in DEBUG config only? ..just an idea..)
The problem seems to be easily reproducible for me using the simple code above. Please, could anybody else try that?

[kilograham]

i did try it, and it worked fine. how are you telling if it is firing if empty?

[kilograham]

note: it certainly might be timing dependent so exact code/compiler might be pertinent

[richard9999999999]

i did try it, and it worked fine. how are you telling if it is firing if empty?

I put breakpoint on line
return true;
in above code. It is minimalictics version to get the problem, originally I had a bit more complex timer callback code which looks cca as follows:

bool my_timer_callback(repeating_timer_t *rt)
{
	if(task_enabled)
	{
		runTask();
	}
	return true; 	//keep repeating
}

And I've found that as soon as I set task_enabled to false, task is not run even it it is enabled later. I spent some time trying to find the root of the problem (including studying generated disassembly code) and I found that really it seems that timer is stopped to be called after the time spent in the last timer callback is "too short". E.g following callback code:

bool my_timer_callback(repeating_timer_t *rt)
{
	if(task_enabled)
	{
		runTask();
	}
	else
	{
		sleep_ms(1);
	}
	return true; 	//keep repeating
}

works as expected.

[richard9999999999]

As I wrote, I am getting the problem in RELEASE build only so you will need to set symbols (debug info) to be generated also in RELEASE build to be able to put the breakpoint there..

[kilograham]

As I wrote, I am getting the problem in RELEASE build only so you will need to set symbols (debug info) to be generated also in RELEASE build to be able to put the breakpoint there..

What you didn't write, but have now, is that you were checking with a breakpoint, which is exactly why I asked.

see also raspberrypi/pico-feedback#428

[kilograham]

I tried with a counter incremented in the timer callback, and printed out, in the main loop, and that worked fine

[richard9999999999]

You are right, more complex example is needed to reproduce the problem (and not usage of breakpoint to detection of callback firing). I tweaked my problem more and found that the problem is related to usage of set_sys_clock_khz. Here is the code to reproduce:

#include "pico/stdlib.h"
#include "hardware/clocks.h"

//#define PICO_DEFAULT_LED_PIN 0

repeating_timer_t my_sampling_timer;
bool led_state = true;
bool task_enabled = true;

volatile int tmp = 0;

bool my_timer_callback(repeating_timer_t *rt)
{
	if(task_enabled)
	{
		gpio_put(PICO_DEFAULT_LED_PIN, led_state);
		led_state = !led_state;	
		for(int i=0; i <10000; i++)
		{
			tmp++;
		}		
	}
	else
	{
		
		//for(int i=0; i <1000; i++)
		//{
		//	tmp++;
		//}		
	}

	return true;
}

int main()
{
	set_sys_clock_khz(160 * 1000, true);

	gpio_init(PICO_DEFAULT_LED_PIN);
	gpio_set_dir(PICO_DEFAULT_LED_PIN, GPIO_OUT);

	alarm_pool_t *pool = alarm_pool_create(2, 1);	
	alarm_pool_add_repeating_timer_ms(pool, -20, my_timer_callback, NULL, &my_sampling_timer);

	while (true)
	{		
		sleep_ms(1000);
		task_enabled = false;
		sleep_ms(1000);
		task_enabled = true;	
	}
}

I need to use Pico2 board to reproduce. In fact I have Pico2w only which doesn't have LED so I ended up by redefining of PICO_DEFAULT_LED_PIN to 0 and checking the "blinking" with scope.
..Yes, I am overclocking the pico2 to 160MHz to get the problem however I don't think the problem is related to physical limits of chip, I would vote for a software problem rather (but I may be wrong of course). I tried various values and 160 seems to be the lowest one to get the problem reproduced.
What is strange that when you uncomment that dummy delay code in else branch in timer callback, the problem is gone..
I've tried that on two pico2W boards with the same results.
RELEASE build configuration..

[peterharperuk]

Running fine for me on a Pico 2. By release build, do you mean you are just running cmake with no arguments?
Does the problem occur after resetting the device? i.e. after a clean reset, not using the debugger at all.

[peterharperuk]

I seem to be able to reproduce this if I load the program with openocd or drop the uf2 onto the pico from my Pi 5.
Hmm, can reproduce it with gdb now.

[richard9999999999]

By release build, do you mean you are just running cmake with no arguments

I mean cmake build type "Release" so compile with optimization for speed, however I am not sure if only this optimization mode is relevant here, potentially also the debug mode can have a specific preprocessor macro value defined (e.g. DEBUG. or _DEBUG or something like that, I didn't check) and preprocessor usually generates (can generate) slightly different C code for RELEASE vs DEBUG configuration)

[richard9999999999]

Does the problem occur after resetting the device? i.e. after a clean reset, not using the debugger at all.

I am able to reproduce the problem both using debugger and also after just loading the binary via USB

[peterharperuk]

Okay. I can reproduce it with your code. Investigating...