Delay when writing to SDRAM?

[MichalKv]

Hello,

I'm experiencing strange behaviour while using MIMXRT1176 MCU.

The M7 core is running from RAM, the M4 core is running from SDRAM. I have a custom board and we're using IS42S32160F-6BLI SDRAM. Due to the fact the mamory has different timings and parameters in comparison with the original SDRAM from MIMXRT1170-EVK board I initialized the SEMC for the memory like this (It's running at frequency 167MHz so it should be mode '-6'):

status_t BOARD_InitSEMC(void) {
	semc_config_t config;
	uint32_t clockFrq = CLOCK_GetRootClockFreq(kCLOCK_Root_Semc);

	memset(&config, 0, sizeof(semc_config_t));

	SEMC_GetDefaultConfig(&config);
	config.dqsMode = kSEMC_Loopbackdqspad; /* For more accurate timing. */
	SEMC_Init(SEMC, &config);

//@formatter:off
	semc_sdram_config_t	sdramConfig = {
		.csxPinMux = kSEMC_MUXCSX0,
		.address = (uint32_t)M4_BOOT_ADDRESS,
		.memsize_kbytes = 16 * 4 * 1024,
		.portSize = kSEMC_PortSize32Bit,
		.burstLen = kSEMC_Nor_BurstLen8,
		.columnAddrBitNum = kSEMC_NorColum_9bit,
		.casLatency = kSEMC_LatencyThree,
		.tPrecharge2Act_Ns = 18,
		.tAct2ReadWrite_Ns = 18,
		.tRefreshRecovery_Ns = 70,
		.tWriteRecovery_Ns = 12,
		.tCkeOff_Ns = 42,
		.tAct2Prechage_Ns = 42,
		.tSelfRefRecovery_Ns = 70,
		.tRefresh2Refresh_Ns = 60,
		.tAct2Act_Ns = 60,
		.tPrescalePeriod_Ns = 160 * (1000000000 / clockFrq),
		.refreshPeriod_nsPerRow = (64 * 1000000) / 8192,
		.refreshUrgThreshold = (64 * 1000000) / 8192,
		.refreshBurstLen = 1,
		.delayChain = 0,
	};
//@formatter:on

	return SEMC_ConfigureSDRAM(SEMC, kSEMC_SDRAM_CS0, &sdramConfig, clockFrq);
}

I feel like the timings should be right after checking even tho I still don't understand the purpose of some of them. 

I also use the SDRAM for a shared memory between the cores. However I'm experiencing a delay between M4 writing data -> M7 receiving data. I'm handling the receiving with a polling method so basically the program goes like:

1. M7 Starts M4 core
2. M7 Waits until M4 core sends 'ready' event (MCMGR event just after M4 wake up)
3. M7 and M4 continues in initializing some things
4. M7 waits until M4 sends 'start calculation' event which is send after I wrote everything into the SDRAM
5. M7 reads the data and start calculation -> the core has no parameters
6. The program goes on and after three cycles the M7 tries to read data and they are finally ready

I found out the data are avaliable since 3rd cycle at the time I'm trying to read the data by the M7 core. I'm thinking the memory probably gets the 'read/write' commands but the SEMC isn't waiting for them so they're ready next time.

But I'm wondering why is that a case? Am I supposed to make a delay on purpose to get the data because the SEMC isn't build for handeling it? What's the right solution because I ran out of them and I don't think infinite loop for miliseconds is the right solution.

In forward thanks for any idea you provide!

Update #1

It kinda feels like it also might be a bug in a debugger? I'm using SEGGER J-link and it seems like when I stop the program right after it was supposed to read from memory, the data aren't here but when I just let the program run it looks like the data might be there in a normal run but that also might be just the fact the processor speedruns the first three iteration and then the data arrive. The question is how to prove which of the behaviour is it? 

Update #2

By using :

DCACHE_InvalidateByRange( ... );

 on the data sector inside the SDRAM (because beside data the M4 core is running on the first addresses) I managed to faster the SEMC write/read process so now it waits "only" 2 loop cycles. So, any idea how to make it wait 0 cycles?

[MichalKv]

Update #3

I would also accept if there's some way how to wait for the data to be ready. I found out there should be some "wait pin" that SEMC used but I can find barely anything about it in the MIMXT1170 reference manual. 

Basically in my application the M4 is acting like a master and whenever M4 is doing something with the data, M7 have to wait/stop and wait for the new data anyway so something like waiting for a pin/status or anything like that is okay.

Right now it's still pretty unstable, sometimes it waits 0 cycles, sometimes 1 or 2 cycles.