pico_time/time.c using GPIO pins #28
Labels
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
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
gh-raspberrypi/pico-sdk#28
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
I've been having a problem with calls to functions in time.c (eg.
sleep_ms()) having side effects on GPIO pins.I'm pretty sure this is related to the DEBUG_PINS macros; changing
#define PICO_DEBUG_PIN_BASE 19uin src/rp2_common/hardware_gpio/include/hardware/gpio.h to something else changes the GPIO pins that are affected. (My project is using GPIO 21 as an output, which is how I discovered this.)I don't immediately see how to turn this off!
time.c lines 16–17 is currently:
This appears to be enough for
DEBUG_PINS_ENABLED(core)to be true and for the DEBUG_PINS_foo(core, v) macros to callgpio_set_mask()etc. as appropriate, whether or notgpio_debug_pins_init()has been called at any point.I think the correct fix is to comment out
CU_SELECT_DEBUG_PINS(core)in time.cDoh! Yes that should not be enabled; will fix (and grep for others) - that probably snuck back in while testing something!
Does this mean that gpio_debug_pins_init() also doesn't work as intended in so far as it is not the only way to enable the debug pins ?
Nope, gpio_debug_pins_init() sets up the pins for output. The macros turn on/off code that writes values to the pins for debugging (mostly for use with logic analyzers when debugging higher frequency stuff)
the macros should not be enabled in any library code.
Ok, but you did write "for the debug pins to do anything, you have to call gpio_debug_pins_init()" which sounded like it enabled them as well as setting them to output and l can't see where gpio_debug_pins_init() is covered in the SDK documentation.
merged into develop
This should now be fixed in MicroPython mainline, see micropython/micropython#6826. Nightly UF2 builds of MicroPython are available from https://micropython.org/download/rp2-pico/.