INVPC Hard fault exception error

There are a number of possible reasons for this fault.  For example

1) Invalid value in EXC_RETURN number during exception return.
For example,
"¢ Return to thread with EXC_RETURN = 0xFFFFFFF1
"¢ Return to handler with EXC_RETURN = 0xFFFFFFF9
To investigate the problem, the current LR value provides the value of LR at the failing exception return.

2) Invalid exception active status. For example:
"¢ Exception return with exception active bit for the current exception already cleared. Possibly caused by use of VECTCLRACTIVE, or clearing of exception active status in NVIC SHCSR.
"¢ Exception return to thread with one (or more) exception active bit still active.

3) Stack corruption causing the stacked IPSR to be incorrect.
For INVPC fault, the Stacked PC shows the point where the faulting exception interrupted the main / preempted program. To investigate the cause of the problem, it is best to use exception trace feature in ITM.

4) ICI/IT bit invalid for current instruction.  This can happen when a multiple-load/store instruction gets interrupted and, during the interrupt handler, the stacked PC is modified.  When the interrupt return takes place, the non-zero ICI bit is applied to an instruction that do not use ICI bits.  The same problem can also happen due to corruption of stacked PSR.

regards,
Joseph

It is hard to guess what went wrong from the limiting information.

It would be useful to see the value of the stacked PSR, which might show which handler is the last executed ISR.
Also you should check the SP values to see if they are in correct memory space.

Could you clarify
"The return PC points to the instruction that tried to set the PC. "
What instruction is it? Is it a instruction withing exception handler?

If you are using KEIL tool, there is a feature that allow exception trace via ULINK2.
I don't know if there is similar feature in IAR tool.

Just seeing the register values at the starting of hardfault handler is not enough.
You also need to find out the register values that are pushed to the stack as
it enter hardfault handler.

The value of R4 might not mean anything.  The program could have gone wrong
for a number of cycle before entering hard fault, and load this value as a literal
data accidentally. I don't know about the IAR function __iar_Tls_dtor__Isdst_rules.
Have you contact IAR support about this? They might be able to help.

Have you try to find out if IAR tool got exception event trace?
If not, define a couple of global variables that work as a shift register to record the last couple of exceptions.
This might help locate the problem.

Are you using really Process Stack?
Another possible issue is that the Main Stack Pointer and the Process Stack Pointer values are quite close.
Are you sure they haven't got overlapped by mistake?