gh-raspberrypi/pico-sdk

Watch

Fork 0

aon_timer_is_running() is true on boot in SDK 2.3.1! Previously the timer would have to be started #3180

New issue

Open

opened 2026-09-05 03:17:44 -05:00 by jondurrant · 10 comments

jondurrant commented

2026-09-05 03:17:44 -05:00

(Migrated from github.com)

Test case:

int main( void )
{
stdio_init_all();
sleep_ms(2000);

if (aon_timer_is_running())
	printf("AON Timer is running\n");

...
}

Use Case:
I check the aon_timer to see if the SNTP has sync-ed time to the Pico 2 W. The can pull calendar and time stamps from aon.

Pico SDK 2.3.1 on Pico 2 W On boot the aon_timer_is_running() is reported as started, yet does not have a "current" calendar date set. Previous versions of the SDK did not have the aon timer running at boot. Test case: int main( void ) { stdio_init_all(); sleep_ms(2000); if (aon_timer_is_running()) printf("AON Timer is running\n"); ... } Use Case: I check the aon_timer to see if the SNTP has sync-ed time to the Pico 2 W. The can pull calendar and time stamps from aon.

will-v-pi commented

2026-09-05 10:08:50 -05:00

(Migrated from github.com)

Can you clarify what you mean by “On boot”? The Always On timer continues running over typical chip resets (e.g. resets from picotool or OpenOCD, see 7.3 in the datasheet for more details), so this could be expected behaviour.

Additionally, nothing should have changed in this area in 2.3.1, so could you double check you can’t reproduce the issue with 2.3.0 or 2.2.0?

Can you clarify what you mean by “On boot”? The Always On timer continues running over typical chip resets (e.g. resets from `picotool` or `OpenOCD`, see 7.3 in the datasheet for more details), so this could be expected behaviour. Additionally, nothing should have changed in this area in 2.3.1, so could you double check you can’t reproduce the issue with 2.3.0 or 2.2.0?

jondurrant commented

2026-09-05 10:20:21 -05:00

(Migrated from github.com)

By on boot i mean on first run of main function.

Confirmed on Pico SDK 2.3.0 that
aon_timer_is_running()==false on entry into main. On 2.3.1 aon_timer_is_running()==true.

You suggest that the timer may be continuing to run after a software load via picotool or swd. If that was the case then the aon timer would retain count of current date in seconds. In fact its return near zero count, suggesting it has been reset and started in bootloader code prior to main being started.

It is possible something very strange has happened in my environment, but I honestly cant see what.

By on boot i mean on first run of main function. Confirmed on Pico SDK 2.3.0 that aon_timer_is_running()==false on entry into main. On 2.3.1 aon_timer_is_running()==true. You suggest that the timer may be continuing to run after a software load via picotool or swd. If that was the case then the aon timer would retain count of current date in seconds. In fact its return near zero count, suggesting it has been reset and started in bootloader code prior to main being started. It is possible something very strange has happened in my environment, but I honestly cant see what.

will-v-pi commented

2026-09-05 11:29:36 -05:00

(Migrated from github.com)

Can you provide minimal example program code that shows this behaviour? I can’t reproduce this using the code you included, when I run that it is always false.

Could you also confirm that you’re seeing this issue on a power-on boot?

Can you provide minimal example program code that shows this behaviour? I can’t reproduce this using the code you included, when I run that it is always false. Could you also confirm that you’re seeing this issue on a power-on boot?

jondurrant commented

2026-09-05 11:53:36 -05:00

(Migrated from github.com)

I will do that and update here.

Thanks for screening.

I will do that and update here. Thanks for screening.

jondurrant commented

2026-09-06 01:16:15 -05:00

(Migrated from github.com)

Further testing shows that this is state of AON carrying over from the prior build. That SWD load and soft resets are not stopping the timer. Apologies for reporting.

I suggest it is worth making it clear that the AON timer survives flashing and other resets in the documentation somewhere. Unless you are expecting that behaviour, the best advice is to always stop the timer at the beginning of main.

Learnt something new about the Pico 2 today, so thanks for that.

Further testing shows that this is state of AON carrying over from the prior build. That SWD load and soft resets are not stopping the timer. Apologies for reporting. I suggest it is worth making it clear that the AON timer survives flashing and other resets in the documentation somewhere. Unless you are expecting that behaviour, the best advice is to always stop the timer at the beginning of main. Learnt something new about the Pico 2 today, so thanks for that.

jondurrant commented

2026-09-06 01:54:50 -05:00

(Migrated from github.com)

Plus additional side effect of low_power module. Going into a lower power dormant mode turns on the aon timer if it wasn't previously running, and it continues to run on wake-up. Understandable, but also an undocumented side effect of low_power_dormant_for_ms.

will-v-pi commented

2026-09-07 06:33:25 -05:00

(Migrated from github.com)

@jondurrant I've raised a docs fix in #3187 - does that resolve this issue for you?

lurch commented

2026-09-07 06:47:15 -05:00

(Migrated from github.com)

@jondurrant Just asking out of curiosity: Based on your new understanding, do you know why you were claiming that this was a change in behaviour between SDK 2.3.0 and SDK 2.3.1 ?

jondurrant commented

2026-09-07 06:58:34 -05:00

(Migrated from github.com)

Hi,

I was seeing the 2.3.0 to 2.3.1 as issue due to order of testing and using
SWD rather than hard power reset. Plus adding complexity of some low power
stability fixes requiring work around between 2.3.0 and 2.3.1 which ment I
wasnt testing exactly the same code base.

Jon

On Mon, 7 Sept 2026, 12:47 Andrew Scheller, @.***>
wrote:

lurch left a comment (raspberrypi/pico-sdk#3180)
https://github.com/raspberrypi/pico-sdk/issues/3180#issuecomment-5570154235

@jondurrant https://github.com/jondurrant Just asking out of curiosity:
Based on your new understanding, do you know why you were claiming that
this was a change in behaviour between SDK 2.3.0 and SDK 2.3.1 ?

—
Reply to this email directly, view it on GitHub
https://github.com/raspberrypi/pico-sdk/issues/3180?email_source=notifications&email_token=AOWFSB22KCSJ6PQ73AZ6ZAD5N2N5TA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNJXGAYTKNBSGM22M4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-5570154235,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AOWFSBY27BIHRRN4I3TO4Z35N2N5TAVCNFSNUABFKJSXA33TNF2G64TZHMZTGMJTHAYDOMRTHNEXG43VMU5TKMZVGY3DKNZTGM3KC5QC
.
You are receiving this because you were mentioned.Message ID:
@.***>

Hi, I was seeing the 2.3.0 to 2.3.1 as issue due to order of testing and using SWD rather than hard power reset. Plus adding complexity of some low power stability fixes requiring work around between 2.3.0 and 2.3.1 which ment I wasnt testing exactly the same code base. Jon On Mon, 7 Sept 2026, 12:47 Andrew Scheller, ***@***.***> wrote: > *lurch* left a comment (raspberrypi/pico-sdk#3180) > <https://github.com/raspberrypi/pico-sdk/issues/3180#issuecomment-5570154235> > > @jondurrant <https://github.com/jondurrant> Just asking out of curiosity: > Based on your new understanding, do you know why you were claiming that > this was a change in behaviour between SDK 2.3.0 and SDK 2.3.1 ? > > — > Reply to this email directly, view it on GitHub > <https://github.com/raspberrypi/pico-sdk/issues/3180?email_source=notifications&email_token=AOWFSB22KCSJ6PQ73AZ6ZAD5N2N5TA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNJXGAYTKNBSGM22M4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-5570154235>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AOWFSBY27BIHRRN4I3TO4Z35N2N5TAVCNFSNUABFKJSXA33TNF2G64TZHMZTGMJTHAYDOMRTHNEXG43VMU5TKMZVGY3DKNZTGM3KC5QC> > . > You are receiving this because you were mentioned.Message ID: > ***@***.***> >

👍 1

jondurrant commented

2026-09-07 06:58:59 -05:00

(Migrated from github.com)

Yes thank you for doing that.

Jon

On Mon, 7 Sept 2026, 12:33 will-v-pi, @.***> wrote:

will-v-pi left a comment (raspberrypi/pico-sdk#3180)
https://github.com/raspberrypi/pico-sdk/issues/3180#issuecomment-5570000629

@jondurrant https://github.com/jondurrant I've raised a docs fix in
#3187 https://github.com/raspberrypi/pico-sdk/pull/3187 - does that
resolve this issue for you?

—
Reply to this email directly, view it on GitHub
https://github.com/raspberrypi/pico-sdk/issues/3180?email_source=notifications&email_token=AOWFSB4PZBYHJIDAX75W27T5N2MJZA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNJXGAYDAMBWGI42M4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-5570000629,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AOWFSB5BJ4XQZXJWAV3NFLL5N2MJZAVCNFSNUABFKJSXA33TNF2G64TZHMZTGMJTHAYDOMRTHNEXG43VMU5TKMZVGY3DKNZTGM3KC5QC
.
You are receiving this because you were mentioned.Message ID:
@.***>

Yes thank you for doing that. Jon On Mon, 7 Sept 2026, 12:33 will-v-pi, ***@***.***> wrote: > *will-v-pi* left a comment (raspberrypi/pico-sdk#3180) > <https://github.com/raspberrypi/pico-sdk/issues/3180#issuecomment-5570000629> > > @jondurrant <https://github.com/jondurrant> I've raised a docs fix in > #3187 <https://github.com/raspberrypi/pico-sdk/pull/3187> - does that > resolve this issue for you? > > — > Reply to this email directly, view it on GitHub > <https://github.com/raspberrypi/pico-sdk/issues/3180?email_source=notifications&email_token=AOWFSB4PZBYHJIDAX75W27T5N2MJZA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNJXGAYDAMBWGI42M4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-5570000629>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/AOWFSB5BJ4XQZXJWAV3NFLL5N2MJZAVCNFSNUABFKJSXA33TNF2G64TZHMZTGMJTHAYDOMRTHNEXG43VMU5TKMZVGY3DKNZTGM3KC5QC> > . > You are receiving this because you were mentioned.Message ID: > ***@***.***> >