Error handling nested interrupts in STM8 (not described in errata)

The STM8 family has a very useful feature for saving energy when interruptions that are fast and critical to processing time are performed by interrupts and low-priority tasks run in the background. To do this, use the AL bit in the GCR register and the WFI machine instruction. However, a pitfall was discovered here that is not described in the current errata version of the crystal.

This problem was detected on the stm8l152c6t6 chip installed on the STM8L-Discovery board.
In the main process, the TIM4 timer was initialized for interrupt operation. The interrupt handler for it is almost empty (well, with the exception of the procedure for resetting the TIM_SR1_UIF bit in the TIM4-> SR1 register). Further, in the main process, writing to the EEPROM was enabled by unlocking MASS, and a procedure for writing a byte with IRQ generation at its end was initiated. Then, the AL bit was set in the GCR register and the WFI command was executed.
In the interrupt handler, upon completion of the write operation in the EEPROM after reading the contents of FLASH-> IAPSR, the priority of the executed code is reduced by the RIM command or the combination PUSH # val / POP CC. Those. Inside the EEPROM ISR, all other interrupts are allowed. And the following was discovered: if the EEPROM ISR was interrupted by another interrupt, then after returning from the nested interrupt, the EEPROM ISR processing stops (that is, it seems that the CPU core enters the WFI state executed by the main process).
This error occurs only if the following conditions exist:

1. Before WFI was executed in the main process, the AL bit in the GCR register was set
2. EEPROM IRQ priority is left by default (i.e. the contents of the ITC-> ISPR1 register are 0xFF)

Possible workarounds:

1. In the main process, before executing the WFI instruction, reset the AL bit in the GCR. At the same time, after each interruption, the main process will resume its execution, which will not have a very good effect on energy consumption.
2. Before lowering the priority inside the EEPROM ISR (i.e., before the RIM or PUSH # val / POP CC commands) also reset the AL bit in the GCR. Again, in this case, after the completion of the EEPROM ISR, the main process will continue its execution, which will not have a very good effect on energy consumption.
3. Change the priority of the EEPROM IRQ in the register ITC-> ISPR1, for example, writing the value 0b11110111 to it. What is most incomprehensible, after that the RIM or PUSH # val / POP CC commands inside the EEPROM ISR start working normally (i.e., after returning from the nested interrupt, the EEPROM ISR processing resumes).

Gentlemen, who have a desire / opportunity, try to reproduce this bug on other crystals of the STM8 / STM8L family. For if this bug is really reproducible, then you need to kick STM to fix it, or at least insert it into the errata sheet.

Received an official response from the ST MCU Support Team:

SOLUTION PROPOSED BY SUPPORTER - 04/05/2017 15:52:59:
- Dear customer,

When an interrupt configure priority level to Level 0 (main), other interrupt executing IRET with AL bit set may put device back to WFI instead of execution of the following instructions of previous code, as a consequence of priority level forced to Level 0 previously.

I recommend to use rather SW priorities than using RIM in the interrupt routine.

Best regards,
ST MCU Support Team