tonyg
Posts: 5
Joined: Thu Oct 04, 2012 5:10 pm

B+ Cycle counter, IRQs, and Wait-for-interrupt

Sat Aug 01, 2015 9:23 pm

Hi all.

I'm trying to use the ARM1176JZF-S cycle counter (MRC p15, 0, R0, c15, c12, 1) to roughly measure IRQ latency in my little kernel. Things seem to be mostly working OK, but I've noticed an oddity.

My kernel invokes Wait-for-interrupt (MCR p15, 0, R0, c7, c0, 4) after setting a timer alarm by poking at the system timer.

Each time the IRQ handler runs, at the top of the handler, I read the cycle counter. The weird thing is that it is always 0x80000113 for a while, and then 0x60000113 seemingly forever. So it looks like somewhere -- either power management machinery, WFI machinery, or something weird I'm doing -- is resetting the cycle counter to 0x80000000 (or 0x60000000) at about the time the interrupt fires.

WFI does put the CPU into a sleep-ish mode, apparently -- perhaps it loses/resets the counter's value there? If so, where would that be documented? And why the weird behaviour where it sets the high nibble to 8 a few times, and then 6?

Any help or insight appreciated :-)

Regards,
Tony

colinh
Posts: 95
Joined: Tue Dec 03, 2013 11:59 pm
Location: Munich

Re: B+ Cycle counter, IRQs, and Wait-for-interrupt

Fri Aug 07, 2015 12:23 pm

Without reading up to check, you might want to have a look at the Memory Order Model section of the ARMv6ARM, if you haven't already. Could be a total red herring, but that stuff looks like it could account for a lot of oddities :)

tonyg
Posts: 5
Joined: Thu Oct 04, 2012 5:10 pm

Re: B+ Cycle counter, IRQs, and Wait-for-interrupt

Sat Aug 08, 2015 11:41 pm

colinh wrote:Without reading up to check, you might want to have a look at the Memory Order Model section of the ARMv6ARM, if you haven't already. Could be a total red herring, but that stuff looks like it could account for a lot of oddities :)
Thanks - yes, it's caused problems in other areas. I don't think it's to blame this time, though, because the performance counters are all accessed via MRC/MCR instructions, not touching memory at all. (I did, however, do the experiment of putting in gratuitous cache flushes, to no effect.)

My suspicion, based on nothing in particular, is that since the CPU is genuinely halted during the wait for interrupts, this has something to do with the strange value in the cycle counter - after all, it hasn't been performing cycles. Though I suppose I might have expected the counter to just... not advance while the CPU was asleep.

Return to “Bare metal, Assembly language”