Interrupts

What kind of operations occur in interrupt service, and what points should I note?

[Introduction]
The basic operations of interrupt service are broadly carried out by 4 phases.

The first is the part that requests the interrupt, the second is the interrupt request flag, the third is the interrupt controller that controls the interrupt, and the fourth is the CPU that actually executes the interrupt service.
An interrupt is serviced via these 4 phases.




[Interrupt request source]
Parts that request interrupts include the timer block, serial block, and external signal edge detector (these parts differ depending on the device).
Once an interrupt request condition, such as a timer match or completion of serial data reception, has been met, the corresponding interrupt request flag is set in these parts.

The first phase of interrupt service involves the satisfaction of a specified condition in each peripheral function block. When a condition such as a match with a compare register in the timer block, completion of communication in the serial block, or detection of an edge via an external interrupt is satisfied, the corresponding interrupt request flag is set. Interrupt request flags can also be set by program.

[Interrupt request flag]
In this way, each interrupt request source simply sets the corresponding interrupt request flag. The interrupt request source and interrupt controller operate independently.
The interrupt request flag is what connects these two parts.

Note that there is only one interrupt request flag (1 bit) for each interrupt source.
Therefore, even if the same interrupt request occurs more than once before the interrupt is acknowledged, it will only be recognized as having occurred once.

Interrupt request flags can also be set and cleared by program.
When using this function, all UART transmission processing, including transmission of the first data, can be executed via interrupts.
In this case, however, be sure to set the relevant interrupt request flag using a bit manipulation instruction.

Example of UART transmission processing When transmitting multiple bytes of data, the main program usually writes the first byte of the output data to UART, and at the same time, information on the second and subsequent bytes of data is passed to the interrupt service program. The interrupt service program then writes the second and subsequent bytes of data to UART based on the information passed from the main program. The processing therefore differs between the first and subsequent bytes of data. The main program passes the information on the transmit data to the interrupt service program and set the interrupt request flag. All of the processing to actually write data to UART is carried out by the interrupt service program, so the entire processing flow is more visible.

[Interrupt controller]
Operations subsequent to the interrupt request flag are executed by the interrupt controller.
Whether to enable (not mask) or disable (mask) an interrupt request flag is determined by the interrupt controller according to the setting of the interrupt mask register.

An interrupt request flag that has been set to disabled is ignored in all subsequent operations.
However, because the request flag itself is not cleared, once the mask is cancelled, the interrupt request becomes enabled again from that point.

Unmasked interrupt requests are sent to the standby controller and are used for releasing standby (except when the macro service in the 78K4 is used).

Interrupt requests are also sent to the CPU via the interrupt priority circuit.
When the CPU receives an interrupt, the corresponding interrupt request flag is cleared.
If the CPU is in the interrupt-disabled state, the received interrupt is simply used to release standby (if the system is not in the standby state, the interrupt is simply held pending).

If the CPU is in the interrupt-enabled state, vector interrupt service is executed after standby is released.
Note that when the macro service in the 78K4 is used, interrupts are received even if the CPU is in the interrupt-disabled state, and are serviced by the macro service function.

Interrupt request flags can be used in the following three ways. They can be used to check whether the processing of the on-chip peripheral function is completed. They can be polled (read out) by the program to check whether the processing of the interrupt request source is completed. In this case, set the interrupt mask to ensure the interrupt is not sent to the CPU. They can be used to release standby. If an unmasked interrupt request flag is set in the standby state, standby is released. At this time, if the CPU is in the interrupt-disabled state, vector interrupt service is not performed after standby is released, and execution resumes after the standby instruction. (If the macro service in the 78K4 is executed, standby is not released.) They can be used as vector interrupt requests to be sent to the CPU. In this case, the status of other interrupt request flags and the interrupt currently being executed by the CPU is checked by the interrupt priority circuit, and the interrupt request with the highest priority is sent to the CPU.

The interrupt priority circuit compares the priority level of interrupt requests generated at the same time, as well as the priority of the interrupt currently being serviced.

Consequently, the interrupt controller monitors the status of the interrupt currently being executed by the CPU, and judges that interrupt service is "in progress" until the RETI instruction is executed.
In the case of the 78K4 and 78K0, while an NMI is being executed, an interrupt with a lower priority cannot be acknowledged even if the CPU executes the EI instruction.


[CPU]
If the CPU is in the interrupt-enabled state, it acknowledges the interrupt with the highest priority (as determined by the interrupt priority circuit), saves the PC and PSW values to the stack, and branches to the interrupt vector.
At this time, the corresponding interrupt request flag is cleared and the CPU enters the interrupt-disabled state.

Note that the timing at which the CPU acknowledges an interrupt and branches to the interrupt vector differs depending on the execution state of the instruction.
So it is not always the same.
This timing varies greatly if an interrupt request hold instruction is executed, or if there is a period in which interrupts are disabled.
Consequently, if the exact timing is needed, you should use hardware functions such as the timer output function or real-time output function instead of interrupt service.

Once interrupt service is completed, the program returns to the original processing via the RETI instruction.
At this time, the original value before interrupt acknowledgment is written back to the PSW, so there is no need to execute the EI instruction immediately before executing the RETI instruction.

In the service routine of a low-priority interrupt source, I immediately enabled interrupts using the EI instruction, but the same interrupt requests keeps being acknowledged.

Simply enabling interrupts in the interrupt service routine will allow any interrupt to be acknowledged, even if it is the same interrupt.
In this case, mask the relevant interrupt request.

Which approach should I use to process multiple interrupts of 3 or more levels?

Two priority levels can be set for 78K0 interrupts.
Each interrupt also has a default priority level.
The actual priority level of each interrupt is therefore determined according to these two types of priority levels.

When interrupts occur simultaneously (occurrence when CPU can acknowledge the interrupts), the CPU acknowledges the one with the highest priority.
If the two interrupts have the same specified priority level, the one with the highest default priority is acknowledged.
By using this priority level specification function, multiple interrupt processing is easily realized up to 2 levels.
However, if multiple interrupts of more than 2 levels are used, care is required about the way they are processed.

Basically, the interrupt mask function is used in this case.

The following explanation uses 4 interrupts, INTP0 to INTP3, assuming their respective priority levels to be


At this time, PPR0 and PPR1 are set to 1 and PPR2 and PPR3 are set to 0.
The processing required for each interrupt is as follows.
The processing flow is described in an attachment.

(1) Processing when INTP2 is being acknowledged [Processing flow (1)]
Since this interrupt has the highest priority level, there is no need to acknowledge any other interrupt.
Therefore, during this processing, interrupts are disabled.

(2) Processing when INTP3 is being acknowledged [Processing flow (2)]
While this interrupt processing is taking place, the INTP2 interrupt must be acknowledged.
Also, it is necessary to disable the INTP0 and INTP1.

Since the highest priority level has been specified for INTP3, the ISP flag of PSW is 0 while INTP3 is being executed, and INTP0 and INTP1, for which a low priority level has been specified, are automatically disabled.

Therefore, you may think that it simply suffices to enable interrupts.
However, if INTP3 could be input again during INTP3 interrupt processing, it is necessary to also disable INTP3.

It is therefore necessary to enable interrupts after setting the PMK3 interrupt mask flag.
Moreover, before exiting interrupt processing, disable interrupts and clear PMK3.



(3) Processing when INTP0 is being acknowledged [Processing flow (3)]
While this interrupt processing is taking place, it is necessary to acknowledge only INTP2 and INTP3.
Moreover, it is necessary to disable INTP0 itself and INTP1.

For this purpose, it is necessary to set PMK0 and PMK1 prior to enabling interrupts.
Moreover, before exiting interrupt processing, disable interrupts and clear PMK0 and PMK1.

(4) Processing when INTP1 is being acknowledged [Processing flow (4)]
While this interrupt processing is taking place, it is necessary to acknowledge interrupts other than INTP1 itself (INTP2, INTP3, INTP0), so setting PMK1 prior to enabling interrupts is required.
Moreover, before exiting interrupt processing, disable interrupts and clear PMK1.

This question is regarding the INTM0 (external interrupt mode register 0) setting method for the uPD780053, when performing remote control reception in the TM0 free-running mode using the INTP0 interrupt, and when the valid edge specification can be changed at any time.

The UM says
but referring to "Remote control reception in free-running mode" in the Application Note, the valid edge of INTP0 is specified without stopping the timer operation as part of the INTP0 interrupt processing.

In other words, can the INTM0 setting be performed without stopping the timer?

The UM description you mention is a caution for cases such as when the INTP0/TI00/P00 pin is used as TI00, when the signal from this pin is used with timer 0.
As mentioned in your inquiry, timer 0 operates in the free-running PWM mode using the internal clock, and when the pin is not used as TI00, switching the valid edge has no influence on timer 0.

Regardless of whether an 8-bit timer interrupt flag is set during UART transmission, no 8-bit timer interrupt occurs.
Why is this and what is the handling for this?

[Program]
    do {
    } while (STYF==0);

The problem lies with the instruction at the place where the system is waiting until STIF is set.

This do ... while statement is substituted for the BF instruction, resulting in branching to itself.
On the other hand, when accessing the interrupt request flag, interrupts are held pending.
In other words, while the system is waiting for STIF to be set, interrupts are held pending and no interrupt is acknowledged.

Write a dummy instruction in do { } so that interrupts are acknowledged during this interval.

For example, at the beginning of the program, write

#pragma NOP

and make the following changes.

    do {
        NOP();
        NOP();
    } while (STIF==0):

In the uPD78058, when HALT is released by an interrupt and the uPD78058 is operating on the subsystem clock, is it correct to assume that if another interrupt occurs, basically subsequent interrupts can be recognized?

Yes, that is correct.
Basically, interrupts can be recognized in the status described in your inquiry.

After entering the HALT mode during subsystem clock operation (while the main system clock is stopped), if HALT is released by an unmasked interrupt, vector interrupt processing is performed; is that vector interrupt processing performed with the subsystem clock?

Yes, operation is performed as is with the subsystem clock.
Note that even if the HALT mode is released by an unmasked interrupt, vector interrupt processing is not necessarily performed.
If the CPU is in the DI status, the HALT mode is simply released, and vector processing is not performed.

To operate this vector interrupt with the main clock, is it necessary to input an instruction that makes the CPU clock the main clock at the beginning of the vector interrupt?

No, this does not suffice.
It is necessary to start oscillation of the main clock after releasing the HALT mode, and after the oscillation stabilizes, switch to the main clock.

If an external interrupt occurs during the interval between the start of system operation after reset and when the user program starts running, can this interrupt be acknowledged?

No, it cannot be acknowledged.
After reset registers are initialized to the no interrupt signal and interrupt processing disabled status, so external interrupts cannot be acknowledged immediately after reset.
Please refer to the description of the status resulting from reset input described in the description of registers in the relevant user's manual.

I am designing the system using the uPD78F0034B.
When writing to IF0L by software, what can I do to prevent the flags for other interrupts being cleared?
Is disabling IE of the PSW immediately before writing to IF0L enough?

Unfortunately, the desired processing cannot be realized using the PSW.
In this case, use a bit manipulation instruction (clr1 or set1) to manipulate just the required bits.
By doing this, you will be able to write to IF0L without affecting the interrupt request flags assigned to other bits in IF0L.

The interrupt pulse width in the data sheet is listed as MIN 10μs, but interrupts are acknowledged even with a pulse width of 4μs. Should this be possible?

Yes, it is possible.
The value of 10μs is the pulse width for which interrupt acknowledgment is guaranteed, but this does not mean that pulse widths smaller than 10μs are not acknowledged (however, these pulse width are not guaranteed).

In the uPD784218, an external interrupt is input asynchronously to the internal clock.
At which timing is the external interrupt processing performed?

This depends on the program execution status.
It is impossible to determine the timing exactly.

First, the edge of the external interrupt is detected.
Please consider that the delay in this operation is approximately 10μs maximum.

Next, the interrupt request flag is set, and judgment of the priority level, etc., is performed in 8 clocks. (Refer to Figure 23-43 in the User's Manual.)
During the execution of the instructions described in section "23.9 When Interrupt Request and Macro Service Are Temporarily Held Pending" in the User's Manual, acknowledgment is held pending.
Upon acknowledgment of an interrupt, depending on the operation status (where the program operates, where the stacks are, etc.), branching to the processing of the actual interrupt processing routine occurs after the lapse of the time indicated in Table 23-7.

When the processing is branched from watchdog timer interrupt processing to power-on processing, it becomes impossible to acknowledge subsequent interrupts.

The countermeasure for this is to execute the RETI instruction until ISPR becomes 0.
For the basic method, refer to the program example described in section 23.12 "Returning interrupt function to initial state" in the User's Manual.

In the uPD784038, I want to use the macro service for reception during clock synchronous serial communication, but the main usage examples describe data transfer using clock synchronous serial communication.
I want to perform 1-byte reception, so should I set MSC to 1?

That is correct. Set the data count to be transferred to MSC.

How can I fetch the data loaded using the macro service?

The data received via the macro service is saved to the macro service buffer, so read this data from this location by program.

Does the uPD784214 acknowledge another interrupt request while it is excuting the macro service (from start of macro service to generation of end interrupt request)?

No, it does not.
The uPD784214 acknowledges interrupt requests during some periods of macro service execution, but not during other periods.

A timing chart of macro service processing is shown below.
There are two periods in macro service execution: the period in which transfer is actually being carried out by the macro service (period A), and the period in which the CPU is executing an instruction (period B).
Interrupts cannot be acknowledged in period A, but if interrupt acknowledgment is enabled in period B, interrupts can be acknowledged even during macro service execution.

Serial I/O data transfer is performed using the 78K/4 macro service function.
Is the main program operation affected during this data transfer?

Yes, the macro service is executed interrupting program execution.
For example, in the case of Type A, executing one transfer requires 24 clocks, and during this interval, the CPU program execution is stopped.
When using an 8MHz resonator, the operating clock can become as small as 4MHz, or half.
Thus in the case of 1Mbps, the CPU cannot execute the program in 75% of the time period.

Could you describe how to describe a macro service in C language?

Basically, macro services are not supported in C language.
If this were attempted, one should define a macro service channel with structures and allocate this to the saddr1 area.

Regarding control words, since these addresses are not reserved, define these addresses.
Then the only action needed would be to plug in values for the defined variables.