IS66WVO8M8DBLL Memory Mapped Interface on STM32H563 in zephyr

Question

Hi all,I am bringing up an ISSI IS66WVO8M8DBLL OctalSPI PSRAM (OctaRAM) on an STM32H563VIT6 overOCTOSPI1 in memory-mapped mode (window at 0x90000000). Reads, register access, and"write a location then read it back immediately" all work perfectly. But any SUSTAINEDor SCATTERED write workload corrupts data: rows that are not continuously re-writtenlose their contents within a few seconds, and some writes come back wrong.This matches errata ES0565 section 2.5.12 ("Variable latency is not supported when arefresh collision occurs during a write access to some OctaRAM memories"). I applied thedocumented workaround - forcing FIXED latency in the memory's configuration register -and I run in the documented MTYP=0b011 (Macronix OctaRAM) mode. The corruption persists,byte-for-byte identical, with the workaround correctly applied and verified by read-back.I have reproduced this on TWO separate boards with identical results, so it is not asingle bad device.Has anyone got OCTOSPI memory-mapped WRITES to an ISSI OctaRAM working reliably onSTM32H5? Is the fixed-latency workaround supposed to fully eliminate this, or is there anextra step / a fixed silicon revision?CONFIGURATION-------------- MCU : STM32H563VIT6 (silicon rev: )- External memory: ISSI IS66WVO8M8DBLL (64 Mbit / 8 MByte, x8 OctalSPI DTR PSRAM, 3.3 V)- Interface : OCTOSPI1, memory-mapped at 0x90000000, 8-line DTR, DQS enabled- Clock : PLL1_Q = 248 MHz -> OCTOSPI prescaler /2 -> SCLK = 124 MHz- Boards : 2 independent units, identical behavior- Software : bare-register + STM32 HAL (XSPI)- Memory datasheet: IS66/67WVO8M8DALL/BLL Rev. A1 (02/25/2022)Programmed OCTOSPI registers (read back at runtime): DCR1 = 0x03160400 (MTYP[2:0] = 0b011 = Macronix OctaRAM mode; DEVSIZE = 8 MB) DCR2 = 0x00000001 (PRESCALER = 1 -> SCLK 124 MHz) DCR3 = 0x00080000 (CSBOUND = 8 -> 256-byte CS# boundary) DCR4 = 0x00000140 (REFRESH = 320 clocks)Device Configuration Register, read back from the IS66WVO: CR = 0xf12a CR[15] = 1 normal operation (out of deep power down) CR[8] = 1 DQSM read pre-cycle CR[7:4] = 0010 latency code = 5 clocks CR[3] = 1 FIXED latency <-- ES0565 2.5.12 workaround applied CR[1:0] = 10 32-byte burst lengthDevice ID register reads correctly: ID = 0x2c93 (manufacturer field = 0x3, ISSI).ERRATUM TEXT (ES0565, section 2.5.12)-------------------------------------Description: "When the memory type (MTYP[2:0] bitfield of the OCTOSPI_DCR1 register) isconfigured to 0b011 to target an OctaRAM memory, the host controller does not supportthe variable latency requested by the external memory if a refresh collision occursduring the write access. For example, some OctaRAM memories, such as ISSI memories,request extra latency cycles for write accesses during refresh collision. In this case,the controller does not sample the DQS input signal during the instruction phase, andcannot detect the extra latency requested by the external memory for the refreshoperation. This results in data corruption."Workaround: "When the application targets an OctaRAM memory that requests extra latencycycles for write access during refresh collision, force the fixed latency mode in theconfiguration register of the external memory."WHAT I OBSERVE (with the workaround applied)--------------------------------------------Even with FIXED latency genuinely programmed (device CR = 0xf12a, CR[3] = 1, verified byread-back) and MTYP = 0b011 (verified DCR1 = 0x03160400):- Reads (any size), register access, and "write then read back immediately" all work.- Write a large region, THEN read it back -> ~100% corruption.- A write to one location disrupts the autonomous refresh of OTHER (un-accessed) rows; those rows decay to 0x00000000 / garbage within a few seconds, even while CS# is idle.- A realistic application struct (mix of frequently- and rarely-written fields) fails: rarely-written fields decay during normal operation, and a constantly-written field is also occasionally corrupted.Things I tried that did NOT change the write corruption: - MTYP = 0b010 (APMemory) and MTYP = 0b011 (Macronix OctaRAM) - identical corruption - Fixed-latency window from 5 to 8 clocks (CR[7:4]) - CSBOUND disabled..256 B; REFRESH 320/400; transaction sizes 4 B..1 MB; wrapped vs continuous burst - Disabling the external data cache (DCACHE1) so accesses are genuinely uncached - CS# internal pull-up; write DQS enable/disableReads stay clean throughout; only writes are affected.REPRESENTATIVE LOGS-------------------Init - clocks, controller and device registers all correct (MTYP=0b011, FIXED latency): INIT regs: ID=0x2c93 (mfr=0x3) CR=0xf12a XSPI ker clk=248000000 Hz prescaler=1 -> SCLK=124000000 Hz XSPI DCR1=0x03160400 DCR2=0x00000001 DCR3=0x00080000 DCR4=0x00000140Write-then-immediately-read works; write-all-then-read-all fails: interleaved write+read-back 1MB: 0 errors -> PASS B FAIL @ +0x0: exp 0xc0de0000 got 0x00000000 B FAIL @ +0xc: exp 0xc0de0003 got 0xfffe8888 B FAIL @ +0x10: exp 0xc0de0004 got 0xffffc0e1 separate write pass then read pass, 1MB: 262104 errors -> FAILA write disrupts refresh of un-accessed rows; data decays although CS# is idle: block @ +0x0 immediate read = OK; after 1MB write storm to other rows = LOST 1MB READ storm (no writes) -> block @ +0x0 = OK (reads do not disrupt refresh) sparse writes + 400 ms idle -> block @ +0x0 = LOSTRealistic application struct in PSRAM, scattered read-modify-write over 5000 ticks: app-vars after 5000 ticks: live_mismatch=39 full_mismatch=42 -> FAIL boot_count=8 (exp 7) uptime=5000 (ok) temp=25904 (ok) crc=0x00001388 (exp 0xA5C3F00D) app-vars after 5s idle: mismatch=42 -> DECAYEDQUESTIONS---------1. With ES0565 2.5.12's workaround applied as documented (device FIXED latency, MTYP=0b011), I still see write corruption. Is the fixed-latency workaround expected to FULLY eliminate it, or are there additional required conditions (controller settings, refresh/CSBOUND constraints, write dummy-cycle requirements)?2. Is this erratum corrected in any STM32H563 silicon revision? If so, which one, and how do I identify it (package marking / DBGMCU_IDCODE REV_ID)?3. Is the ISSI IS66WVO8M8 a validated/recommended OctaRAM for STM32H5 OCTOSPI memory-mapped WRITE use? If not, can you recommend an OctaRAM PSRAM that does not request extra write-access refresh latency (and would therefore be unaffected per the erratum text)?4. Is there a reference project / app note showing reliable OCTOSPI memory-mapped WRITES to an ISSI OctaRAM on STM32H5 that I can compare against?Thanks in advance for any pointers.

KDJEM.1 · Accepted Answer

Hello ​@sramrajkarand welcome to the community;Could you please share the memory datasheet?I recommend you to look atHow to configure and use ISSI OctaRAM™ with STM32U5 over octo-SPI | Communityarticle precisely section4.2 Configure the latency counter.According to the errata sheet this limitation is available on all silicon revision.I recommend you to look atHow to configure and use ISSI OctaRAM™ with STM32U5 over octo-SPI | Communityarticle and get inspired to check your configuration.This technical guidance describes how tobring upand useISSIIS66WVO32M8DBLLOctaRAMwithSTM32U5.Note that the STM32U575 have the same erratum as the STM32H563.I hope this help you.Thank you.Kaouthar

sramrajkar · Answer

HiThanks — that confirms what I was seeing, and it's helpful to have it stated that ES0565 §2.5.12 applies to all STM32H563 silicon revisions.I've since done a full characterization on two boards and wanted to report the results, plus one finding that is separate from the erratum and may be of interest to ST.== Write path (the erratum) ==I applied the documented workaround (force fixed latency, CR[3]=1 — device CR reads back 0xF14A, MTYP=0b011, confirmed on the wire) and also matched the STM32U5 OctaRAM reference configuration as closely as the H5 allows. Writes still corrupt. The behavior is now cleanly isolated:- A write LANDS correctly: write a 32–256 B chunk, read it back immediately (uncached) — bit-perfect, every time.- Data does NOT persist: after writing the rest of the array, a re-scan shows ~100% of previously-written words corrupted, including words that read back correct moments earlier.So it is exactly the refresh-collision/disturb mechanism in the erratum: writing one region disrupts the device's hidden refresh of other rows. Things I verified have no effect on this: MTYP 0b010 vs 0b011, fixed-latency window 5→8 clk, st,csbound (0/5/8) and st,refresh, MaxTran, transaction sizes 4 B–1 MB, continuous vs wrapped burst write, ChipSelectHighTimeCycle up to max, mmap timeout counter, and pacing writes with idle gaps. Reads/register access/idle retention stay perfect throughout.Could you confirm the intended usage model for OctaRAM *writes* on STM32H5 given this erratum? In practice it appears usable only as write-then-immediately-consume scratch or write-once/read-many, not as general read-write memory. If there is a register or timing recipe that makes sustained/scattered memory-mapped writes reliable on H5 (not U5), I'd be grateful for it.== Separate finding: DCACHE1 corrupts memory-mapped reads ==While isolating the above I found a second, independent issue that is NOT the erratum and cost me a lot of time:The always-on STM32H5 DCACHE1 corrupts CACHED reads of the memory-mapped OCTOSPI window. With DCACHE1 disabled (sys_cache_data_disable), reads are bit-perfect at any size. With it enabled, a contiguous read shows a reproducible defect: a 16-bit beat is duplicated ~32 bytes into the read and the remainder is shifted. The fault is:- independent of access width (8/16/32-bit),- independent of device burst length (CR[1:0] 32 B vs 128 B),- relative to the start of the read (tracks read+0x20), not an absolute address,- only visible with a non-uniform data pattern (uniform/zero fills like 0xAA or 0x55 hide it).Decisive test was dumping the same buffer twice, cached then with DCACHE1 disabled — cached shows the slip, uncached is clean — so the OCTOSPI read engine and the device are fine; the DCACHE1 line-fill/prefetch path is mangling the window.Questions on this:1. Is DCACHE1 incoherence/corruption on the memory-mapped OCTOSPI region a known limitation on STM32H5? Is there an erratum or app-note covering it?2. What is the supported way to make the OCTOSPI-mapped region cacheable AND correct? Is uncached the expected answer for OCTOSPI-mapped PSRAM on H5, or is there a recommended DCACHE configuration/maintenance pattern?Environment: STM32H563VIT6, OCTOSPI1 @ 0x90000000, 8-line DTR, IS66WVO8M8DBLL, tested 25–124 MHz, Zephyr RTOS with an out-of-tree memc driver. Happy to share register dumps (DCR1/2/3/4, CR) or a minimal reproducer.Thanks again for the help.

Sign up

Social Login

Login to the community

Social Login