Jump to a label after a RETI

Emilien BENHARD said:

Does someone know C langage tips to do that?

Interrupt functions are outside the scope of the C language, and jumping around in the code may lead to unpredictable behavior.

However, an interrupt that leads to an LPM state can be done. But not in the way you think.

Normally, when an ISR is entered, teh GIE bit is clear and this ISR cannot be interrupted. If precautions are tagen to avoid endless ISR loops and stack overflows, one may set teh GIE bit inside an ISR and allow further interrupts (even for the same ISR interrupting itself, one of the pitfalls) and then you may even enter LPM inside this ISR without ever returning to main. However, the logic to handle this and prevent endless recursions is quite complex.

You surely have two different causes for entering and leaving LPM. Best case are two different ISRs, but even inside one it is possible.

Some symbolic code here:

volatile char inLPM = 0;

ISR 'go into LPM':
[...]handling of interrupt cause (IFG bits must be reset before proceeding)
if(!inLPM)
{
  deactivate hardware
  inLPM=1;
  _BIS_SR_register(LPM3_bits|GIE)
}

ISR 'reactivate device'
if(inLPM)
{
  inLPM=0;
  LPM3_EXIT();
}

After exiting LPM3 in the reactivate ISR (which might be the same as the 'go into LPM' ISR) code execution is continued in the previous instance of the 'go into LPM' ISR, which was suspended into LPM3 before. This ISR will then exit to main. However, if your main code might have problems with the temporarily deactivated hardware, you should also set a global 'bail_out' flag and implement a check for it into your main code, so it knows that the hardware was deactivated and maybe the expected program flow has been compromised (e.g. ADC conversions invalid, serial transmissions timed out or were interrupted mid-byte etc.)

Or you never return to main at all, triggering e.g. a watchdog password violation when the device shall wakeup again, so the complete main is restarted. (of course your main code shoudl detect this by checking the WDTIFG bit, and reset it, so it doesn't re-init the RTC as if it were  real power_up).