MCU RAM - Why accessing RAM across the boundary causes Bus Fault?
Turbo J's answer is most likely correct, but I wanted to clarify what's going on with the RAMs and show you how to find this information in the documentation.

There are three RAM blocks on your MCU. The first is the program RAM (PSRAM). As is stated in the XMC4000 MCU reference manual's introduction (section 1.3):


  Code RAM (PSRAM)
  
  The Code RAM is intended for user code or Operating System data storage. The
  memory is accessed via the Bus Matrix and provides zero-wait-state access for the CPU for code execution or data access.


So the RAM is "intended" for program code, and (according to section 25.2.5) there's a special option to boot from PSRAM, but you can use it for whatever you want.

From the introduction again:


  System RAM (DSRAM1)
  
  The System RAM is intended for general user data storage. The System RAM is
  accessed via the Bus Matrix and provides zero-wait-state access for data.
  
  Communication RAM (DSRAM2)
  
  The Communication RAM is intended for use by communication interface units like the USB and Ethernet modules.


Now again, it says "intended", but elsewhere the document suggests that the RAM blocks are mostly interchangeable. Section 2.3.3 says:


  The Code, SRAM, and external RAM regions can hold programs. However, it is
  recommended that programs always use the Code region. This is because the processor has separate buses that enable instruction fetches and data accesses to occur simultaneously.


This is talking about the ARM ICode and DCode interfaces. I'm not an expert on those, unfortunately, but basically it's a Harvard architecture.

ARM has posted the Cortex-M4 TRM online. It explains a helpful property of the DCode bus:


  Control logic in this interface converts unaligned data and debug accesses into two or three aligned accesses, depending on the size and alignment of the unaligned access. This stalls any subsequent data or debug access until the unaligned access has completed.


According to another ARM TRM page, this comes with limitations:


  Unaligned accesses that cross memory map boundaries are architecturally Unpredictable. The processor behavior is boundary dependent, as follows:
  
  
  DCode accesses wrap within the region. For example, an unaligned halfword access to the last byte of Code space (0x1FFFFFFF) is converted by the DCode interface into a byte access to 0x1FFFFFFF followed by a byte access to 0x00000000. ...
  


Now, let's go back to the MCU reference manual one more time to see what the memory regions are on this particular implementation:


  


It lines up perfectly with the ARM example! (That's pretty common, actually.) So an unaligned access at 0x1ffffffd/e would wrap around to 0x00000000. What's at that address? The MCU reference manual's memory map comes to the rescue:


  


It's the boot ROM! If I had to guess, I'd say that writes to the boot ROM address space probably trigger an error. (Section 7.4 of the manual suggests it's an Unsupported Access Mode error.) You can experiment and find out if you'd like. Anyway, the moral of this story is: don't make your linker sections cross memory regions! (Ideally, put them in the RAM they're "intended" for.)

This stuff about unaligned accesses and memory regions is not as straightforward as one might like, but these are the sorts of things you have to deal with when using a high-end microcontroller. When in doubt, it's best to follow the manufacturer's recommendations for what goes where in memory.