Interrupt response time depends on the state of the CPU when the interrupt occurs. Pending interrupts are sampled and priority decoded on every system clock cycle. Therefore, the fastest possible response time is 5 system clock cycles: 1 clock cycle to detect the interrupt and 4 clock cycles to complete the LCALL to the ISR. If an interrupt is pending when a RETI is executed, a single instruction is executed before an LCALL is made to service the pending interrupt. Therefore, the maximum response time for an interrupt (when no other interrupt is currently being serviced or the new interrupt is of greater priority) occurs when the CPU is performing an RETI instruction followed by a DIV as the next instruction. In this case, the response time is 18 system clock cycles: 1 clock cycle to detect the interrupt, 5 clock cycles to execute the RETI, 8 clock cycles to complete the DIV instruction and 4 clock cycles to execute the LCALL to the ISR.
The interrupt response time also depends on different pre-conditions, such as system clock, prefetch setting, push operation in the interrupt handler function, etc.
Detail about the push process introduce as below.
Push stack operation is at the beginning of interrupt handler function, and it has strong relation with the complexity of ISR. Each push will require additional clocks before the ISR code starts executing.
If the special function registers (SFR) will not be used in the interrupt handler function, there is no need to do any stack push operations. Figure 1.1 / 1.2 show an example about push operations. In this example, there is only CPL P1.4 process in the demo code’s interrupt handler function (Figure 1.1), so the compiler does not need to do any push operations at the beginning of ISR. However, the push operation is necessary in Figure 1.2 because the code uses the core SFRs ACC/B/PSW.
Figure 1.1 Without any push stack process in interrupt handler
Figure 1.2 Push stack process in interrupt handler
In order to ensure the stability of the Interrupt Latency measure results, strict pre-conditions should be suggested, such as placing the CPU in idle mode before interrupt response, the fewest push operations in the ISR and the corresponding prefetch setting.
In some instances, especially on EFM8 devices with low-power modes (such as the EFM8SB1, EFM8SB2), a device may seem to be unrecoverable through the normal debug interface. Attempting to program or erase the device may give an error:
" 'Erasing flash' has encountered a problem.
TCF command failed"
It is often the case that the debugger built into the STK cannot recover these devices, but a legacy 8-bit debug adapter can. First, make sure to disable the on-board debugger on the STK by going to [Launcher] and selecting [Debug Mode]>[Off].
Then, connect the debug adapter to the C2 pins found on the upper right corner of the STK. It will be necessary to connect C2CK, C2D, and GND to the debug adapter.
Note: It is not necessary to connect all ground pins from the debug adapter to the STK, only one will be required.
Next, download and run the Flash Programming Utilties. After connecting to the device, an erasure should be able to recover it.
After recovering the device, the debug mode of the board can be set back to [MCU] to continue using the STK within Simplicity Studio.
To prevent this from occurring in the future, it is recommended to add a very long delay after reset (> 200ms) when running programs that utilize low power modes such as Sleep or Snooze. Other methods that cause the device to exit these low power modes and stay in either Idle or Active modes will also allow the STK to again communicate to the device.