Skip to content

Cache the SDRAM once it is verified (cache=on) - #4

Merged
JohnAmadis merged 1 commit into
mainfrom
feature/sdram-cache
Oct 4, 2026
Merged

JohnAmadis merged 1 commit into
mainfrom
feature/sdram-cache

Conversation

@JohnAmadis

Copy link
Copy Markdown
Contributor

Summary

dmfmc now caches the SDRAM once it is verified (cache=on, the default).

  • Before: the SDRAM window was Normal non-cacheable, non-bufferable (MPU region 6). Every access to it went over the 16-bit FMC bus, whatever the CPU caches. On the STM32F746G-DISCO, filling a 118x101 rounded rectangle took 6.5 ms (~117 cycles per pixel), and a dmview window redraw took 160 to 230 ms.
  • After:
    • the window is non-cacheable during bring-up and the uncached check, as before;
    • then the new port function dmfmc_port_cache_sdram() makes it write-back (TEX=001 C=1 B=1);
    • it then checks the SDRAM through the D-cache: 64 KiB of address-dependent patterns are written into the cache, cleaned to the SDRAM, invalidated and read back, in two passes, the second inverted;
    • when that fails, the window is made uncached again and an error is logged.
  • Without a data cache (the F4, or the D-cache off), only the attributes are set.
  • cache=off keeps the SDRAM uncached.
  • Docs: the comment on the MPU region now says why this is safe. The "every word reads back as the last one written" corruption from bring-up coincided with swapped bank target bits (CTB1/CTB2) and too fast an SDCLK for RBURST, both fixed since.

Also in this PR: dmfmc_types.h includes stdint.h, stdbool.h and stddef.h before dmdrvi_ioctl.h. That header uses size_t without stddef.h; the dmdrvi fix is choco-technologies/dmdrvi fix/ioctl-stddef.

Requirements

  • choco-technologies/dmlcdtft fix/sync-copied-area should be released together with this PR. With a write-back cache, the area PRESENT copies into the other buffer must be synced.
  • The caches are enabled by dmod-boot (choco-technologies/dmod-boot feature/cortex-m7-caches).

Testing

STM32F746G-DISCO, 8 MiB SDRAM, SDCLK 72 MHz, CAS 2, 16-bit bus:

  • the check through the cache passed and the window stayed write-back (MPU region 6 RASR 030b002f);
  • the board ran the dmview demo, with modules, heaps and framebuffers in the SDRAM, through many minutes of use.

🤖 Generated with Claude Code

The SDRAM window was Normal non-cacheable, non-bufferable for good: every
access to it - module code, heaps, framebuffers - went over the 16-bit FMC
bus, and the caches of a Cortex-M7 never helped. After the uncached check,
dmfmc_port_cache_sdram() makes it write-back and checks it through the
data cache (64 KiB of patterns cleaned to the SDRAM and read back, twice);
when that fails the window stays uncached. cache=off keeps it uncached.

Also: dmfmc_types.h includes the standard headers before dmdrvi_ioctl.h,
which uses size_t without stddef.h.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@JohnAmadis JohnAmadis self-assigned this Oct 4, 2026
@JohnAmadis
JohnAmadis merged commit c3ecbf9 into main Oct 4, 2026
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant