You don't tell us much about the program that is triggering these faults - what language it was written in (we assume C or perhaps C++), or whether you are using a RTOS.
My first suspicion would be your software, but it is possible that it is a "hardware" issue - glitches or brown-out on power-rails, ESD events; clocking too fast for a given supply-voltage + FLASH-wait-state combination. Do revisit that and check the errata. And double-check that you have adequate power-supply-decoupling capacitors immediately adjacent to every Vdd, Vss pair. Violate the data-sheet's "operating conditions" and all bets are off...
I see all returnAddr you show seem to be in FLASH (0x080yyyyy).
A major trouble is that the software bug (if there is one) might cause corruption of a bit of memory that is used elsewhere (perhaps a return-address on a stack, or the address of a variable stored in a pointer); only when you use that now-corrupt value does the exception occur so it might not give you an immediate clue as to what's going on until you notice that this value is just after the end of a buffer that is overflowing.
If software, and you're using C/C++, then it is very easy to slip up in memory handling.
Does your code use dynamic memory (malloc/calloc/free; new/delete)? If so, how do you handle the inevitable case when memory-fragmentation causes an allocation to fail. You do check for out-of-memory on every allocation, don't you? How do you recover?
Of course your PEG library might do such allocations, hidden from you. Assuming there are no lurking bugs in there, you do check their replies every time as well? Is PEG thread-safe, or are you sure to only call it from one thread?
And what about passing a pointer to an automatic variable (allocated on the stack) that goes out-of-scope as soon as you return from the subroutine?
Or accessing beyond either end of an array?
Are you sure you give enough space for each and every thread's stack? (Do you ever allocate variable-sized-arrays on a stack?)
Of course you need good version-control so you can be sure that the version of source-code you're looking at is the version that caused the exception!
But no this kind of post-mortem is not easy in my opinion.
