Write/Read issues with HyperRAM S70KL1282 on OctoSPI2 (STM32H7A3)

[GS1]

I am currently ramping up a new project which has a HyperRAM installed (S70KL1282 - like in the example project of STM32H735G).

With the help of this sample project code I can successfully write and read with memory mapped mode from the 16 MB RAM - but not 100%.

I implemented a test routine, which counts the read errors of faulty reads after writing a pattern to the RAM. I get between 15 and 40 faulty read accesses when checking the complete 16 MB Ram.

I tried to change the initialisation parameters for the OctoSPI (clock prescaler, CS high time, recovery time etc. But this doesn't solve the problem.

I tried "rewriting after faulty read" - which is however not a solution:

After detecting a faulty read, rewriting the pattern and reading it again: returns correct readings. So the RAM seems to be working in general.

Can anyone tell, which parameters might be responsible for the wrong writings/readings?

Any suggestions welcome!

BR GS

[Alex - APMemory]

Hi,

This is strange, especially if you already tried to decrease the frequency.

If you can't make it work, you can try this 128Mb OPI device (APS12808L-3OBM-BA) and replace on your PCB. We have made it works without any issue.

https://www2.mouser.com/ProductDetail/AP-Memory/APS12808L-3OBM-BA?qs=IS%252B4QmGtzzrXcGkbuYahqw%3D%3D

regards

Alex

[GS1 · Accepted solution]

Hello Alex,

thank you for your reply.

Meanwhile we succeeded to get it to work.

The solution was to adapt the various initialisation parameters. I now set them as follows and it works (solving changes in bold):

void MX_OCTOSPI2_Init(void)

{

 /* USER CODE BEGIN OCTOSPI2_Init 0 */

 /* USER CODE END OCTOSPI2_Init 0 */

 OSPIM_CfgTypeDef sOspiManagerCfg = {0};

 OSPI_HyperbusCfgTypeDef sHyperBusCfg = {0};

 /* USER CODE BEGIN OCTOSPI2_Init 1 */

 /* USER CODE END OCTOSPI2_Init 1 */

 hospi2.Instance = OCTOSPI2;

 hospi2.Init.FifoThreshold = 4;

 hospi2.Init.DualQuad = HAL_OSPI_DUALQUAD_DISABLE;

 hospi2.Init.MemoryType = HAL_OSPI_MEMTYPE_HYPERBUS;

 hospi2.Init.DeviceSize = 24;

 hospi2.Init.ChipSelectHighTime = 1;

 hospi2.Init.FreeRunningClock = HAL_OSPI_FREERUNCLK_DISABLE;

 hospi2.Init.ClockMode = HAL_OSPI_CLOCK_MODE_0;

 hospi2.Init.WrapSize = HAL_OSPI_WRAP_NOT_SUPPORTED;

 hospi2.Init.ClockPrescaler = 2;

 hospi2.Init.SampleShifting = HAL_OSPI_SAMPLE_SHIFTING_NONE;

 hospi2.Init.DelayHoldQuarterCycle = HAL_OSPI_DHQC_ENABLE;

 hospi2.Init.ChipSelectBoundary = 23;

 hospi2.Init.DelayBlockBypass = HAL_OSPI_DELAY_BLOCK_USED;

 hospi2.Init.MaxTran = 0;

 hospi2.Init.Refresh = 240;

 if (HAL_OSPI_Init(&hospi2) != HAL_OK)

 {

   Error_Handler();

 }

 sOspiManagerCfg.ClkPort = 2;

 sOspiManagerCfg.DQSPort = 2;

 sOspiManagerCfg.NCSPort = 2;

 sOspiManagerCfg.IOLowPort = HAL_OSPIM_IOPORT_2_LOW;

 sOspiManagerCfg.IOHighPort = HAL_OSPIM_IOPORT_2_HIGH;

 if (HAL_OSPIM_Config(&hospi2, &sOspiManagerCfg, HAL_OSPI_TIMEOUT_DEFAULT_VALUE) != HAL_OK)

 {

   Error_Handler();

 }

 sHyperBusCfg.RWRecoveryTime = 3;

 sHyperBusCfg.AccessTime = 7;

 sHyperBusCfg.WriteZeroLatency = HAL_OSPI_LATENCY_ON_WRITE;

 sHyperBusCfg.LatencyMode = HAL_OSPI_VARIABLE_LATENCY;

 if (HAL_OSPI_HyperbusCfg(&hospi2, &sHyperBusCfg, HAL_OSPI_TIMEOUT_DEFAULT_VALUE) != HAL_OK)

 {

   Error_Handler();

 }

 /* USER CODE BEGIN OCTOSPI2_Init 2 */

 /* USER CODE END OCTOSPI2_Init 2 */

}

After all it seems to me that this RAM is very critical to small changes of the parameters to get it to fail or to work. My trust in the RAM therefore is a bit insecure and up to now I avoid to use it if not necessary. The next project will bring more confidence in it - at lease I hope so as this then will need the RAM for LCD frames.

BR GS

[Alex - APMemory]

Hi,

IoT RAM is running in mu/m including with STM32 SoC and frame buffering application, so you can be sure this is a safe and most effective RAM solution for MCU application. It goes from 16Mb up to 512Mb density, with only 6 signal pins for QSPI & 11 pins for OPI. We can provide set up up upon need. We can trust this solution for future design !

Alex

[AS1956]

Thanks, had the same issue with the same chip. Its custom board so wasn't sure if this was hardware issue or setup  Your numbers seem to work. You saved me a lot of time.