STM32H7B0RBT6 with QSPI PSRAM APS6404L-3SQR

[ALAMI_Othmane]

Hi Community,

During a project we are using the microcontroller STM32H7B0RBT6 with QSPI PSRAM APS6404L-3SQR , it works fine in indirect mode either in quad read and quad write, but the issue is with the write in memory mapped mode when trying to write less than 8 byte, one for example (*((uint8_t*) (0x90000010))=0x55;) the 7 others  bytes are zeroed it seems that the write accept only 8 bytes if the data is less than 8 the other bytes are zeroed as you can see :

instead written 8 bytes (*((uint64_t*) (0x90000010))=0xA5A5A5A5A5A5A5A5ULL;) works fine !!

Did someone face a similar problem could please provide some suggestions to do, thanks,

Here I share the code that  I have used to  enable the memory mapped mode

OSPI_MemoryMappedTypeDef sMemMappedCfg = {0};
OSPI_RegularCmdTypeDef sCommand = {0};

/* set command to write to qspi ram */

sCommand.OperationType = HAL_OSPI_OPTYPE_WRITE_CFG;
sCommand.FlashId = HAL_OSPI_FLASH_ID_1;
sCommand.InstructionMode = HAL_OSPI_INSTRUCTION_4_LINES;
sCommand.InstructionSize = HAL_OSPI_INSTRUCTION_8_BITS;
sCommand.InstructionDtrMode = HAL_OSPI_INSTRUCTION_DTR_DISABLE;
sCommand.AddressMode = HAL_OSPI_ADDRESS_4_LINES;
sCommand.AddressSize = HAL_OSPI_ADDRESS_24_BITS;
sCommand.AddressDtrMode = HAL_OSPI_ADDRESS_DTR_DISABLE;
sCommand.AlternateBytesMode = HAL_OSPI_ALTERNATE_BYTES_NONE;
sCommand.DataMode = HAL_OSPI_DATA_4_LINES;
sCommand.DataDtrMode = HAL_OSPI_DATA_DTR_DISABLE;
sCommand.DQSMode = HAL_OSPI_DQS_ENABLE; /* Memory-mapped write error response when DQS output is disabled */
sCommand.SIOOMode = HAL_OSPI_SIOO_INST_EVERY_CMD;
sCommand.Instruction = QUAD_WRITE_DATA_CMD;
sCommand.Address = 0;
sCommand.NbData = 0;
sCommand.DummyCycles = 0;

if (HAL_OSPI_Command(&hospi1, &sCommand, HAL_OSPI_TIMEOUT_DEFAULT_VALUE)  != HAL_OK)

{

Error_Handler();

}

/* set command to read from spi ram */

sCommand.DQSMode = HAL_OSPI_DQS_DISABLE;
sCommand.OperationType = HAL_OSPI_OPTYPE_READ_CFG;
sCommand.Instruction = FAST_READ_QUAD_DATA_CMD;
sCommand.DummyCycles = 6;

if (HAL_OSPI_Command(&hospi1, &sCommand, HAL_OSPI_TIMEOUT_DEFAULT_VALUE)  != HAL_OK)

{

Error_Handler();

}

/* set up memory mapping */

/* release nCS after access, else no refresh */
sMemMappedCfg.TimeOutActivation = HAL_OSPI_TIMEOUT_COUNTER_ENABLE;
sMemMappedCfg.TimeOutPeriod = 1;

if (HAL_OSPI_MemoryMapped(&hospi1, &sMemMappedCfg) != HAL_OK)

{

Error_Handler();

}

[Piranha]

Its really a pity that ST didn't simulate and test this better or more robustly that it would be usable in reasonably anticipated use cases...

---

In my opinion such a serious and limiting flaw deserves another revision of the silicon.

@ALAMI_Othmane , regarding enabling the cache as a "solution", read my post there:

https://community.st.com/t5/stm32-mcus-products/stm32h7b0-aps6404l-3sqr-issue-with-write-in-memory-mapped-mode/m-p/597193/highlight/true#M224703

[Tesla DeLorean]

>In my opinion such a serious and limiting flaw deserves another revision of the silicon.

I don't think ST operates in that mode, and it also creates multiple steppings that behave differently, and gets to be a headache for the buyers or part sourcers to ensure you buy and build with a compatible part. They did it with the original H7 where we have X, Y and V steps (public ones), but it took them many years and masksets to get the parts to work properly. An unusual number honestly, but does point to a lack of rigor at the simulation stage, although admittedly a lot of complexity with core interactions, caching, etc, but I'm really focused on a peripheral level where the mechanics should be solidly understood.

This really needs to be owned at the design and validation stages.

The model used here is just to keep the design team moving and pivoting into new designs, fixing things, but not revisiting old designs with all the characterization and validation that would require. At a business level I suspect that's just not desirable.

We I suppose should just look for newer pin compatible parts and pivot into those as quickly as our design cycles permit.

[Piranha]

For H7 they changed the functionality, which is a terrible decision. When doing that, a new part number must be assigned. Silicon revisions should just fix the unintended flaws, which are serious enough. Unfortunately even that creates an uncertainty for buyers, but, if done relatively soon after the release, it pays off in the long term.

[ALAMI_Othmane]

In your opinion, what would be a good solution without enabling the cache and configuring the MPU?

[Piranha]

I would start with finding out whether the cache guarantees or can be configured in such a way that it is guaranteed to not bypass cache for any access and all accesses are 64-bit wide. If that is not the case, then only a software methods can provide a reliable solution.

[Alex - APMemory]

Hi Othmane,

The "only" limitation is Memory Mapped write with QSPI SDR & STM32H7B0RB

Alex

[shuocao]

Thank you, I am also facing the same problem and I decide to not using memory-mapped mode, but simply indirect mode for buffering in my DAQ application.

[ALAMI_Othmane · Accepted solution]

This memory require a specific refresh value that resolve the issue, now it's working fine and stable with the memory mapped mode, we have actually used as a heap for our application contain the frame buffer and all others data

to make it work, you need to:
- Configure the MPU for the specific mapped addresses area

- Pay attention to the refresh value ( should equal 241)  when initializing the octospi interface to have better stability for values stored in this ram

[SMazu.3]

can you give me the the source file pls?