EIC and Hazard Barriers

This topic contains 2 replies, has 2 voices, and was last updated by  andersm 3 years, 1 month ago.

Viewing 3 posts - 1 through 3 (of 3 total)
  • Author
    Posts
  • #31781

    andersm
    Member

    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?

    #38916

    ChrisImgtec
    Moderator

    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.

    #38917

    andersm
    Member

    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
    ehb
    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.

Viewing 3 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic.