direct use of TIMER clashing with SDK ?

Post Reply

Print view

3 posts • Page 1 of 1

pie_face: Posts: 171; Joined: Sun Aug 04, 2024 11:16 am

direct use of TIMER clashing with SDK ?

Quote

Tue Nov 11, 2025 2:55 pm

Hi,

I use one core of rp2040 to run the device and trigger some IO on the other core by forcing a timer event.

Code: Select all

 hw_set_bits(&timer_hw->intf, TIMER_MASK); // trigger ISR on core1

in the ISR on core1 I clear it :

Code: Select all

 hw_clear_bits(&timer_hw->intf, TIMER_MASK); // disable in NVIC of core0

This seemed like a simple solution to avoid setting full on FIFO communication for such a trivial task. (I tried, wasted a lot of time, and decided it was overkill).

However, I'm seeing occasional glitches in the data which may or may not be due to this , I'm digging.

Could this clash with SDK running i2c and spi using "alarms" ?

If so is there a way to do this in a way which does not clash with SDK use of timers?

TIA.

gmx: Posts: 1845; Joined: Thu Aug 29, 2024 8:51 pm

Re: direct use of TIMER clashing with SDK ?

Quote

Tue Nov 11, 2025 5:27 pm

The system counter/timer is used by:

4.2.11. pico_time
API for accurate timestamps, sleeping, and time based callbacks.
4.2.11.1. Detailed Description
NOTE
The functions defined here provide a much more powerful and user friendly wrapping around the low level hardware
timer functionality. For these functions (and any other SDK functionality e.g. timeouts, that relies on them) to work
correctly, the hardware timer should not be modified. i.e. it is expected to be monotonically increasing once per
microsecond. Fortunately there is no need to modify the hardware timer as any functionality you can think of that
isn’t already covered here can easily be modelled by adding or subtracting a constant value from the unmodified
hardware timer.
4.2.11.2. Modules
timestamp Timestamp functions relating to points in time (including the current time).
sleep Sleep functions for delaying execution in a lower power state.
alarm Alarm functions for scheduling future execution.
repeating_timer Repeating Timer functions for simple scheduling of repeated execution.

Maybe you should use:

4.1.28. hardware_timer
Low-level hardware timer API.

pie_face: Posts: 171; Joined: Sun Aug 04, 2024 11:16 am

Re: direct use of TIMER clashing with SDK ?

Quote

Tue Nov 11, 2025 9:52 pm

Thanks.

IRQ_FORCE
Writing a 1 to each of these bits will forcibly assert the
corresponding IRQ. Note this is different to the INTF register:
writing here affects PIO internal state. INTF just asserts the
processor-facing IRQ signal for testing ISRs, and is not visible to
the state machines.

Maybe you should use:

4.1.28. hardware_timer
Low-level hardware timer API.

I thought I was:

Code: Select all

 
 #define TIMER_NUM 1 // four counters, only one timer.
 #define TIMER_MASK (1<<TIMER_NUM)
 hw_set_bits(&timer_hw->intf, TIMER_MASK); // trigger ISR on core1

This should write to TIMER: INTF Register and immediately trigger an interrupt calling the ISR it associated with it.
I'm clearing this bit in the ISR but that's probably superfluous, though I don't see an explicit declaration this is cleared automatically.
I don't need to touch the ALARM register since I'm not using counters and comparators.

Obviously , I don't change the 1us interval of the timer.

Since there is only ONE timer on this chip, it is common to both cores and provides an efficient way to trigger an ISR fn in one core from the other one.

From my reading of the doc , it looks legit at the chip level.

Can I be confident this will not affect the rest of the SDK implementation of SPI, I2C or UART functionality?

cheers.