cancel
Showing results for 
Search instead for 
Did you mean: 

Data is written to SDRAM at the correct address and at a wrong address with 32 byte offset simultaneously. What could be the reason for this?

Jan1
Associate II

Hello,

I have an STM32F746 in an own PCB design. A 128 Mb DRAM IS42S32400F is connected to the FMC pins, similar as on the STM32F746G-DISCO board. I can write and read data but there are errors which occur in a systematic way:

I start writing 16 bit data at address 0xC000 0000.

Data is stored at the the correct address. But, the strange thing is that the same data appears simultaneously at a second location either 32 byte above or below the intended address. How can this happen? How can data be stored at two locations with one write command?

A memory dump screenshot is attached.

I have double-checked all connections and fiddled with timing - but no success.

In my design I didn't care about matched trace lengths. Controller and SDRAM are about 4 cm apart. Could this be a reason?

I can also observe the same problem on an LCD sreen since the SDRAM is also my frame buffer.

The test loop is very simple:

while (1)

   {

       *(uint16_t*) (LCD_FB_START_ADDRESS + 2 + (2 * (y * 800 + x))) = x;

       x++;

       if (x == 800)

       {

           x = 0;

           y++;

           if (y == 480)

               y = 0;

       }

       HAL_Delay(1);

   }

I hope that anyone can give me a hint. I'm new in the STM32.

Regards

Jan

15 REPLIES 15

Hello DM.7,
Can you provide more information on how you solved this issue??. I'm also facing the same issue right now.

Thanks & Regards,
Abubakkar Siddiq

As a fundamental, trace length matching is critical to correct SDRAM operation.  The same is true of any high-speed, multi-signal bus (OSPI, QSPI, etc.).

Hello,

In the units MPU config, there was a section that was:

MPU_InitStruct.DisableExec = MPU_INSTRUCTION_ACCESS_ENABLE;

and changing it to:

MPU_InitStruct.DisableExec = MPU_INSTRUCTION_ACCESS_DISABLE;

This then stopped the issue.

This does not seem like a good fix as it doesn't make much sense but that is all it was. I have not had a chance to investigate further

 

I have not found the cause of it yet, it keeps coming back from time to time.

I have made some changes to the MPU config, which makes it go away temporarily.

We recently noticed that we were clocking the RAM at 120MHz, which is out of spec. Lowering the clock to 110MHz, stopped the latest occurence of it.

Check your Data Sheets carefully - what's the upper limit on the FMC and memory rates?

AbubakkarSiddiq
Associate

I have solved the issue by clearing the entire cache once by using the 

SCB_CleanDCache() function.