SDRAM STM32F429 refresh problem

[m__it]

Posted on July 04, 2014 at 13:58

The original post was too long to process during our migration. Please click on the attachment to read the original post.

[Tesla DeLorean]

Posted on July 04, 2014 at 20:31

Does the similar code work on the STM32F429I-DISCO?

How does the pin/board configuration differ? I'd dig deeper but none of your pin configuration is commented, and there's no schematic.

[m__it]

Posted on July 05, 2014 at 14:23

Thank you for your reply

I have tested today with the STM32F429i discovery and that seems to work correctly. 

Even when I stop the program in the debugger mode for a couple of minutes before

reading back the data. The data is still valid. 

I will show the differences between the pins on the discovery and our project:

Discovery: (uses ISSI 64Mb sdram -  http://www.issi.com/WW/pdf/42-45S16400J.pdf)

//             PB5  = SDCKE1 (CKE) PF0  = A0

//             PB6  = SDNE1  (/CS) PF1  = A1

//             PC0  = SDNWE  (/WE)       PF2  = A2

//             PD0  = D2                           PF3  = A3

//             PD1  = D3                           PF4  = A4

//             PD8  = D13                          PF5  = A5

//             PD9  = D14                         PF11 = SDNRAS (/RAS)

//             PD10 = D15                       PF12 = A6

//             PD14 = D0                           PF13 = A7

//             PD15 = D1                           PF14 = A8

//             PE0  = NBL0   (LDQM)     PF15 = A9

//             PE1  = NBL1   (UDQM)     PG0  = A10

//             PE7  = D4                           PG1  = A11

//             PE8  = D5                     PG4  = BA0    (BANK A0)

//             PE9  = D6                           PG5  = BA1    (BANK A1)

//             PE10 = D7                           PG8  = SDCLK  (CLK)

//             PE11 = D8                           PG15 = SDNCAS (/CAS)

//             PE12 = D9

//             PE13 = D10

//             PE14 = D11

//             PE15 = D12

Our project: (uses Alliance Memory 512 Mb sdram -   http://www.alliancememory.com/pdf/dram/512M-SDRAM.pdf)

//            *PH7  = SDCKE1 (CKE) PF0  = A0

//            *PH6  = SDNE1  (/CS)         PF1  = A1

//             PC0  = SDNWE  (/WE)       PF2  = A2

//             PD0  = D2                             PF3  = A3

//             PD1  = D3                             PF4  = A4

//             PD8  = D13                           PF5  = A5

//             PD9  = D14                           PF11 = SDNRAS (/RAS)

//             PD10 = D15                         PF12 = A6

//             PD14 = D0                           PF13 = A7

//             PD15 = D1                           PF14 = A8

//             PE0  = NBL0   (LDQM)       PF15 = A9

//             PE1  = NBL1   (UDQM)       PG0  = A10

//             PE7  = D4                             PG1  = A11

//             PE8  = D5                           *PG2  = A12

//             PE9  = D6                             PG4  = BA0    (BANK A0)

//             PE10 = D7                           PG5  = BA1    (BANK A1)

//             PE11 = D8                           PG8  = SDCLK  (CLK)

//             PE12 = D9                           PG15 = SDNCAS (/CAS)

//             PE13 = D10                     *PH12 = VDD SDRAM enable

//             PE14 = D11

//             PE15 = D12

* means different from STM32F429i discovery

I hope this will inform you a little bit better.

My sincerly 

[Tesla DeLorean]

Posted on July 05, 2014 at 15:17

FMC_SDRAMInitStructure.FMC_ColumnBitsNumber = FMC_ColumnBits_Number_8b;

 

FMC_SDRAMInitStructure.FMC_RowBitsNumber = FMC_RowBits_Number_12b;

Isn't the geometry of this part 13 Rows, 10 Columns?

[m__it]

Posted on July 05, 2014 at 15:51

Yeah, you are absolutely right. We have missed that one. 

Changed it in the sofware but this doesn't effect the memory loss problem.

[John F.]

Posted on July 07, 2014 at 09:26

The line

RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_GPIOB | RCC_AHB1Periph_GPIOC | RCC_AHB1Periph_GPIOD |
RCC_AHB1Periph_GPIOE | RCC_AHB1Periph_GPIOF | RCC_AHB1Periph_GPIOG | RCC_AHB1Periph_GPIOG, ENABLE);

references GPIOG twice. You don't appear to enable GPIOH clock.

[jacekborko]

Posted on May 10, 2015 at 22:53

Hey did you solve this problem ? i have simmilar one with AS4C4M16S-6TIN. but after delay i have following results:

2002ffd8   de111206

d00003d4  fe117206

so as you can see two octets are changed and i have no ideal what can make this, any sugestions ?

[Tesla DeLorean]

Posted on May 11, 2015 at 03:26

Would seem to suggest you have some issue with D13/D14, or with the refresh period?

[jacekborko]

Posted on May 11, 2015 at 20:46

datasheet says ''Refresh Interval Time  -  max 15.6 '' so :

 //15.6us*84MHz=1311 

when i use 100

  FMC_Bank5_6->SDRTR=100<<1;

this didnt gave any result.

when i put 

even 

  FMC_Bank5_6->SDRTR=10000<<1;

thats didnt gave any result.

Would seem to suggest you have some issue with D13/D14

could you explain me this part, and how to check it ?

[Tesla DeLorean]

Posted on May 11, 2015 at 21:28

could you explain me this part, and how to check it ?

You'd revisit your board as designed via the schematic. Verify that you're using the right pins.

You'd evaluate your board as built, looking at a) the bare PCB board, and b) a finished one, and probe out the lines to verify continuity, and lack of shorts.

At a software level you could write and immediate read several locations with different combinations of bit patterns in the D13 and D14 position, and confirm with zero delay if the bits ever hold zero states, or the correct states.

These would seem like some pretty basic steps to validate the design. If those work, then focus on the software and timing, and review signals with a scope or logic analyzer, until you understand what's actually going on.

[h239955]

Posted on June 03, 2015 at 15:31

Clarification of original symptoms

This is not a refresh problem. This immediate readback of a write like Michel's test below gives the expected value for 'number2' even with the SDRAM device physically removed from the board! It took me ages to find that out. In my case the software turned out to be correct but the RAM device wasn't soldered down properly. 

Michel's test:

    //We declarate a variable test as a float in the SDRAM

    __attribute__((section(''.sdram_data''))) float test;

    //Just some numbers

    float number1 = 12.5, number2;

    int main(void)

    {

        test = number1;

        number2 = test;

    }