- August 1, 2014 at 9:06 am #31781
On Microchip’s PIC32MX devices (M4K core with an EIC), an EHB or JR.HB instruction does not clear hazards after writing to Cause.IP1/IP0. Instead, you have to insert a three-cycle wait to ensure that the interrupt is triggered. Is this a defect in the implementation, or do the hazard barrier instructions not cover external interrupt controllers?August 20, 2014 at 3:32 am #38916
An EHB is just to make sure that a mtc0 doesn’t put the following instructions into a hazard case. It has no effect on the software interrupt. The sw interrupt needs three cycles for pipeline flush before it is raised and pending. EHB doesn’t change the pipeline flush logic. So this is normal behavior.
Usually the software interrupt is enabled, while in an interrupt routine, to preform task that don’t need as high an interrupt priority, By the time the interrupt routine does a eret the software interrupt will be raised and taken if its the highest priority interrupt pending.August 24, 2014 at 10:14 pm #38917
If it is normal behaviour, then I think the hazards section of the M4K Processor Core Software User’s Manual is misleadingly written. Just to be clear, this is the kind of code I’m talking about:
li $t0, 0
mtc0 $t1, $13 # sets IP0
li $t0, 1
My reading of the documentation was that $t0 would contain 0 on ISR entry, but it seems not to be the case. The specific circumstance where it bit me was using the software interrupt to pend an OS context switch.