clarification about acknowledging XIRQ interrupts

[biosbob]

after implementing the suggestion in #588, i want to claify the steps required to acknowledge an XIRQ interrupt....

according to the XIRQ docs, we must:

1. clear the bit corresponding to the XIRQ FIRQ in mip
2. clear the bit corresponding to the pending XIRQ channel in EIP; and
3. write any value to ESC to complete the acknowledgement

in my use-case, one of my iCEBreaker buttons is associated with XIRQ(0); triggering an interrupt occurs on the rising edge of the button press.... my interrupt handler (which performs steps 1-3) begins execution as soon as i press (and even hold) the button....

when i look a little closer with my logic analyzer, however, i find that the interrupt is executing TWICE.... said another way, even though i've performed steps 1-3, i am immediately hit with the same interrupt before idling through the WFI instruction....

my workaround -- as a fourth step, i explictly DISABLE the corresponding XIRQ channel in EIE in my interrupt handler.... with this change, i now execute my handler exactly once per button-press.... needless to say, i re-enable the XIRQ channel before executing the next WFI instruction....

not a big issue -- though this is NOT how mie and mip work in general.... specifically, i only need to touch mip in step 1 above; the XIRQ FIRQ can remain enabled in mie....

my experience with other MCUs is that they do behave in accordance with model presented in the docs; and that's exactly how my first implementation proceeded.... in reality, however, i required the extra step of disabling the XIRQ channel itself....

as they say: when the map and the terrain disagree, trust the terrain 😉

[stnolting]

Hey @biosbob!

according to the XIRQ docs, we must: [...]

Your steps sound right. Basically, this is identical to the operations of the XIRQ RTE (runtime environment) handler:

neorv32/sw/lib/source/neorv32_xirq.c

Lines 229 to 246 in 543e45b

	static void __neorv32_xirq_core(void) {
	neorv32_cpu_csr_write(CSR_MIP, ~(1 << XIRQ_FIRQ_PENDING)); // acknowledge XIRQ FIRQ
	// get highest-priority XIRQ channel
	uint32_t src = NEORV32_XIRQ->ESC;
	// clear the currently pending XIRQ interrupt
	NEORV32_XIRQ->EIP = ~(1 << src);
	// execute handler
	uint32_t xirq_handler = __neorv32_xirq_vector_lut[src];
	void (*handler_pnt)(void);
	handler_pnt = (void*)xirq_handler;
	(*handler_pnt)();
	NEORV32_XIRQ->ESC = 0; // acknowledge the current XIRQ interrupt
	}

in my use-case, one of my iCEBreaker buttons is associated with XIRQ(0); triggering an interrupt occurs on the rising edge of the button press...

Did you configure the XIRQ_TRIGGER_TYPE and XIRQ_TRIGGER_POLARITY generics accordingly so that the trigger type is set to "rising-edge" for your button's XIRQ channel?

when i look a little closer with my logic analyzer, however, i find that the interrupt is executing TWICE.... said another way, even though i've performed steps 1-3, i am immediately hit with the same interrupt before idling through the WFI instruction....

Have you also checked the signal of your button? Maybe it requires some additional debouncing logic?

though this is NOT how mie and mip work in general.

Could you specify this a little bit more in detail?

The XIRQ's EIP register is similar to RISC-V's mip register. A bit in here becomes pending when the according interrupt source fires. In terms of the XIRQ, a bit will becomes set if the configured trigger type fires.

The XIRQ's EIR register behaves just like the RISC-V mie register (enabling specific interrupt sources). A pending interrupt can only cause a CPU interrupt if the according enable and pending bits are both set.

[biosbob]

must have been something that happened in the heat of development.... my handler is now doing that same steps as yours -- and it's working just fine now....

[stnolting]

Great to hear! 😄

[biosbob]

problem resolved