Interrupts

What kind of operations occurs in interrupt servicing, and what points should I note?

[Introduction]
The basic operations of interrupt servicing are broadly carried out by 4 parts.

The first part is the part that generates the interrupt source, the second part is the interrupt request flag, the third part is the interrupt controller that controls the interrupt, and the fourth part is the CPU that actually executes the interrupt servicing.
An interrupt is serviced via these 4 parts.




[Interrupt source generator]
Parts that generate interrupt sources include the timer block, serial block, and external signal edge detector (these parts differ depending on the device).
Once an interrupt generation 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 stage of interrupt servicing 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. When an interrupt source is used as a DMA start source, a request flag other than the interrupt request flags described above is used. During a DMA transfer, these interrupt request flags are set (to 1), so interrupts should be masked to prevent unnecessary interrupt servicing.

[Interrupt request flag]
In this way, each interrupt source simply sets the corresponding interrupt request flag; the interrupt source generator 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 single 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 servicing program. The interrupt servicing 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 information on the transmit data to the interrupt servicing program and the interrupt request flag is set. All of the processing to actually write data to UART is carried out by the interrupt servicing 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.
In particular, when the interrupt is used as a DMA start trigger, it is necessary to clear the interrupt request flag (to 0) after the DMA operation is completed.

Unmasked interrupt requests are sent to the standby controller and are used for releasing standby.

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, interrupt servicing is executed after standby is released and control branches to the corresponding handler address.

Interrupt request flags can be used in the following three ways. They can be polled (read out) by the program to check whether the processing that prompted the interrupt request is completed. In this case, set the interrupt mask to ensure the interrupt is not sent to the CPU. After confirming that an interrupt mask has been set, the interrupt request flag must be cleared by separate processing. 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 servicing is not performed after standby is released, and execution resumes after the standby instruction. The interrupt request flag must be cleared by separate processing since it is not cleared automatically. 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. In this event, it is not necessary to clear the interrupt request flag by program, since it is automatically cleared after the CPU acknowledges the interrupt and control is branched to the handler.

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.

This is why the status of the interrupt currently being processed by the CPU is stored to the ISPR register.
Once this interrupt servicing is completed and a RETI instruction is executed, the bit in the ISPR register that corresponds to the interrupt with the highest priority is cleared (to 0) and the current interrupt processing is completed.
Note that the ISPR register cannot be written by program.
In V850/S products, the operation of the interrupt priority circuit is stopped when the CPU is in the interrupt-enabled state.
Consequently, even when the CPU status is switched from the interrupt-disabled state to the interrupt-enabled state, interrupt signals are not issued to the CPU immediately.
Interrupt request signals are not issued to the CPU until the priority comparisons have been completed.
Therefore, any interrupts cannot be acknowledged if the interrupt-enabled period is 7 clock cycles or shorter.

Caution
Bits that control the interrupt priority levels and interrupt masks are assigned to the same registers as the interrupt request flags.
Therefore, if bit manipulation instructions are not used to control the manipulation of interrupt masks, interrupt request flags that have been set may be cleared by such mask manipulations.
Similar caution must be taken when manipulating interrupt priority levels.

Refer to the following FAQ item for further discussion of this issue:

Interrupts and manipulation of the interrupt control register [All V850]

< 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 EIPC and EIPSW registers respectively, and the control branches to the interrupt handler. At this time (when the corresponding interrupt request flag is cleared), the CPU enters the interrupt-disabled state.

Since there is only one set of EIPC and EIPSW registers, when using multiple interrupts, the contents of these registers must be saved (such as to a stack) before enabling interrupts. Before recovery from interrupt servicing, acknowledgment of multiple interrupts must be prohibited and the EIPC and EIPSW values that were saved (to a stack, etc.) must be restored.

Note that the timing at which the CPU acknowledges an interrupt and branches to the interrupt handler differs depending on the execution state, so it is not always the same.
This timing varies greatly if an instruction that holds an interrupt pending is executed, or if there is a period in which interrupts are disabled.
Consequently, if detailed timing is an issue, you should use hardware functions such as the timer output function or real-time output function instead of interrupt servicing.

Once interrupt servicing is completed, the program returns to the original processing via the RETI instruction. At this time, the PSW value that has been saved to the EIPSW register (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.

I want an external interrupt to occur but the interrupt request is not acknowledged.
The ID bit of the PSW is set to 0, the interrupt request is reset, and interrupt processing is enabled.

Possible causes are as follows: - A mask is set for the interrupt (bit 6 of the interrupt control register is set).
- NMI processing is in progress (the NP bit of the PSW is set).
- Processing of a higher priority interrupt is in progress (check using the ISPR register.)
- Consecutive instructions that do not acknowledge an interrupt exist.

Check the PSW, ISPR, and the interrupt control register.

INTP0 is set as shown below but no interrupt is generated.

  P0   = 0x00;
  PM0  = 0x02;
  EGP0 = 0x00;  /*Interrupt rising Edge specification*/
  EGN0 = 0x00;  /*Interrupt falling Edge specification*/

With this setting, the edge detection would not generate an interrupt at both the rising and falling edges.
To use INTP0, bit 1 of EGO0 or EGNP0 must be set.

I want to perform interrupt processing (maskable) but control does not branch to the interrupt program.
Although the EI instruction is executed, NP = 1 and ID = 1.

The possible reason of NP = 1 may be one of the following:
- An NMI has been acknowledged.
- The PSW has been rewritten by the LDSR instruction.
- The value set in EIPSW when returning from a maskable interrupt is incorrect.

Does control branch to the initialization processing during the interrupt (NMI) service, resulting in re-initialization?
During interrupt servicing, the status is recorded to flags (NP bit or ISPR.ISPRn bit), and this status is retained until a RETI instruction is executed.
Interrupts cannot be acknowledged as long as these flags hold the status.

Also refer to the following FAQ items:
  Initialization during interrupt service [All V850]
  Initialization with watchdog timer interrupts [V850/SA, V850/SB]

In the User's Manual, there is a description saying,
Are interrupts disabled in this period (7 clocks)?

No. The description means a period in which the CPU does not perform interrupt acknowledgement (sampling).
That is, you should understand that a non-sample instruction and the next instruction are always executed in succession. [All V850]

(This 7-clock period refers to the period from the time an EI instruction is executed in the DI state to the time the CPU is enabled to acknowledge an interrupt.
It has no relation to interrupt disabling.) [All V850/S]

TM0 is used as an interval timer.
After startup, an interrupt occurred only once.
Is this because the RETI instruction was not executed at the end of the interrupt?

Yes it is.
Judging from the contents of your question, the reason for this phenomenon may be, as you mentioned, that ISPR is not reset because RETI has not been executed.

In V850 devices, up to 8 priority levels can be set, and these settings are controlled in the ISPR register.
This 8-bit register consists of 8 bits that correspond to each priority level, and when an interrupt is acknowledged, the bit corresponding to that interrupt's priority level is set (to 1).

Once a bit in the ISPR register is set, only the interrupts with a priority level higher than the set bit are acknowledged.
When a RETI instruction is executed at the end of the interrupt servicing to exit interrupt servicing, the bit that corresponds to the highest-priority interrupt among all of those set to 1 in the ISPR register is cleared to 0.

Since the priority levels of interrupts are controlled in this way, a RETI instruction must be executed to end interrupt servicing.

In the manual, there is a description saying,
When an individual interrupt occurs, is the corresponding processing program placed at the relevant address?

Yes, it is. The addresses are used as you say.
However, in almost all cases 16-byte processing is not possible, so a branch instruction should be placed here to enable a branch to the interrupt handler that actually services the interrupt.

Is it all right that up to 16 bytes are used for the handler address part?

A 16-byte space is reserved for each handler address, so this much space can be used.
If less than 16 bytes are all that is needed, the address ends there.
If more than 16 bytes are needed for the processing, the rest of the processing beyond 16 bytes is assigned to a different space and there is no problem in branching to that space.
However, it should be noted that another register is used for this.

Do I have to keep the table area corresponding to unused interrupts free?

No, you don't.
This memory area is reserved only for interrupts.
If you do not use an interrupt, the corresponding area can be used as a normal memory area.

The V850E/MA1 interrupt function is set so that an interrupt will be generated at both edges (rising and falling edges).
To determine whether it is a rising edge or falling edge during interrupt processing, do I have to check the status of the port?

Yes, that is OK.
In V850 devices, when a pin is used for an alternate function, the pin status can be read as the input port status.
However, in such cases the input port status must be set via the PM register.
(No additional setting is required for the V850/S, because any pin that has the external interrupt function alternately is surely set to input when it is used for the external interrupt function.)

The seventh bit of PORT0 is used for external interrupt request input.
In interrupt processing, to read the signal that was input to this pin from P07,
I first set PMC07 to the I/O mode then set PM07 to the input mode.
Then I tried to read the contents of P07, but I could not read the correct value.

Because you first set PMC to the port mode, the output buffer became ON and a pin conflict occurred.
This may be the reason why you could not read the contents of P07 correctly.
To check the status of an external interrupt, you have to set PM07 to input.
Read the port in this state.

With an external interrupt, can an interrupt be generated by detecting the level?

The V850E/MA1 features a low-level level detection function.[V850E/MA1]
In any other device, interrupts cannot be generated using the level.

However, a function that approximates the desired function can be implemented by reading the interrupt input signal state via a port.

To perform interrupt servicing with active level low:

	(1)	Set the port mode to input by setting the PM register.
	(2)	Set the falling edge for the detection edge.

When an edge-trigger interrupt is acknowledged:

	(3)	Perform the necessary processing by the interrupt.
	(4)	Before exiting the interrupt servicing, read the port to check the interrupt pin status.
	(5)	If the pin is at high level, quit exit the interrupt servicing.
	(6)	If the pin is being held at low level, set the corresponding interrupt request flag (to 1) and then exit the interrupt servicing.

Since the interrupt request flag is set in step (6), another interrupt can be acknowledged after recovering from this interrupt service.
This approach seems to approximate the desired level-triggered interrupt type of function.
[All V850 products except V850E/MA1]

Port P22 (INTP021) is set as a falling edge by the external interrupt setting, but no interrupt request flag (P021F1) is set.

To use INTP021, you have to set TMCCAE2 of the TMCC20 register.
Try adding this setting.
This point is described as a note in the section regarding the valid edge selection register (7.3.9 "Interrupt Trigger Mode Selection") in the latest User's Manual.

How can I use the exception for a V850 illegal instruction code?

In V850 devices, a certain combination of instruction codes that have no assigned instructions is considered as an illegal instruction code.
(The matter of which code is considered as an illegal instruction code varies depending on the CPU core. Refer to the "Exception Trap" section in the Architecture User's Manual for the core being used.)

When an instruction corresponding to this code is executed, an exception trap occurs and control branches to the handler at address 60H, which has been set up to handle illegal instructions.
An illegal instruction code is embedded in an unused memory area, and it can be used to detect operation faults in the system.

Note with caution that this method covers nearly all undefined code but not all of it.

I would like to use transmit interrupts to perform half-duplex communications with UART.
When should the first interrupt be inserted in order to start transmitting? [V850ES/KF1]

That type of timing interrupt is not used.
Basically, an interrupt occurs in serial communications when a communications session is completed (in this case, at the first STOP bit). [Almost all V850 models]

To use an interrupt to start a transmission, the corresponding interrupt request flag could be set by a program.
When using this method, be sure to confirm that no data is being transmitted before setting the interrupt request flag.

For further description, refer to
"Timing of UART transmission interrupts [V850ES/Kx1, etc.]"
in the FAQ section "Serial Communication."

In a V850/IA2 device, I would like to issue a high-priority interrupt while servicing of a timer interrupt through multiple interrupt processing.
The timer interrupt function includes a multiple interrupt declaration (_multi_interrupt), but it does not seem to be working.
It is programmed to service the high-priority interrupt after the timer interrupt service has been completed.

Multiple interrupt declarations are used only to prepare for handling of multiple interrupts (in addition to normal interrupt servicing, this includes saving information such as return addresses saved to EIPC and EIPSW).

Since the correct timing for acknowledging multiple interrupts differs among different systems, in this case "__EI();" should be used to enable interrupts, via the timing by which multiple interrupts are enabled.
If this is overlooked, the problem you refer to will occur.

Also, when quitting an interrupt function that includes such a multiple interrupt declaration, interrupt-disabled status must be set.
Therefore, first execute __EI(); then execute __DI(); before terminating the interrupt.

Interrupts A and B have the same priority level and other interrupts are prohibited while interrupt A or B is being serviced.
In this case, if interrupt B occurs while interrupt A is being serviced, will interrupt B be held pending?

Yes, interrupt B will be held pending.

Interrupt B occurs while interrupt A is being serviced, and then interrupt A occurs again.
In this case, are both interrupt B and the second interrupt A held pending while the first interrupt A is being serviced?
After that, is interrupt B serviced and then interrupt A?

No, when interrupt A and interrupt B are both held pending, the one with the higher default priority will be acknowledged first.

When interrupt A is being serviced, if the same interrupt (A) occurs twice more, are the second two interrupts held pending and then serviced later, so that all three interrupts are serviced one at a time?

No, only two interrupts would be serviced in this case.
Since the interrupt request flag for interrupt A is a single-bit flag, it can only record whether or not an interrupt request has been issued.
When an interrupt is acknowledged, this flag is cleared (to 0), and afterward it can record only one interrupt until it is cleared again.
Therefore, if interrupt A occurs again more than once while another interrupt A is being processed, the second and subsequent occurrences will be ignored.

When the V850E/MA1 is used in single chip mode 0, the interrupt handler address is 0 to 0x360.
What is this address when in single chip mode 1?

The handler address is the same for single chip modes 0 and 1.
Accordingly, you should write the interrupt handler to the corresponding address in externally connected ROM.

This concerns V850E/MA1 with externally expanded I/O.
For external word access, the access method uses two 16-bit accesses per word.
Can any interrupts occur between the first and second 16-bit access?

No, interrupts basically do not occur at any time during the execution of an instruction.
The bus is locked during the twice 16-bit access, so no other cycles can be inserted.

I am using INTP1 interrupts.
During the processing shown below, I manipulate the PIC1 register to set masking and priority levels, but sometimes an interrupt does not occur.

   if (condition){
         pic1 = 0x02;    /* Normal status */
   }
   else {
         pic1 = 0x47;
   }

This is because the interrupt request flag, mask flag, and priority level settings are all assigned to the PIC1 register, and whenever a write operation occurs in the PIC1 register, the PIF1 bit (interrupt request flag) is also overwritten (cleared to zero).
Consequently, any interrupt request that was held pending (i.e., set to "1") is cleared during this write operation and the corresponding interrupt does not occur.

To avoid this, use timing for manipulating the PIC1 register that is not synchronized with interrupt timing (such as immediately after an INTP1 interrupt occurs).

Also, use a bit manipulation instruction that changes only one bit at a time.

When using a mask bit in the interrupt control register to enable or disable interrupts, if an interrupt request occurs while switching from interrupt-disabled state to interrupt-enabled state, will the interrupt be held pending and then executed when the interrupt-enable state is set?

When 8-bit access is used to clear masks (such as when a C program does not directly manipulate bits in the interrupt control register but expands to multiple instructions), any interrupt request up to that point is deleted.

When direct bit manipulation is used to clear masks, interrupts that have been requested before then are acknowledged once the mask has been cleared.

One way to jump from within an interrupt to the start of a program (for initialization) is to set dummy values to the EIPC and EIPSW registers and use a RETI instruction to jump.
Sometimes, the level of the previous interrupt is held so that no other interrupts can occur.

Perhaps this is because of multiple interrupts.
If so, executing one RETI instruction will clear only the bit in the ISPR register that corresponds to the highest-priority interrupt.
To handle multiple interrupts in this case, an RETI instruction must be executed repeatedly until the ISPR register value becomes 00 (all the bits cleared).

Also refer to the following FAQ item:
  Initialization with watchdog timer interrupts [V850/SA, V850/SB]

I am using the INTPn pin as a port, and am using software to trigger INTPn interrupts (by setting an interrupt request flag).
There is no triggering by external input.
Will INTPn interrupts function properly when using this method?

Unless there is edge detection of the INTPn pin, changes in the INTPn pin status cannot trigger interrupts.
There is no problem with software triggered interrupts in this case if the interrupt request flag is manipulated accordingly.