Skip to main content
infoinfo983
infoinfo983
Associate III
Apr 20, 2018 12:19 PM UTC
Question

Write problems on a SRAM with the STM32H743ZIT6

Posted on April 20, 2018 at 14:19

Greetings

I have the following problem on the micro STM32H743ZIT6:

1) during access to the external write bus, on an SRAM, with only 16 bit bus, occurs when I execute the instruction

* ((uint16_t *) 0x60000000) = (uint16_t) 0xFFFF;

The hardware signals move as follows (/ NE1 yellow, / NOE blue, /WR purple) see attached.

1) It is certainly incorrect because

- /NE1 (yellow chipselect) should only be activated once and not 2.

- And / NWR (purple) should only activate 1 within / NE1 and not 2.

How come this occurs?

Where am I doing wrong ?

2) The above test was performed with the data cache and code disabled, because otherwise nothing is activated.

 How can I write externally with the cache enabled?

Obviously if it's possible.

My InitCode is:

/* FMC initialization function */

static void MX_FMC_Init(void)

{

    FMC_NORSRAM_TimingTypeDef Timing;

    FMC_SDRAM_TimingTypeDef SdramTiming;

    /** Perform the SRAM1 memory initialization sequence

     * Accesso alla FPGA

    */

    hsram1.Instance                    = FMC_NORSRAM_DEVICE;

    hsram1.Extended                    = FMC_NORSRAM_EXTENDED_DEVICE;

    /* hsram1.Init */

    hsram1.Init.NSBank                = FMC_NORSRAM_BANK1;

    hsram1.Init.DataAddressMux        = FMC_DATA_ADDRESS_MUX_DISABLE;

    hsram1.Init.MemoryType            = FMC_MEMORY_TYPE_SRAM;

    hsram1.Init.MemoryDataWidth        = FMC_NORSRAM_MEM_BUS_WIDTH_16;

    hsram1.Init.BurstAccessMode        = FMC_BURST_ACCESS_MODE_DISABLE;

    hsram1.Init.WaitSignalPolarity    = FMC_WAIT_SIGNAL_POLARITY_LOW;

    hsram1.Init.WaitSignalActive    = FMC_WAIT_TIMING_BEFORE_WS;

    hsram1.Init.WriteOperation        = FMC_WRITE_OPERATION_ENABLE;

    hsram1.Init.WaitSignal            = FMC_WAIT_SIGNAL_DISABLE;

    hsram1.Init.ExtendedMode        = FMC_EXTENDED_MODE_DISABLE;

    hsram1.Init.AsynchronousWait    = FMC_ASYNCHRONOUS_WAIT_DISABLE;

    hsram1.Init.WriteBurst            = FMC_WRITE_BURST_DISABLE;

    hsram1.Init.ContinuousClock        = FMC_CONTINUOUS_CLOCK_SYNC_ONLY;

    hsram1.Init.WriteFifo            = FMC_WRITE_FIFO_DISABLE;

    hsram1.Init.PageSize            = FMC_PAGE_SIZE_NONE;

    /* Timing */

    Timing.AddressSetupTime            = 9;

    Timing.AddressHoldTime            = 15;

    Timing.DataSetupTime            = 11;

    Timing.BusTurnAroundDuration    = 7;

    Timing.CLKDivision                = 16;

    Timing.DataLatency                = 17;

    Timing.AccessMode                = FMC_ACCESS_MODE_A;

    /* ExtTiming */

    if (HAL_SRAM_Init(&hsram1, &Timing, NULL) != HAL_OK)

    {

        _Error_Handler(__FILE__, __LINE__);

    }

Thank you

    This topic has been closed for replies.

    6 replies

    Nesrine M_O
    Nesrine M_O
    Associate
    Apr 20, 2018 2:03 PM UTC
    Posted on April 20, 2018 at 16:03

    Hi

    Corradini.Alberto

    ,

    Do you try the FMC_SRAM example under the STM32H7 firware package:

    STM32Cube_FW_H7_V1.2.0\Projects\STM32H743I_EVAL\Examples\FMC\FMC_SRAM

    In this example, the SRAM device is configured and initialized explicitlyfollowing all initialization sequence steps. After initializing the device, user can perform read/write operations on it. A data buffer is written to the SRAMmemory, then read back and checked to verify its correctness.

    -Nesrine-

    infoinfo983
    infoinfo983Author
    Associate III
    Apr 20, 2018 5:33 PM UTC
    Posted on April 20, 2018 at 17:33

    Hi

    I do not have an evaluation board, but a working card already in production with the STM32F429ZIT6.

    I'm trying to upgrade with the new microcontroller.

    Everything I've tried so far works.

    Also reading at SRAM works.

    I stuck to the writing because I noticed that anomaly.

    I do not have to write in an SRAM, but in an FPGA seen as SRAM.

    I have to write words individually and not a series of consecutive information.

    In any case, I try to look at the recommended example.

    Thank you

    Hal

    infoinfo983
    infoinfo983Author
    Associate III
    Apr 20, 2018 5:57 PM UTC
    Posted on April 20, 2018 at 17:57

    Hi,

    My initialization is identical to the one in the example, but I can not try it because I have an FPGA and not an SRAM.

    I only have to write words (16bit) to random and non-consecutive addresses.

    For me there is a problem in silicon!

    Can you confirm ?

    thank you

    Hal

    Piotr S
    Piotr S
    Associate
    Apr 20, 2018 2:32 PM UTC
    Posted on April 20, 2018 at 16:32

    What a coincidence, i posted exactly the same problem today.

    https://community.st.com/0D50X00009XkWQESA3

    . It looks like fmc tries to write entire 64bit block of memory.

    Regarding 2nd question:

    I took a look into FMC SRAM code example from cube package for STM32H743I_EVAL, but this example enables data cache, writes only 512bytes of data, then reads it back. Since DCache have size of 16kB, data is not written into SRAM until cache is cleared/runs out of space (which is never). Then example code reads what it just written to cache without single operation on sram. Way to go...

    With cache enabled you can force write with SCB_CleanDCache(); I tried enabling cache, writing one uint16_t and cleaning cache which resulted in this:

    0690X0000060Ai2QAE.png

    After cache clean a wholecache line of 32 bytes was written. Not a problem with interfacing to memory, but in my case i want to write commands to LCD with parallel interface.

    This leads me to believe that even with data cache disabled there is something between CPU and FMC with cache like behaviour which results in this weird 4 write accesses... Maybe there is something in core or MPU that i'm not aware of.

    Piotr S
    Piotr S
    Associate
    Apr 20, 2018 3:41 PM UTC
    Posted on April 20, 2018 at 17:41

    I believe i have a solution. Put following line at the end of your FMC init function:

    HAL_SetFMCMemorySwappingConfig(FMC_SWAPBMAP_SDRAM_SRAM);

    Swap your

    0x60000000

    address with 0xC0000000. Should work fine.

    Why this works? Memory under 0xC0000000 is accessed as Device memory, as opposed to memory under 

    0x60000000

    accessed as Normal memory. 'Normal memory allows the load and store of bytes, half-words and words to be arranged by the CPU in an efficient manner (the compiler is not aware of memory region types)'. You can refer to AN4838 and AN4839 for more information.
    infoinfo983
    infoinfo983Author
    Associate III
    Apr 23, 2018 9:26 AM UTC
    Posted on April 23, 2018 at 09:26

    Hi

    It seems to work.

    Now I have to check if the external SDRAM continues to work

    .

    Thank you

    Hal

    Terms & ConditionsAccessibility statement