2016-10-19 12:08 AM
2016-10-19 02:12 AM
A0 and A1 stuck/not connected? Check activity with an oscilloscipe directly on the SDRAM's A0/A1 pins.
JW2016-10-19 03:24 AM
Hi JW,
good gues, O thought it too. But then blocks of memory would be unredable, because address line is used to send colum and row adress so blocks of memory (4x4 cels) would be the same. Now only repetition 1x4 is the same. To be sure now I ***** signals with oscilloscope. You can see in attach I add A0 compare A1 address line and A1 compare A3 address line. As you can see, everything is fine. Also you can find attach 3, where i higlight adress lines from 0 to Today I did one more reseach. I noticed that if i continously write/read in SDRAM, sometimes I get values diferent than repeation of 4. So write my array write[100]and after that I read that array read[100]. After read/write i compare these two array and if they not match, I stop writing, and left only reading part. Rezult - I always get array with broken repeation 1x4. To be more clear: Continously rea/write __________________________________________ Write to sdram Read from sdram (most common) 0 300 100 300 200 300 300 300 400 700 500 700 600 700 700 700 800 1100 900 1100 1000 1100 1100 1100 1200 1500 1300 1500 1400 1500 1500 1500 After I capture one mismatch with comon read values i turn of writing mismatch After turn of write (only continuous read left) 300 300 300 300 300 300 300 300700 700
600 600 600 600 700 700 1100 1100 1100 1100 1000 1100 1100 1100 1500 1500 1500 1500 1500 1500 1500 1500 So the problem apears only on write sequence. Thanks for answer anyway. ________________ Attachments : A0_A1.jpg : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I1KT&d=%2Fa%2F0X0000000blO%2FQ80Fhw8iuywyaFK3MjadTE.Wsqr4GVMQIsLxPf2JgKQ&asPdf=falseA1_A3.jpg : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I1DZ&d=%2Fa%2F0X0000000blM%2Fsfs_SrLpjGu1bFNIFoDheRhTbbQAlcWCsB0KMKpuuzk&asPdf=falseHardware.png : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I1KJ&d=%2Fa%2F0X0000000blK%2F9qkPM02.O2IH5sbU5tCGjJ1.YLXRIT98iEFKb_h8qrs&asPdf=false2016-10-19 04:49 AM
Your SDRAM lacks of sufficient power supply. 100nF capacitors to every VDD and VDDQ pin is necessary, HF Separation of VDD and VDDQ is strongly recommended. To make it even worse in your design, the SDRAM is sharing its 100nF Capacitory with the uC. See the Datasheet of the SDRAM, it draws 200mA during refresh cycle / 120mA in normal use. See attached file to see more Details ...
________________ Attachments : SDRAM_Power.png : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I1Fk&d=%2Fa%2F0X0000000blL%2FK1.MxLwTXYbtaa7tqZb4sHWZG9Mr4TrI6oZDHnehO_U&asPdf=false2016-10-19 05:04 AM
See also attached schematics of STM32F4/7 Disco SDRAM with extra 100nF Capacitors for every VDD/VDDQ pin.
________________ Attachments : SDRAM_DISCO.png : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I1K0&d=%2Fa%2F0X0000000blJ%2F3Y105pHYLKetgaSEHsmZlaoVyfu5HTDRlmKEX2ASEg0&asPdf=false2016-10-20 01:50 AM
Hello Markus, thank you for answer,
I try to connect 100 nF capacitors on each VDD and VDDQ pin (see in attatch). There is no shorts i tested all posible shorts with multimeter. But the result is the same. Any more ideas, why this bug is appearing? ________________ Attachments : soldered_100n_and_4.7uF_cap.jpg : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006I1K9&d=%2Fa%2F0X0000000blH%2FbsZARaawUCwg26AnVwFTKncHsbzwHHy6gpZzQhxoqV4&asPdf=false2016-10-20 02:17 AM
I'd start with small steps: clear the entire memory (write 0), check it is clear, then write some nonzero value to a single address once, check entire memory for changes. Try with different values and different addresses, but always one write only. Come back with results.
JW2016-10-20 03:02 AM
Hi JW,
Write zeroes to SDRAM was alredy done by initialization code. Folowing your instructions I implement test code:write[0]=0xFAFA;
HAL_SDRAM_Write_16b(&g_sdram, 0xD0000000+111112, &write, 1); // values I tried: 0, 12, 112, 1112, 11112 and 111112
for (i=0; i<0x400000; i+=2) // 0x400000 - ram size, based on uint16_t words
{
HAL_SDRAM_Read_16b(&g_sdram, 0xD0000000+i, &read, 1);
if (read[0]==0)
read[0]=0;
else if (read[0]!=0xFAFA)
read[0]=read[0]; // breakpoint 1
else if (read[0]==0xFAFA)
read[0]=read[0]; // breakpoint 2
}
Rezult: I always 4 times stoped on breakpoint 2, which indicates writed value in 4 cells after 1 write cycle, and then I get end of the for cycle. Breakpoint 1 newer occured. I do not put breakpoint on first if, because most of memory is zero.Note: I have more than one sample, all act the sameAny ideas?
2016-10-20 03:48 AM
I've just noticed:
> sdramCommand.ModeRegisterDefinition =(uint32_t) SDRAM_MODEREG_BURST_LENGTH_2 |
I believe FMC does not support bursts on the SDRAM-interface. RM0090 rev.13 in 37.7.3 SDRAM controller functional description, SDRAM initialization checklist, item 7:
The Burst Length (BL) of 1 must be selected by configuring the M[2:0] bits to 000
in the mode register (refer to the SDRAM datasheet). Please review. I am no FMC/SDRAM expert. JW
2016-10-20 04:08 AM
Acording to your note, I changed this part to:
sdramCommand.ModeRegisterDefinition =(uint32_t) SDRAM_MODEREG_BURST_LENGTH_1 | // ((uint16_t)0x0000)
SDRAM_MODEREG_BURST_TYPE_SEQUENTIAL | // ((uint16_t)0x0000)
FMC_SDRAM_CAS_LATENCY_3 | // ((uint16_t)0x0030)
SDRAM_MODEREG_OPERATING_MODE_STANDARD | // ((uint16_t)0x0000)
SDRAM_MODEREG_WRITEBURST_MODE_SINGLE; // ((uint16_t)0x0200)
Unfortunately i get the same rezult. I have also tried to change this row: g_sdram.Init.ReadBurst = FMC_SDRAM_RBURST_ENABLE;
But nothing happened.Any more ideas?