The next couple weeks will document one of the biggest parts of this GSoC project, exposing the actual raw metrics from RTEMS to Scrutiny so they can be instrumented. Unfortunately, RTEMS does not provide any “raw” constantly updating numeric values exclusively for any of the metrics I want to implement (namely for this blog, interrupts).
Counting the amount of interrupts as a single numeric updating value is something RTEMS does not provide either. Using the example of determining memory usage through stackchk.h (an RTEMS library under libmisc/), it does provide numeric values, but only as information within a struct that is given to you via callbacks, therefore this cannot be used as a metric to hook onto Scrutiny.
The most roundabout but obvious way to get around this is to parse the printer functions that RTEMS does provide and extract the numeric values from them. Unfortunately, this is unefficient and may not even fit with the rate at which Scrutiny runs its instrumentation. We need a variable that is always available, consistently updated, numeric, and has one memory address to instrument off of.
My proposal initially was to create a small library under libmisc/ that provides these numeric metrics in a Scrutiny-agnostic way. This may or may not be the proper approach. Regardless, the matter at hand is to first get some sort of metric running through my demo file.
During my last blog post I initialized datalogging through the Scrutiny C Wrapper with RTEMS via my demo file. If we look back at the 100hz function:
void task_100hz() {
counter++;
scrutiny_c_loop_handler_fixed_freq_process(task_100hz_lh, 10000U);
}
We don’t return the counter variable or anything. Scrutiny will instrument its value through the varmap generated by the SFD or as a runtime published variable (RPV) if initialized otherwise.
Now to count interrupts, I initialize an interrupt count variable with _Atomic before it. If an interrupt fires while the counter variable is being read it can cause corruption, so we need to make sure the interrupt count is an atomic value.
_Atomic uint32_t interrupts = 0;
Later edit: better to probably use volatile
Now the real challenge comes, actually counting interrupts in a hardware agnostic way. We want this abstract enough to work across all architectures.
My initial approach
My initial approach involved using rtems_interrupt_catch to “catch” whenever an interrupt fired…
rtems_status_code interrupt_counter(rtems_vector_number vector) {
rtems_isr_entry old_isr_handler;
rtems_status_code catch = rtems_interrupt_catch(
interrupt_counter_isr,
vector,
&old_isr_handler
);
return catch;
}
Establishing a new ISR that just increments everytime time an interrupt is caught:
rtems_isr interrupt_counter_isr(rtems_vector_number vector) {
interrupts++;
}
Then feeding it to the Init() past the Scrutiny config and task config:
status = interrupt_counter(LEON3_VECTOR);
directive_failed( status, "interrupt" );
Later edit: rtems_interrupt_catch() may be deprecated. A more modern replacement would need to be found. The overall logic remains the same however.
Attempting a new solution:
Unfortunately this methodology does not seem to work effectively. The problem is that this is far too much of a simple approach (coupled with rtems_interrupt_catch() not being optimal) to count interrupts across all hardwares. After testing on both STM32F4 physical hardware & LEON3 QEMU, the interrupts variable doesn’t seem to increment.
There may not be a possible way to expose an interrupt count that is hardware-agnostic. Almost every solution requires something specific design that takes from the BSPs in question.
After some more research, I’m aiming towards another solution using rtems_interrupt_handler_install(), this would require something like this:
rtems_status_code rtems_interrupt_handler_install(
rtems_vector_number vector,
const char *info,
rtems_option options,
rtems_interrupt_handler routine,
void *arg
);
(taken from the documentation on interrupt directive here)
This way, I’d be able to handle counting interrupt more seamlessly. However, this isn’t entirely hardware agnostic since you still need to pass a vector value. If I take the approach of a telemetry library (or even any other sort of “glue” code), this function would take in the vector number as a parameter. This would be provided by the user depending on which BSP they’re using.
I wrote up this directive,
rtems_interrupt_handler_install(
LEON3_VECTOR, /* test vector on 14 */
"interrupt counter",
RTEMS_INTERRUPT_SHARED,
interrupt_counter,
NULL
);
However, I still got issues with getting the interrupt count to increment. On the Scrutiny GUI, it simply stays at 0. After various hours of siphoning through solutions, I realized the problem may be linked to whether an interrupt was being picked up at all.
At the current moment, there is one glaring issue with counting interrupts this way, it only counts interrupts from ONE vector. And there weren’t any interrupts firing from that vector while I was testing. That being said, I manually edited the leon3 vector 14 register so I create a fake interrupt:
volatile uint32_t *irq = (volatile uint32_t*) 0x80000208;
*irq = (1 << 14);
But there was also another issue, with Scrutiny. This is specific to the LEON3 architecture since it’s big endian. Scrutiny has some issues with byte-swapping and decoding on big endian architecture which will be fixed soon after I discussed it with my mentor. Regardless, all I had to do to fix this was assign a new interrupt count variable and byte swap it (though this took me quite a while to figure out):
interrupts_count = __builtin_bswap32(interrupts);
As of 2026-07-02 this has been fixed, so I no longer need to byte swap. Scrutiny now supports big endian architecture seamlessly
And finally, after running Scrutiny, we can see that this interrupt was counted:
However, that’s not all there is to interrupt counts. As I said, this only counts an interrupt from ONE vector, we need to loop through all interrupt vectors in order to establish a handler on each one. Some will fail (so I won’t use directive) for sure, but we’ll be able to extract a count for all interrupts through this manner. All the user needs to provide is the amount of vectors according to their BSP, instead of the vector number itself. In the case of LEON3 architecture, it’s 15 vectors, and the STM32F4 has 96.
for (uint32_t i = 0; i < LEON3_VECTOR_COUNT; i++) { /* or STM32F4_VECTOR_COUNT */
status = rtems_interrupt_handler_install(
i,
"interrupt counter",
RTEMS_INTERRUPT_SHARED,
interrupt_counter,
NULL
);
// directive_failed( status, "interrupt counter" );
}