[STM32H7B0][APS6404L-3SQR] Issue with Write in Memory Mapped Mode

[Ayoub Cheggari]

Hello Dear Community,

I am working on an HMI System and using STM32H7B0 with APS6404L-3SQR. I am able to do all operations including Write in Memory Mapped Mode but when I try to write 1 byte, It writes 8 bytes which is not what I expect.

I have read many discussions here, but all say that this problem shouldn't appear for H7Bx Platform as it supports the Memory Mapped Mode in write.

What do you think about this?

@Alex - APMemory, Please do you have any clues here?

This is my Code for the Memory Mapped Mode!

SHIP_Bool
SHIP_PSRAM_MMAP_Enable(){

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

/* Read Sequence */
sCommand.OperationType = HAL_OSPI_OPTYPE_READ_CFG;
sCommand.FlashId = HAL_OSPI_FLASH_ID_1;
sCommand.InstructionMode = HAL_OSPI_INSTRUCTION_4_LINES;
sCommand.AddressMode = HAL_OSPI_ADDRESS_4_LINES;
sCommand.AddressSize = HAL_OSPI_ADDRESS_24_BITS;
sCommand.AlternateBytesMode = HAL_OSPI_ALTERNATE_BYTES_NONE;
sCommand.DataMode = HAL_OSPI_DATA_4_LINES;
sCommand.SIOOMode = HAL_OSPI_SIOO_INST_EVERY_CMD;
sCommand.Instruction = FAST_READ_QUAD_DATA_CMD;
sCommand.DummyCycles = 6;

SHIP_ASSERT((HAL_OSPI_Command(&hospi1, &sCommand, HAL_OSPI_TIMEOUT_DEFAULT_VALUE) == HAL_OK), SHIP_LOG_SYSTEM);

/* Write Sequence */

sCommand.OperationType = HAL_OSPI_OPTYPE_WRITE_CFG;
sCommand.InstructionMode = HAL_OSPI_INSTRUCTION_4_LINES;
sCommand.AddressMode = HAL_OSPI_ADDRESS_4_LINES;
sCommand.AddressSize = HAL_OSPI_ADDRESS_24_BITS;
sCommand.AlternateBytesMode = HAL_OSPI_ALTERNATE_BYTES_NONE;
sCommand.DataMode = HAL_OSPI_DATA_4_LINES;
sCommand.DQSMode = HAL_OSPI_DQS_ENABLE; // See errata
sCommand.SIOOMode = HAL_OSPI_SIOO_INST_EVERY_CMD;
sCommand.Instruction = QUAD_WRITE_DATA_CMD;
sCommand.DummyCycles = 0;

SHIP_ASSERT((HAL_OSPI_Command(&hospi1, &sCommand, HAL_OSPI_TIMEOUT_DEFAULT_VALUE) == HAL_OK), SHIP_LOG_SYSTEM);

/* set up memory mapping */

/* release nCS after access, else no refresh */
sMemMappedCfg.TimeOutActivation = HAL_OSPI_TIMEOUT_COUNTER_DISABLE;

SHIP_ASSERT((HAL_OSPI_MemoryMapped(&hospi1, &sMemMappedCfg) == HAL_OK), SHIP_LOG_SYSTEM);

return SHIP_TRUE;}

[Tesla DeLorean]

The Read/Write memory mappings are really just command templates. Does the Write work via command mode?

[Ayoub Cheggari]

Thanks for you reply! Yes it does correctly.

The point here is that we want to use the PSRAM for code execution + Heap. With this happening, it seems impossible.

[KDJEM.1]

Hello @Ayoub Cheggari ,

There is an errata "Memory-mapped write error response when DQS output is disabled". So with this errata we need to enable the DQS when doing memory mapped writes even if the memory do not support DQS. This is the workaround as you did.

Now concerning products with AXI bus (OCTOSPI memory mapped region on AXI not AHB) the memory mapped write are always done in multiple of the AXI bus size (64-bit).

So when you do a 8-16-32 bit write , the OCTOSPI will output 64-bit and mask the rest using DQS pin. The problem is if the memory do not support DQS (which is in our case), the rest of the AXI data will be written to the memory. so if you write : *(__IO uint8_t *)0x90000000 = 0xFF, 0x90000000 will be written correctly but the data from address 0x90000001-0x90000007 will be corrupted. This is why we need to make access in 64-bit.

This is described here in the errata sheet : "If the DQS output is asserted on memory-mapped writes while the AXI bus transfer has some byte-enable bits deasserted, the bytes that should be masked get written to the memory."

Thank you for your contribution in STCommunity.

Kaouthar

[Ayoub Cheggari · Accepted solution]

I actually found the issue and maybe you can add it in the next versions of the UM.

The Data and Code Cache should be enabled prior to the Init of PSRAM to be able to make proper Writes.

[Piranha]

The cache just hides the issue, because it does 64-bit accesses to the memory. I am not sure it is guaranteed to always do only 64-bit accesses and that it is guaranteed to not bypass the cache for some accesses. If it is not guaranteed, then enabling cache cannot be a reliable solution.