2021-10-14 03:14 AM
Hi,
I work with a development team that is developing a product that has a STM32L4S9 MCU and a IS66WVH8M8ALL-100 HyperBus PSRAM.
Recently, we found in the STM32L4 Errata that actually this MCU does not support PSRAM. We noticed that the self-refresh was not occuring and data was being lost/corrupted.
We tried changing the OctoSPI configuration, but any attempt did not work.
We measured nCS pin, and in fact it is not released in time (4us) to allow the refresh to occur.
In our project we use this memory configured as memory mapped, so we can extend the internal memory . The RAM is used to save various user data, framebuffers and more.
By looking at the HAL code we see that there is a memory type HAL_OSPI_MEMTYPE_MACRONIX_RAM. But we could not find any other OctoSPI RAM memory that is not PSRAM and has density of 64Mb (8MB).
I wonder if someone has faced this same problem and could use, maybe, some OctoSPI Static RAM instead, that does not require self-refresh function.
*We already know and tested a STM32H7 MCU using the same PSRAM, and it fully works. However, this will require a huge change in our product, so we are trying to first understand all options around the STM32L4S9 MCU
Solved! Go to Solution.
2021-11-29 07:33 AM
Hi,
I confirm ST doesn't support OPI configuration on this specific version of MCU. following version are supporting IoT RAM (QSPI or OPI PSRAM). One alternative option could be to use ADMUX PSRAM on FMC bus.
fyi, we still have few customers who manage to run our memory for frame buffering (64Mb IoT RAM APS6408L-OBM for example). Key point is you need to avoid odd address write issue. In their use case, since the pixel was 2 bytes, the DMA2D should be 2 bytes aligned, so they had no odd address access.
Regards
Alex
2021-11-29 07:33 AM
Hi,
I confirm ST doesn't support OPI configuration on this specific version of MCU. following version are supporting IoT RAM (QSPI or OPI PSRAM). One alternative option could be to use ADMUX PSRAM on FMC bus.
fyi, we still have few customers who manage to run our memory for frame buffering (64Mb IoT RAM APS6408L-OBM for example). Key point is you need to avoid odd address write issue. In their use case, since the pixel was 2 bytes, the DMA2D should be 2 bytes aligned, so they had no odd address access.
Regards
Alex
2021-11-29 11:03 AM
Thanks for your reply @Alex - APMemory
We do run our IS66WVH8M8ALL with framebuffer the same way (16 bit color), and it works. However we had problems using more general data, so we decided changing to STM32H7 MCU to fully support the OSPI PSRAM.
Best Regards
2021-11-29 01:07 PM
OK, good to hear
If you need a compatible alternative in current tight period you can check APS6408L-OBM-BA.
Alex