ESP8266 exceptions, what is the cause?

I just want to know the reason for the following exception so I can find what is causing it.
The project was on hold for a month or so and when I left it I checked in the code and the last flash binary to SVN.
Now when I restarted work it turns out that if I load the head flash image from SVN into the hardware (ESP-07) it constantly reboots after running the setup code with a number of debug port messages I have put there.
But towards the end of setup() it runs into an exception and it is not at a constant place.
The execution reaches different points before rebooting...
I have cut out the first piece of debug code from the ESP:

Fatal exception 28(LoadProhibitedCause):
epc1=0x40208110, epc2=0x00000000, epc3=0x00000000, excvaddr=0x00000000, depc=0x00000000

Exception (28):
epc1=0x40208110 epc2=0x00000000 epc3=0x00000000 excvaddr=0x00000000 depc=0x00000000

This always happens when the exception is triggered. What exactly does the "LoadProhibitedCause" mean?
The code uses 3 tcp services and stores config data in EEPROM and SPIFFS.
Any ideas?
BTW: If is retrieve the flash binary from earlier revisions in SVN there are no exceptions, so I must have been doing something really bad the last time I worked on it...

Maybe these excellent ESP8266 trouble shooting guides (from the Core Documentation) get you further:

https://arduino-esp8266.readthedocs.io/en/latest/faq/a02-my-esp-crashes.html

https://arduino-esp8266.readthedocs.io/en/latest/exception_causes.html

You'll see there an expansion of your "LoadProhibitedCause".

Thanks!
The first document is a debugging guide and I guess I have a different case than the examples there...

The second document had this on the exception itself:

28     LoadProhibitedCause     A load referenced a page mapped with an attribute that does not permit loads     Region Protection or MMU     Yes

What I don't understand here is what the page and its attribute are....
Any suggestions? Does it pertain to SPIFFS pages or EEPROM pages or what? I use both, but I think SPIFFS was not enabled in the binaries I have saved before the last one.
And there I don't get exceptions.

I can't really help on the further interpretation of the error message, but page in this context will be a unit of memory. I could imagine something related to loading a cached page into ram, but that is just a guess.

I think you simply have to revert to a working version of your sketch and add code until it breaks. Issues to watch for which cause mysterious crashes include allowing code, which should remain in RAM (ISRs / callbacks etc.), to be cached.

Yes, I have to master how to compare SVN repo revisions against the working copy.
I am on command line in Windows for SVN... In CVS, which we used before, there was a WinCVS program that helped with that. But I digress...
There are only so much in between the working binary revision and the head.
I was busy trying to calculate a correct value to run deep sleep with in order for it to wake up exactly on time when I left the project before. So when committing I did not include the flash binary to save space, and therefore I don't know what actually broke the sketch. But probably the diff between the head and previous revisions.

It sounds like development methodology could also be a factor here. Everyone has their own way of developing a sketch. I now use Sloeber (Eclipse) but I started this method with the Arduino IDE.
Create a sketch and name it with a suffix v0.01. In the sketch folder are also all modified library files etc.
After modifications and testing, simply save the whole thing (save_as option in the IDE, a cut and paste operation is Sloeber) , incrementing the version number and maintaining a version history in the sketch. I don't expose myself to complexities of external source management systems and the like and have always something I can go back to.
Of course, that does not preclude a library update or similar rendering the whole thing unusable, but that is another issue.