best_effort_wfe_or_timeout hangs indefinitely #2469

New issue

Closed

opened 2025-05-16 15:10:03 -05:00 by writeonlymemory · 5 comments

writeonlymemory commented

2025-05-16 15:10:03 -05:00

(Migrated from github.com)

I don't exactly know why yet but I am seeing something odd with best_effort_wfe_or_timeout.

Given this program:

int main() {
  const absolute_time_t deadline = make_timeout_time_ms(1000);
  best_effort_wfe_or_timeout(deadline);
  best_effort_wfe_or_timeout(deadline);
}

The second call never returns (the first does, immediately).

If I add an alarm (even far in the future):

int main() {
  add_alarm_at(make_timeout_time_ms(5000), do_nothing, NULL, true);
  const absolute_time_t deadline = make_timeout_time_ms(1000);
  best_effort_wfe_or_timeout(deadline);
  best_effort_wfe_or_timeout(deadline);
}

The second call to best_effort_wfe_or_timeout works as expected.

I'm on a Pico 2W, using SDK 2.1.1.

I don't exactly know why yet but I am seeing something odd with `best_effort_wfe_or_timeout`. Given this program: ``` int main() { const absolute_time_t deadline = make_timeout_time_ms(1000); best_effort_wfe_or_timeout(deadline); best_effort_wfe_or_timeout(deadline); } ``` The second call never returns (the first does, immediately). If I add an alarm (even far in the future): ``` int main() { add_alarm_at(make_timeout_time_ms(5000), do_nothing, NULL, true); const absolute_time_t deadline = make_timeout_time_ms(1000); best_effort_wfe_or_timeout(deadline); best_effort_wfe_or_timeout(deadline); } ``` The second call to `best_effort_wfe_or_timeout` works as expected. I'm on a Pico 2W, using SDK 2.1.1.

kilograham commented

2025-05-16 15:39:15 -05:00

(Migrated from github.com)

can you try on the develop branch

can you try on the `develop` branch

writeonlymemory commented

2025-05-16 15:47:31 -05:00

(Migrated from github.com)

Just tried and it seems to have the same behaviour I'm afraid.

kilograham commented

2025-05-19 08:56:57 -05:00

(Migrated from github.com)

i tried this with both release and debug builds, but couldn't reproduce on GCC 13.2

@peterharperuk / @will-v-pi wanna try?

@writeonlymemory what compiler? how r u running (e.g. debugger etc.?

i tried this with both release and debug builds, but couldn't reproduce on GCC 13.2 @peterharperuk / @will-v-pi wanna try? @writeonlymemory what compiler? how r u running (e.g. debugger etc.?

writeonlymemory commented

2025-05-19 10:27:59 -05:00

(Migrated from github.com)

Thanks for looking at it.

$ arm-none-eabi-gcc --version
arm-none-eabi-gcc (15:13.2.rel1-2) 13.2.1 20231009

Great question about debugging: this jogged my memory about #1977 which I was also hitting. (I am using the debug probe and openocd to flash but not actively debugging the core - just using printf debugging.)

If I power cycle the part after flashing (and getting into this hang) it starts up correctly. So I think I'm just hitting the same oddity at startup as in #1977

I'll leave it to you to if you want to dupe this into it.

Thanks for looking at it. ``` $ arm-none-eabi-gcc --version arm-none-eabi-gcc (15:13.2.rel1-2) 13.2.1 20231009 ``` Great question about debugging: this jogged my memory about #1977 which I was also hitting. (I am using the debug probe and openocd to flash but not actively debugging the core - just using printf debugging.) If I power cycle the part after flashing (and getting into this hang) it starts up correctly. So I think I'm just hitting the same oddity at startup as in #1977 I'll leave it to you to if you want to dupe this into it.

peterharperuk commented

2025-05-30 11:20:17 -05:00

(Migrated from github.com)