Nios - control the cache

Scenario:

Custom slave which uses waitrequest and bursts. Memory map: 0x200000 - 0x3FFFFF.

I want to write 256 Bytes to the slave, it's a spi controller so the master (NIOS f) should write the data without doing anything in between, I want to check the status register in software.

Problem: When accessing 0xXXXD00 and 0XXXF00 with memcpy I get the following (doesn't matter if 0xXX1D00, 0xXX2D00 and so on):

I use the following code to write to the slave (Avalon slave):

memcpy((alt_u8*)(mem_base+addr),(alt_u8*)(src_cached_ptr),length);
alt_dcache_flush_all();

avs_mem_xxx is the signal from the master to the slave after the interconnect component. The system is generated in the Platform Designer.

0xD00:

The write is splitted into 3 parts: 1st part and 3rd part happens when I use flush, the 2nd part is written while executing memcpy.

When accessing 0xF00 I get this:

and when writing to any other 0xX00 address with memcpy and 256 Bytes I get the wanted result:

I tried to flush before executing a memcpy:

alt_dcache_flush_all();
alt_remap_cached(src_cached_ptr,length);
memcpy((alt_u8*)(mem_base+addr),(alt_u8*)(src_cached_ptr),length);
alt_dcache_flush_all();

But got the same result (haven't checked all scenarios with this), 0xD00 behaves the same as 0xF00 now.

This src_cached_ptr is a alt_u32* pointer which is passed to this function.

At first I defined the pointer as a pointer to a reserved memory area, afterwards I changed it to a defined array (no dynamic memory allocation). When I do that then 0xD00 and 0xF00 look ok, but 0xE00 looks like the previous 0xF00.

In the BSP Editor and preferences, the optimizations are turned off.

In the Platform Designer:

so no tightly coupled memory, just the zim_qspi_controller (the slave where I want to use the memcpy) and a nios ram (onchip memory) where my heap and stack is allocated.

How can I force the memcpy to write without any interruptions?