[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]

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.

[Zhou JianQiang]

@KDJEM.1 :

Hi , Can you help confirm whether it is guaranteed to always do only 64-bit accesses and that it is guaranteed to not bypass the cache for some accesses after enable cache as Piranha said above?

[KDJEM.1]

Hello @Zhou JianQiang ,

 

When making tests be sure to always disable cache to avoid issue masking.

The guaranteed is:

So, this workaround may be does not work for products where memory-mapped write operations are sent via an AXI bus.

Thank you.

Kaouthar

[Zhou JianQiang]

Hi @KDJEM.1 :

what about enable MPU, will this issue fixed if I enable MPU?

Because I also read from thread below:

https://community.st.com/t5/stm32-mcus-products/stm32h7b0rbt6-with-qspi-psram-aps6404l-3sqr/m-p/596182?

 

If it still can' fix, what about STM32H723ZG? Does this IC have same issue when doing a 8-16-32 bit write ?

Because I don't find the below sentence in  Errata sheet:

But in thread below, it seems STM32H723ZG have same issue:

https://community.st.com/t5/stm32-mcus-products/stm32h723-problem-with-serial-ram-in-memory-mapped-mode/m-p/229476

 

[KDJEM.1]

Hello @Zhou JianQiang ,

 

Now, no MPU configuration or cache workaround is mentioned in the errata sheet.

Thank you for bringing the STM32H723 errata sheet issue, I reported internally.

Internal ticket number: 191784 (This is an internal tracking number and is not accessible or usable by customers).

 

Thank you.

Kaouthar