Hi Marco
I don't see the actual problem/error but I find that the code is rather difficult to understand (and verify) due to the fact that you have written it in a way that demands that the user pass the exact number of bytes to program, rounded to the the programming size, rather than doing it in a generic manner that allows the user to not need to know this information and thus avoid potential mistakes).
This, for example, is over-complicated and dangerous:
#define APP_MEMORYSIZE_UINT8 (8*(1+(sizeof(App_Memory)-1)/8))
since if you change your App_Memory size it will cause one more or one less phrase write to be made. A one-off error will lose you 8 bytes or not, which is similar to the issue that you have since if you increase App_Memory size with dummy bytes it indeed solves your issue. When I calculate the value in my head it seems to be OK, but it is a bit cryptic and begs for errors to be made.
If someone were to pass a non power of 8 length to your Flash_writeBuffer() routine it would also hang, so my advice is to allow the user to simply pass the same of the data to be written and you can pad and dangling bytes to the programming size and thus avoid such risks. or to 4 bytes if you use the same code on a device with long-word programming instead (portability).
In addition, I would protect just the low level writes and erase form interrupt rather than the complete loops - this will avoid clocking other interrupt driver services for unnecessary long times during such use.
I expect that if you clean up the method so that it automatically handles/manages the HW restrictions in the low level code you will probably find that such problems automatically disappear to and also don't come back later when you change something using it.
Regards
Mark