Stm32F427 with external SDRM and external NOR flash. 2mB of SDRAM is used as frame buffer for LCD. this is a working system. In some faulty bords, the system misbehaves.

[Johanan1]

In particular, I can see random white dots on LCD when external NOR flash is written, like writing in the flash somehow influence the frame buffer. Testing RAM for error passes OK, same is when I test NOR flash write and verify. I searched for a problem for too long. Any ideas will be appreciated. (The problem is in about 5% of the boards. in normal life I just ignore such problems and put it away, but these days, chips are hard to find and extremely expensive).

[MM..1]

If your LCD uses read from NOR Flash, and your code too write here, some conflict on bus can occur.

Too memory mapped NOR Flash can only read , no write etc. Try show image and why you write and ...

[JPeac.1]

When you write to the NOR, jhow do you determine when write is complete? Does the NOR IC have a WAIT/BUSY pin connected to a GPIO, to the WAIT FSMC pin, or do you poll the NOR looking for status? Does SDRAM and NOR share a common WAIT line? You might be seeing a conflict where NOR writes block access to the FSMC bus, which would cause pixels to drop out on refresh.

Does it only occur on NOR writes?

[Johanan1]

NOR busy connected to GPIO pin, and waiting.

please look at my replay to Tesla DeLorean for more details.

Thanks very much.

GPIO_PinState isFlashReady()
{
	return HAL_GPIO_ReadPin(GPIOD, GPIO_PIN_6);
}
 
void NOR_Write(uint32_t addr, uint16_t value)
{
	int i;
	HAL_NOR_Program(&hnor1, (uint32_t *)addr, &value);
	for (i = 0; i < 50; i++)
		__NOP();
	while (!isFlashReady())
		__NOP();
}

in the write function like this:

[Tesla DeLorean]

Getting "snow" on a raster display device pulling from a memory frame-buffer tends to be indicative of a bandwidth issue, not an issue with parts in a batch.

Screen painting is particularly intolerant of stalls on the memory interface. If other bus users are blocking you'll get issues. One way to minimize this is to do these interactions during the frame fly-back.

[Johanan1]

This happens on board bring-up, when large file (~4Mb) is written to the NOR Flash. I also found that flash write fail sometimes, but if I retry write to same address, it's OK. I tried a small code to erase and write that flash just after reset, before FreeRTOS starts, and before LCD controller is initialized, and found no problems. The puzzle is that this system is in production for over 4 years, and only last batch is like this. Could it be some FMC initialization? this is the current init code.

Thanks very much.

void NOR_FMC_Init(void)
{
	FMC_NORSRAM_TimingTypeDef Timing;
 
	/** Perform the NOR1 memory initialization sequence
 */
	hnor1.Instance = FMC_NORSRAM_DEVICE;
	hnor1.Extended = FMC_NORSRAM_EXTENDED_DEVICE;out.
	/* hnor1.Init */
	hnor1.Init.NSBank = FMC_NORSRAM_BANK1;
	hnor1.Init.DataAddressMux = FMC_DATA_ADDRESS_MUX_DISABLE;
	hnor1.Init.MemoryType = FMC_MEMORY_TYPE_NOR;
	hnor1.Init.MemoryDataWidth = FMC_NORSRAM_MEM_BUS_WIDTH_16;
	hnor1.Init.BurstAccessMode = FMC_BURST_ACCESS_MODE_DISABLE;
	hnor1.Init.WaitSignalPolarity = FMC_WAIT_SIGNAL_POLARITY_LOW;
	hnor1.Init.WrapMode = FMC_WRAP_MODE_DISABLE;
	hnor1.Init.WaitSignalActive = FMC_WAIT_TIMING_BEFORE_WS;
	hnor1.Init.WriteOperation = FMC_WRITE_OPERATION_ENABLE;
	hnor1.Init.WaitSignal = FMC_WAIT_SIGNAL_DISABLE;
	hnor1.Init.ExtendedMode = FMC_EXTENDED_MODE_DISABLE;
	hnor1.Init.AsynchronousWait = FMC_ASYNCHRONOUS_WAIT_DISABLE;
	hnor1.Init.WriteBurst = FMC_WRITE_BURST_DISABLE;
	hnor1.Init.ContinuousClock = FMC_CONTINUOUS_CLOCK_SYNC_ONLY;
	// Timing
	
	Timing.AddressSetupTime = 15;
	Timing.AddressHoldTime = 15;
	Timing.DataSetupTime = 15;
	Timing.BusTurnAroundDuration = 15;
	Timing.CLKDivision = 16;
	Timing.DataLatency = 17;
	Timing.AccessMode = FMC_ACCESS_MODE_A;
 
	/* ExtTiming */
 
	HAL_NOR_Init(&hnor1, &Timing, NULL);
}

[waclawek.jan]

Is the snow permanent or flickering?

​

JW​

[Johanan1]

Flickering. After flash write is finished all looks OK.

[MM..1]

If this isnt on all boards same, you trouble is bad high speed signals design on your pcb layer. Sometimes vias is lower quality , sometimes close wires ... Hard to solve if not all board have this issue.