gh-raspberrypi/pico-sdk
Watch
1
0
Fork
You've already forked pico-sdk
 0
Code Issues 262 Pull requests 63 Releases Activity

Hardware timer not working after reset under debugger #1152

New issue
Closed
opened 2022-12-21 19:27:47 -06:00 by l0ud · 13 comments
l0ud commented 2022-12-21 19:27:47 -06:00 (Migrated from github.com)

Hello,

During testing some examples I noticed SDK Timer functions are not working when I'm debugging my program.
It seems like they are waiting indefinitely for hw timer, which has value 0.

x/2x  0x40054024
0x40054024:	0x00000000	0x00000000

x/32x  0x40054000
0x40054000:	0x00000000	0x00000000	0x00000000	0x00000000
0x40054010:	0x00000000	0x00000000	0x00000000	0x000003e2
0x40054020:	0x00000008	0x00000000	0x00000000	0x00000007
0x40054030:	0x00000000	0x00000000	0x00000008	0x00000000
0x40054040:	0x00000000	0x54494d52	0x00000000	0x00000001
0x40054050:	0x00000000	0x00000000	0x00000000	0x00000001
0x40054060:	0x00000000	0x00000000	0x00000000	0x00000000
0x40054070:	0x00000000	0x00000000	0x00000000	0x00000000

But if I power cycle my target and then attach debugger (just attach - not resetting core or touching anything in flash) I can see that code is definitely progressing and timer is no longer stuck.

x/2x  0x40054024
0x40054024:	0x00000000	0x002b4a54

x/32x  0x40054000
0x40054000:	0x00000000	0x00000000	0x00000000	0x002b4a54
0x40054010:	0x00000000	0x00000000	0x00000000	0x002b4c8e
0x40054020:	0x00000008	0x00000000	0x002b4a54	0x00000007
0x40054030:	0x00000000	0x00000000	0x00000008	0x00000000
0x40054040:	0x00000000	0x54494d52	0x00000000	0x00000001
0x40054050:	0x00000000	0x00000000	0x00000000	0x00000001
0x40054060:	0x00000000	0x00000000	0x00000000	0x00000000
0x40054070:	0x00000000	0x00000000	0x00000000	0x00000000

if I step though the code I can see that now timer is progressing normally.
If I then reset target using debugger I can see core staring from 0x000000ee. After some initialization (I cannot track it, it's before runtime_init function) timer registers seem to be reset:

x/32x  0x40054000
0x40054000:	0x00000000	0x00000000	0x00000000	0x00000000
0x40054010:	0x00000000	0x00000000	0x00000000	0x00000000
0x40054020:	0x00000000	0x00000000	0x00000000	0x00000007
0x40054030:	0x00000000	0x00000000	0x00000000	0x00000000
0x40054040:	0x00000000	0x54494d52	0x00000000	0x00000001
0x40054050:	0x00000000	0x00000000	0x00000000	0x00000001
0x40054060:	0x00000000	0x00000000	0x00000000	0x00000000
0x40054070:	0x00000000	0x00000000	0x00000000	0x00000000

x/2x  0x40054024
0x40054024:	0x00000000	0x00000000

And after full initialization (after runtime_init - I verified core is performing that function), registers are a little different, but timer is stuck at 0:

x/32x  0x40054000
0x40054000:	0x00000000	0x00000000	0x00000000	0x00000000
0x40054010:	0x00000000	0x00000000	0x00000000	0x000003e2
0x40054020:	0x00000008	0x00000000	0x00000000	0x00000007
0x40054030:	0x00000000	0x00000000	0x00000008	0x00000000
0x40054040:	0x00000000	0x54494d52	0x00000000	0x00000001
0x40054050:	0x00000000	0x00000000	0x00000000	0x00000001
0x40054060:	0x00000000	0x00000000	0x00000000	0x00000000
0x40054070:	0x00000000	0x00000000	0x00000000	0x00000000

x/2x  0x40054024
0x40054024:	0x00000000	0x00000000

My code no longer functions, all timer-related functions are blocking infinitely.
Of course power-cycling whole board is fixing this issue, until next target reset.

I'm using OpenOCD, Picoprobe with Cortex Debug plugin in VSCode.
Is this a known issue? Am I am doing anything wrong?
I'm fighting with this issue second day, any help is highly appreciated. Thanks!

Hello, During testing some examples I noticed SDK Timer functions are not working when I'm debugging my program. It seems like they are waiting indefinitely for hw timer, which has value 0. ``` x/2x 0x40054024 0x40054024: 0x00000000 0x00000000 x/32x 0x40054000 0x40054000: 0x00000000 0x00000000 0x00000000 0x00000000 0x40054010: 0x00000000 0x00000000 0x00000000 0x000003e2 0x40054020: 0x00000008 0x00000000 0x00000000 0x00000007 0x40054030: 0x00000000 0x00000000 0x00000008 0x00000000 0x40054040: 0x00000000 0x54494d52 0x00000000 0x00000001 0x40054050: 0x00000000 0x00000000 0x00000000 0x00000001 0x40054060: 0x00000000 0x00000000 0x00000000 0x00000000 0x40054070: 0x00000000 0x00000000 0x00000000 0x00000000 ``` But if I power cycle my target and then attach debugger (just attach - not resetting core or touching anything in flash) I can see that code is definitely progressing and timer is no longer stuck. ``` x/2x 0x40054024 0x40054024: 0x00000000 0x002b4a54 x/32x 0x40054000 0x40054000: 0x00000000 0x00000000 0x00000000 0x002b4a54 0x40054010: 0x00000000 0x00000000 0x00000000 0x002b4c8e 0x40054020: 0x00000008 0x00000000 0x002b4a54 0x00000007 0x40054030: 0x00000000 0x00000000 0x00000008 0x00000000 0x40054040: 0x00000000 0x54494d52 0x00000000 0x00000001 0x40054050: 0x00000000 0x00000000 0x00000000 0x00000001 0x40054060: 0x00000000 0x00000000 0x00000000 0x00000000 0x40054070: 0x00000000 0x00000000 0x00000000 0x00000000 ``` if I step though the code I can see that now timer is progressing normally. If I then reset target using debugger I can see core staring from 0x000000ee. After some initialization (I cannot track it, it's before runtime_init function) timer registers seem to be reset: ``` x/32x 0x40054000 0x40054000: 0x00000000 0x00000000 0x00000000 0x00000000 0x40054010: 0x00000000 0x00000000 0x00000000 0x00000000 0x40054020: 0x00000000 0x00000000 0x00000000 0x00000007 0x40054030: 0x00000000 0x00000000 0x00000000 0x00000000 0x40054040: 0x00000000 0x54494d52 0x00000000 0x00000001 0x40054050: 0x00000000 0x00000000 0x00000000 0x00000001 0x40054060: 0x00000000 0x00000000 0x00000000 0x00000000 0x40054070: 0x00000000 0x00000000 0x00000000 0x00000000 x/2x 0x40054024 0x40054024: 0x00000000 0x00000000 ``` And after full initialization (after runtime_init - I verified core is performing that function), registers are a little different, but timer is stuck at 0: ``` x/32x 0x40054000 0x40054000: 0x00000000 0x00000000 0x00000000 0x00000000 0x40054010: 0x00000000 0x00000000 0x00000000 0x000003e2 0x40054020: 0x00000008 0x00000000 0x00000000 0x00000007 0x40054030: 0x00000000 0x00000000 0x00000008 0x00000000 0x40054040: 0x00000000 0x54494d52 0x00000000 0x00000001 0x40054050: 0x00000000 0x00000000 0x00000000 0x00000001 0x40054060: 0x00000000 0x00000000 0x00000000 0x00000000 0x40054070: 0x00000000 0x00000000 0x00000000 0x00000000 x/2x 0x40054024 0x40054024: 0x00000000 0x00000000 ``` My code no longer functions, all timer-related functions are blocking infinitely. Of course power-cycling whole board is fixing this issue, until next target reset. I'm using OpenOCD, Picoprobe with Cortex Debug plugin in VSCode. Is this a known issue? Am I am doing anything wrong? I'm fighting with this issue second day, any help is highly appreciated. Thanks!
lurch commented 2022-12-21 21:16:01 -06:00 (Migrated from github.com)

Is this the same thing as https://github.com/raspberrypi/picoprobe/issues/45 ?

Is this the same thing as https://github.com/raspberrypi/picoprobe/issues/45 ?
l0ud commented 2022-12-22 10:09:33 -06:00 (Migrated from github.com)

@lurch you're right, it's the same thing. After adding USE_CORE 0 to openocd configuration I no longer have that problem.
Thanks!
I would say it's still very confusing timer is configured like that? Can you point me to documentation which register should I change to have counter still running when core is halted?

@lurch you're right, it's the same thing. After adding USE_CORE 0 to openocd configuration I no longer have that problem. Thanks! I would say it's still very confusing timer is configured like that? Can you point me to documentation which register should I change to have counter still running when core is halted?
lurch commented 2022-12-22 11:28:05 -06:00 (Migrated from github.com)

I've not run any code, but a quick look at https://datasheets.raspberrypi.com/rp2040/rp2040-datasheet.pdf suggests that TIMER: DBGPAUSE looks like a likely candidate?

I've not run any code, but a quick look at https://datasheets.raspberrypi.com/rp2040/rp2040-datasheet.pdf suggests that `TIMER: DBGPAUSE` looks like a likely candidate?
👍 2
jgroman commented 2023-02-05 13:47:16 -06:00 (Migrated from github.com)

I had the same problem and can confirm that adding timer_hw->dbgpause = 0; to my code fixed the problem for me.

I had the same problem and can confirm that adding `timer_hw->dbgpause = 0;` to my code fixed the problem for me.
👍 3 ❤️ 6
mischievous commented 2024-04-21 10:39:16 -05:00 (Migrated from github.com)

I had the same problem and can confirm that adding timer_hw->dbgpause = 0; to my code fixed the problem for me.

Dumb question... It looks timer_hw->dbgpause defaults to 0x7 (DBG1/DBG0) enabled. Turning off DBG1 appears to fix the issue... Should pico_runtime/runtime.c::runtime_init set the timer_hw->dbgpause to 0x2 or 0x0 until the second core is "turned" on, then clear it again if the second core is disabled?

> I had the same problem and can confirm that adding `timer_hw->dbgpause = 0;` to my code fixed the problem for me. Dumb question... It looks timer_hw->dbgpause defaults to 0x7 (DBG1/DBG0) enabled. Turning off DBG1 appears to fix the issue... Should pico_runtime/runtime.c::runtime_init set the timer_hw->dbgpause to 0x2 or 0x0 until the second core is "turned" on, then clear it again if the second core is disabled?
👍 1
kilograham commented 2025-03-18 12:38:50 -05:00 (Migrated from github.com)

Re-opening to investigate suggestion

Re-opening to investigate suggestion
recursivenomad commented 2025-04-20 15:09:16 -05:00 (Migrated from github.com)

@kilograham - Directing your attention regarding this issue here in case you haven't seen it recently. I believe the cause of this problem is users using official releases of OpenOCD 0.12.0 as directed to in the getting started guide, but doing so on non-Raspberry Pi systems. Raspberry Pi appears to serve a more up-to-date build of OpenOCD through apt, as 0.12.0 official does not contain SMP support.

Solution for me was to DL OpenOCD's current snapshot build for Windows, and building OpenOCD from source on Debian to achieve SMP support and resolve timers from freezing. See the linked comment/issue for details.

@kilograham - Directing your attention regarding this issue [here](https://github.com/raspberrypi/pico-feedback/issues/428#issuecomment-2490032484) in case you haven't seen it recently. I believe the cause of this problem is users using official releases of OpenOCD 0.12.0 as directed to in the getting started guide, but doing so on non-Raspberry Pi systems. Raspberry Pi appears to serve a more up-to-date build of OpenOCD through `apt`, as 0.12.0 official does not contain SMP support. Solution for me was to DL OpenOCD's current snapshot build for Windows, and building OpenOCD from source on Debian to achieve SMP support and resolve timers from freezing. See the linked comment/issue for details.
lurch commented 2025-04-23 09:49:04 -05:00 (Migrated from github.com)

@recursivenomad Our current recommended setup is to use the Raspberry Pi Pico VSCode extension, which downloads the tools that it needs from https://github.com/raspberrypi/pico-sdk-tools

@will-v-pi Do you think it's worth updating https://datasheets.raspberrypi.com/pico/getting-started-with-pico.pdf to suggest that people always use pico-sdk-tools rather than installing OpenOCD via other methods?

@recursivenomad Our current recommended setup is to use the [Raspberry Pi Pico VSCode extension](https://github.com/raspberrypi/pico-vscode), which downloads the tools that it needs from https://github.com/raspberrypi/pico-sdk-tools @will-v-pi Do you think it's worth updating https://datasheets.raspberrypi.com/pico/getting-started-with-pico.pdf to suggest that people always use pico-sdk-tools rather than installing OpenOCD via other methods?
👍 1
recursivenomad commented 2025-04-23 09:59:50 -05:00 (Migrated from github.com)

Specifically this section still recommends using apt:
https://datasheets.raspberrypi.com/pico/getting-started-with-pico.pdf#_install_openocd

Until OpenOCD 1.0.0 releases later this year, it would also be nice if it could state that OpenOCD 0.12.0 is not supported.

Specifically this section still recommends using `apt`: <https://datasheets.raspberrypi.com/pico/getting-started-with-pico.pdf#_install_openocd> Until OpenOCD 1.0.0 releases later this year, it would also be nice if it could state that OpenOCD 0.12.0 is not supported.
will-v-pi commented 2025-04-23 13:19:19 -05:00 (Migrated from github.com)

@will-v-pi Do you think it's worth updating https://datasheets.raspberrypi.com/pico/getting-started-with-pico.pdf to suggest that people always use pico-sdk-tools rather than installing OpenOCD via other methods?

The guide does already state as the first thing that building from source or downloading from pico-sdk-tools is necessary after RP2350 release, so I think that guidance will just need to persist until the next OpenOCD release, and then we can fix the guide to use OpenOCD 1.0.0

> [@will-v-pi](https://github.com/will-v-pi) Do you think it's worth updating https://datasheets.raspberrypi.com/pico/getting-started-with-pico.pdf to suggest that people always use pico-sdk-tools rather than installing OpenOCD via other methods? The guide does already state as the first thing that building from source or downloading from pico-sdk-tools is necessary after RP2350 release, so I think that guidance will just need to persist until the next OpenOCD release, and then we can fix the guide to use OpenOCD 1.0.0
recursivenomad commented 2025-04-23 13:37:15 -05:00 (Migrated from github.com)

I think the confusion stems from the section immediately below that, titled "Install OpenOCD", which recommends installing from apt. I think a lot of users might click that on the table of contents, and not see the section above it.

FWIW, I think the "Install OpenOCD" section isn't necessary, with the how clear the information provided in "Building OpenOCD" is.

I think the confusion stems from the section immediately below that, titled "Install OpenOCD", which recommends installing from `apt`. I think a lot of users might click that on the table of contents, and not see the section above it. FWIW, I think the "Install OpenOCD" section isn't necessary, with the how clear the information provided in "Building OpenOCD" is.
rgrr commented 2026-02-26 00:26:11 -06:00 (Migrated from github.com)

I stumbled into the very same problem. But this time with pyocd, not with openocd.

I observed that FreeRTOS with dual core worked in pyocd (even if the application did not use both cores), but single core made the program hang in timer_busy_wait_until() because TIMER0 does not count. Running free worked.

My personal solution was to give core1 a reset at start of my application when in single core mode. But perhaps the correct solution would be to set TIMER.DBGPAUSE to the correct value on startup in SDK?

int main(void)
{
#if configNUMBER_OF_CORES != 2
    // this is actually just for debugging the probe firmware running with just one core (good for pyocd)
    // allow to run TIMER0 even in debug pause which would otherwise be inhibited because TIMER0.DBGPAUSE=7
    multicore_reset_core1();
#endif
...
I stumbled into the very same problem. But this time with pyocd, not with openocd. I observed that FreeRTOS with dual core worked in pyocd (even if the application did not use both cores), but single core made the program hang in timer_busy_wait_until() because TIMER0 does not count. Running free worked. My personal solution was to give core1 a reset at start of my application when in single core mode. But perhaps the correct solution would be to set TIMER.DBGPAUSE to the correct value on startup in SDK? ```C int main(void) { #if configNUMBER_OF_CORES != 2 // this is actually just for debugging the probe firmware running with just one core (good for pyocd) // allow to run TIMER0 even in debug pause which would otherwise be inhibited because TIMER0.DBGPAUSE=7 multicore_reset_core1(); #endif ... ```
will-v-pi commented 2026-06-10 05:36:37 -05:00 (Migrated from github.com)

I think the confusion stems from the section immediately below that, titled "Install OpenOCD", which recommends installing from apt. I think a lot of users might click that on the table of contents, and not see the section above it.

FWIW, I think the "Install OpenOCD" section isn't necessary, with the how clear the information provided in "Building OpenOCD" is.

This docs fix has been merged internally, so will be in the next docs release

> I think the confusion stems from the section immediately below that, titled "Install OpenOCD", which recommends installing from `apt`. I think a lot of users might click that on the table of contents, and not see the section above it. > > FWIW, I think the "Install OpenOCD" section isn't necessary, with the how clear the information provided in "Building OpenOCD" is. This docs fix has been merged internally, so will be in the next docs release
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
master
rpi-connect-preview
ns-alpha
combine-uf2s
powman-fixups
persistent-data-docs
develop
aon-docs-fix
default-uart-fixups
async-context-deinit-freertos
sdk-time-critical
riscv-flag-check
multi-gcc-riscv-scrict-align
multi-gcc-develop
another-sleep-fix
powman-default-tick
bootrom_sysinfo_tweaks
board_header_checks
mbedtls-file-lists
use_count_of
vtable-per-core
stdio-usb-reset-compat
pico-aes
better-package
ditch_pico_pio_version
ns-develop
hardware-header-updates
low-power-ci
pioasm-cflags
lurch-patch-4
lurch-patch-3
rom_version
iar/develop
2.3.1
2.3.0
2.2.0
2.1.0-correct-picotool
2.1.1-correct-picotool
2.1.1
2.1.0
2.0.0
1.5.1
1.5.0
1.4.0
1.3.1
1.3.0
1.2.0
1.1.2
1.1.1
1.1.0
1.0.1
1.0.0
Labels
Clear labels   
bazel

   
bluetooth

   
board settings

   
boot_stage2

   
bug
Something isn't working

  
build

   
c++

   
can't reproduce
Can not reproduce the bug

  
clang

   
clib-interface

   
cmsis

   
code cleanliness

   
code size

   
compiler version issues

   
cyw43_driver

   
debug

   
discussion

   
documentation
Improvements or additions to documentation

  
duplicate
This issue or pull request already exists

  
dynamic_clock

   
elf2uf2

   
enhancement
New feature or request

  
errata

   
filesystem

   
flash layout

   
floating point

   
FreeRTOS

   
hardware_adc

   
hardware_claim

   
hardware_clocks

   
hardware_dma

   
hardware_exception

   
hardware_flash

   
hardware_gpio

   
hardware_i2c

   
hardware_irq

   
hardware_pio

   
hardware_pwm

   
hardware_rcp

   
hardware_rtc

   
hardware_spi

   
hardware_sync

   
hardware_uart

   
hardware_vreg

   
hardware_watchdog

   
hardware_xosc

   
help wanted
Extra attention is needed

  
host

   
IAR

   
installation

   
invalid
This doesn't seem right

  
linker scripts

   
lto

   
lwip

   
mbedtls

   
missing API

   
needs reporter detail

   
networking

   
newlib

   
newlib-multicore

   
non-c

   
non-cmake

   
non-gcc

   
openocd

   
orphan PR

   
OS integration

   
pico_async_context

   
pico_base

   
pico_binary_info

   
pico_flash

   
picolibc

   
pico_lwip

   
pico_malloc

   
pico_multicore

   
pico_printf

   
pico_runtime

   
pico_stdio

   
pico_stdio_usb

   
pico_sync

   
pico_time

   
pico_util

   
pioasm

   
port
issues or discussions of porting code/libraries to rp2040

  
question
Further information is requested

  
review

   
review2

   
rtos interop
Consideration for FreeRTOS co-existence

  
runtime init

   
static library

   
svd

   
test

   
tinyusb

   
vscode

   
wifi integration

   
wontfix
This will not be worked on

No labels
bazel
bluetooth
board settings
boot_stage2
bug
build
c++
can't reproduce
clang
clib-interface
cmsis
code cleanliness
code size
compiler version issues
cyw43_driver
debug
discussion
documentation
duplicate
dynamic_clock
elf2uf2
enhancement
errata
filesystem
flash layout
floating point
FreeRTOS
hardware_adc
hardware_claim
hardware_clocks
hardware_dma
hardware_exception
hardware_flash
hardware_gpio
hardware_i2c
hardware_irq
hardware_pio
hardware_pwm
hardware_rcp
hardware_rtc
hardware_spi
hardware_sync
hardware_uart
hardware_vreg
hardware_watchdog
hardware_xosc
help wanted
host
IAR
installation
invalid
linker scripts
lto
lwip
mbedtls
missing API
needs reporter detail
networking
newlib
newlib-multicore
non-c
non-cmake
non-gcc
openocd
orphan PR
OS integration
pico_async_context
pico_base
pico_binary_info
pico_flash
picolibc
pico_lwip
pico_malloc
pico_multicore
pico_printf
pico_runtime
pico_stdio
pico_stdio_usb
pico_sync
pico_time
pico_util
pioasm
port
question
review
review2
rtos interop
runtime init
static library
svd
test
tinyusb
vscode
wifi integration
wontfix
Milestone
Clear milestone
No items
No milestone
2.3.0
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
gh-raspberrypi/pico-sdk#1152
No description provided.