I'm doing some preliminary testing with a STM32F767 and FMC connecting to a KS0108 128x64 LCD display.

The problem I'm running into is that I can't come up with a clean way to slow down the enable clock and data to meet the spec unless I slow down the complete AHB bus, which I don't really want to do. With timing accesses maxed out I'm getting 80us NWE (E pin) high where I need 450us minimum to meet LCD specs.

The datasheet says it supports 6800 and 8080 modes, but its pretty sketchy on details. Am I missing something here, or is a timer + dma and GPIO the better way to go here?

Following is the init setup

  hsram1.Instance = FMC_NORSRAM_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_8;
  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_ENABLE;
  hsram1.Init.PageSize = FMC_PAGE_SIZE_NONE;
  /* Timing */
  Timing.AddressSetupTime = 15;
  Timing.AddressHoldTime = 15;
  Timing.DataSetupTime = 255;
  Timing.BusTurnAroundDuration = 15;
  Timing.CLKDivision = 15;
  Timing.DataLatency = 15;
  Timing.AccessMode = FMC_ACCESS_MODE_A;
  /* ExtTiming */

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

Logic capture

  • \$\begingroup\$ "Interface with parallel LCD modules, supporting Intel 8080 and Motorola 6800 modes." is explicitly mentioned as a feature of the FMC peripheral, so it's doable. Whether it's convenient using the HAL libraries is another matter. github.com/NickNagy/Cortet/wiki/… and st.com/resource/en/application_note/… will be really helpful to you \$\endgroup\$
    – Ben Voigt
    Commented May 6, 2022 at 19:48
  • \$\begingroup\$ I use as little HAL as possible. The problem is that 216mhz / (addset+1+datast+1) is still > a 6mhz clock rate, or in reverse, I'd basically have to run a 32mhz HCLK to run this slow enough. \$\endgroup\$ Commented May 6, 2022 at 19:57
  • \$\begingroup\$ You have data setup of 255, shouldn't that make your denominator more than 260 and divide a 216MHz down less than 1MHz (looks like you need to get down to 400kHz) \$\endgroup\$
    – Ben Voigt
    Commented May 6, 2022 at 20:01
  • \$\begingroup\$ Possible a little crude - but maybe you could use an external one-shot monostable like a 74LVC1G123 configured to produce a ~400us pulse, triggered by NWE, with its output connected to the STM32's NWAIT input to force extra wait states when the FMC accesses the LCD ... \$\endgroup\$
    – brhans
    Commented May 6, 2022 at 20:13
  • \$\begingroup\$ @BenVoigt The problem is that the 216 / (ADDSET + 1) is around 13.5mhz/75ns which is too long for the 500ns min of lcd. \$\endgroup\$ Commented May 6, 2022 at 23:15

1 Answer 1


It makes little sense to put a device with such a slow bus on the FMC. You likely will write multiple bytes sequentially, which makes the whole system to pend on a write until FSMC bus operation is complete. It will be equally slow if you just have the display on GPIO and wait for relevant amount of microseconds, but you can still have the CPU responding to interrupts for example.

So using GPIO with delays, timer interrupts, or DMA to generate bus waveforms would sound like a plan. Or changing to a display with a serial interface (SPI, I2C).

  • 1
    \$\begingroup\$ It isn't all that bad, the AXI bus can continue communicating with other AHB busses while the FMC is busy, and the processor also has tightly-coupled memories that completely bypass bus contention. See the bus matrix on page 71 of st.com/resource/en/reference_manual/… The only part of the system that would truly be blocked would be access to other external memories. \$\endgroup\$
    – Ben Voigt
    Commented May 6, 2022 at 19:26
  • 1
    \$\begingroup\$ The core thing I'm after is as little cpu intervention as reasonable, so some type of DMA regardless. This would be the only this on this bus, so not sure how it would effect other memories like qspi. \$\endgroup\$ Commented May 6, 2022 at 19:29
  • 1
    \$\begingroup\$ @ErikFriesen: The bus matrix and explanation (section 2.1, pages 71-73) of the reference manual linked above shows that the DMA2D (designed for copying framebuffers around) can talk to the FMC without preventing the processor or other DMA engines (Ethernet for example) from talking on any other AHB at the same time. \$\endgroup\$
    – Ben Voigt
    Commented May 6, 2022 at 19:53
  • \$\begingroup\$ One drawback to GPIO+timer is that you basically have to bit fiddle the DMA source buffer that feeds the BSRR. \$\endgroup\$ Commented May 6, 2022 at 23:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.