Timer Interrupt Configuration and Use Within User Space


I’m trying to configure a precise hardware timer, whose interrupt handler should use a callback function to broadcast messages within my python development environment. For testing purposes, my initial goal is to toggle a GPIO to ensure the timer has the right configuration. So far all my attempts were unsuccessful. Here are the steps I’m trying to follow and the associated issues I’m facing:

  1. Check TRM to find out the memory addresses and bit fields of the TMR0 I want to configure. Here is what I have:

TMR0 Address range
TMR0_BASE_ADDRESS = 0x02090000
TMR0_END_ADDRESS = 0x0209ffff

Offset for all TMR0 registers:
STA_REG_OFFSET = 0x10004

Start addresses of all TMR0 registers:

  1. Confirm the mapping of the address range associated with the TMR0 register. Specifically, I am examining whether the memory region is appropriately mapped to a file.

Upon reviewing the contents of “/proc/iomem,” the provided information is as follows:
iomem.txt (11.1 KB)

However, it seems that the indicated address range is not currently mapped to any file.

Additionally, I have examined the contents of “/proc/modules” below:
kernel_modules.txt (4.4 KB)

It appears that the driver or kernel module for the timer is not present.

I am reaching out to seek guidance on whether the absence of the timer driver or kernel module may be the cause of the unmapped address range. I would appreciate your assistance in directing me on how to load the required driver or kernel module for the timer.

  1. Once previous step is completed, I’m planning to modify the kernel module to include a callback function, followed by the compilation and installation of the updated module. Subsequently, I plan to write to the timer registers, presuming little-endian memory storage, using either the devmem tool in the terminal or a Python script with the mmap module.

I am curious whether “CONFIG_STRICT_DEVMEM=y” in the kernel configuration file might restrict my ability to configure the TMR0 registers. If this is the case, could you kindly clarify if recompiling the kernel is the only viable solution to overcome this restriction?

  1. Finally, I intend to monitor GPIO state using an oscilloscope to ensure accurate timing.

I must note that my knowledge of Linux and the kernel is limited, and any guidance you can provide to fill in the gaps or highlight missing steps would be immensely appreciated.

Thank you for your time and expertise. I look forward to your valuable insights.

Hi dkhomenko,

Are you using the devkit or custom board for Orin Nano?
What’s your Jetpack version in use?

The TMR seems not available for user to configure.

Could you help to check if the following instruction meet your requirement?
Generic Timestamp Engine — Jetson Linux Developer Guide documentation (nvidia.com)

Hi KevinFFF,

Thank you for your quick response.

I am working with the devkit and Jetpack 5.1.2.
I will investigate the GTE and share my findings in a few days.

Hi Kevin,

After reviewing the GTE documentation, it seems that the functionalities it offers may not align with the requirements of the project I am currently engaged in.

The developer guide explicitly mentions that “The Jetson GTE provides hardware timestamping for state changes of specific signals.” However, my main goal is to enable generation of a signal (interrupt) at precise time intervals, rather than monitoring when a GPIO changes its state and recording the time. The monitoring of the GPIO would be used as a final step to ensure the timer interrupt was configured correctly, before using it to trigger data transmission with by calling a function within my python application. Please note that I’ve also tried to use software timers, but the data transmission timing proved to be far too jittery. This is primarily due to the inherent characteristics of software timers, including their reliance on system scheduling, processing, and the method of time calculation, hence the selection of hardware timers for this project.

I would appreciate any guidance or suggestions on alternative approaches.

Thank you for your assistance.