FLASH data cannot be read as expected using Memory Mapped Mode

[Myasu.1]

I would like to read external FLASH data using Memory Mapped mode, which is a function of OctoSPI.
The environment is as follows.

Use Board : nucleo l4r5zi
IDE : Atollic TrueSTUDIO® for STM32, Built on Eclipse Neon.1a.(Version: 9.3.0)
FLASH : W25Q64JV

Currently, when FLASH data is read using Memory Mapped Mode, some data is unreadable.
Specifically, 0xFF, 0xCC, and 0x88 are read.
I have already confirmed that the data can be read as expected when read in indirection mode.

The procedure is as follows.

1. Set for Memory Mapped Mode
    Specifically, the register settings are as follows.

2. Reading FLASH data
    The offset from 0x9000_0000 is stored in argv[2], and the program reads 256 bytes of data from that location.

 

 

 

 

static void flash_mng_cmdt_mem_mapped_read(int argc, char *argv[])
{
	uint8_t *base_addr = (uint8_t*)0x90000000;
	uint32_t i, j, k;
	uint8_t data;
	
	ofst = atoi(argv[2]);
	
	base_addr = base_addr + ofst;
	
	for (i = 0; i < 16; i++) {
		for (j = 0; j < 16; j++) {
			k = i*16+j;
			data = *(base_addr+k);
		}
	}
}

 

 

 

 

3. Reading Results
    I have implemented a console in my own work, and I can access the flash by executing commands from the console. In the following case, 256 bytes of data are read from 0x9000000 + 0x200 (512). The values up to 0x49 below are as expected, but after that they are 0xFF and not as expected.

command>flash_mng mem_mapped_read 512
==================== read ============================
 | 0 1 2 3 4 5 6 7 8 9 A B C D E F
------------------------------------------------------
0x00 | 01 2B 00 2A FB D1 18 1A 01 38 70 47 80 B4 00 AF
0x10 | 03 4B 1B 68 18 46 BD 46 5D F8 04 7B 70 47 00 BF
0x20 | A0 07 04 20 80 B4 00 AF 04 4B DB 68 1B 0A 03 F0
0x30 | 07 03 18 46 BD 46 5D F8 04 7B 70 47 00 ED 00 E0
0x40 | 80 B4 83 B0 00 AF 03 46 39 60 FF FF FF FF FF FF
0x50 | FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
0x60 | FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
0x70 | FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
0x80 | FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
0x90 | FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
0xA0 | FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
0xB0 | FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
0xC0 | FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
0xD0 | FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
0xE0 | FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
0xF0 | FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

 When a breakpoint is placed at line 14 of the above program and the program is stopped and executed every time 1 byte is read, the value goes from 0xFF to 0x88.

I assume there is a timing issue based on the above, but please let me know if you know anything.

[KDJEM.1]

Hello @Myasu.1 ,

Could you please check the OCTOSPI configuration parameters like Devise size, Delay hold quarter cycle:  enabled in DTR mode and disabled in STR mode, Chip select boundary (CSBOUND) configured depending on the memory datasheet. The chip select must go high when crossing the page boundary (2^CSBOUND bytes defines the page size).

I recommend you to take a look to the errata sheet and precisely 2.8.13 Memory-mapped read of the last memory space byte not possible in SDR octal-SPI mode.

Workaround: Apply one of the following measures:
• Avoid reading the last byte of the memory space through memory-mapped access. Use indirect read
instead.
• Set DEVSIZE value so that the memory space it defines exceeds the memory size, then handle the memory
boundary by software.

May be this example OSPI_NOR_MemoryMapped can help you.

Could you please share the memory datasheet and the OCTOSPI configuration code?

I hope this help you.

Kaouthar

 

[Myasu.1]

Hello @KDJEM.1 

Thank you for your response.

I would like to check the errata sheet, register settings, and Workarounds as advised.

I share memory datasheet and OCTOSPI configuration code with you and would appreciate it if you could check as well.

・memory datasheet
w25q64jv revj 03272018 plus.pdf

・OCTOSPI configuration code
octspi.c/h

I cannot show you the whole code, so I have extracted only the parts that are necessary.

Let me briefly describe the contents of the source code.
Set up to use OCTOSPI in octospi_open and then call octospi_memory_mapped to set up Memory Mapped mode.

When reading, the register is set to use the following commands.
w25q64jv revj 03272018 plus.pdf p31

The register values after calling octospi_open and octospi_memory_mapped will be as listed in the first QA.

[KDJEM.1]

Hello @Myasu.1 ,

Could you please check the SSHIFT. So SSHFT can be enabled when reading from the memory in SDR mode but must not be used in DTR mode. When enabled, the sampling is delayed by one more 1/2.

 Please try:

- To decrease the OCTOSPI frequency.

- Disable the Timeout counter, the user must consider that enabling timeout counter in Memory-mapped mode
may increase the command overhead and then decrease the read performance. 

Are you see the same issue when reading in indirect mode?

These recommendations may help you to solve the issue and clarify the its causes.

I hope this help you!

Thank you.

Kaouthar

 

 

[Myasu.1]

Hello @KDJEM.1 

Thanks very much for many advices.
I am very sorry for the delay in responding.

I will check this weekend as I don't have time now.
I will report the result of the confirmation this weekend.

[KDJEM.1]

Hello @Myasu.1 ,

Thank you for this update.

I set CSBOUND to 3 and the result changed.
It read mostly as expected, but a few bytes did not read as expected. All data not read as expected was 0xFF.

I set it to 8, which resulted in more data not being read as expected compared to setting it to 3.

Could you please share a data screenshot when using  CSBOUND=3 and  CSBOUND=8?

Please check the Refresh rate value, it may be a timing configuration issue.

Note the chip select must go high each (REFRECH x OCTOSPI clock cycles), configured depending on the memory datasheet.

Please try to decrease the OCTOSPI frequency.

Thank you.

Kaouthar

[Myasu.1]

Hello @KDJEM.1 

Thanks for the advice.

I'm sorry to bother you over and over.
I can't confirm this week as I can't find the time.
Please wait until next weekend to check and report back.

I am very sorry for not being able to confirm immediately, dispite you advise me.
I want to solve the problem, so please continue your support.

[Myasu.1]

Hello @KDJEM.1 

I’m sorry for the late reply.

I tried to reproduce the phenomenon, but was unable to do so.

After all, now the data can be read using Memory Mapped Mode with SSHIFT disabled and CSBOUND disabled.

I wonder why it was not readable before and now it is. For now, the data can be read, so I'll close this QA once and for all.

Thank you very much for your help.

[KDJEM.1]

Hi again @Myasu.1 ,

Thank you for updating past and thank you for your contribution in STCommunity :).

It is mentioned in the errata sheet of STM32L4R5 in Section "2.8.1 CSBOUND must not be used" section that CSBOUND feature does not work properly and must not be used. The CSBOUND[4:0] bitfield of the OCTOSPI_DCR3 register must be left at its reset default value (0b00000).

If you need further clarification, please do not hesitate to share it.

Thank you.

Kaouthar

[Myasu.1]

@KDJEM.1 

I’m sorry for the late reply.

Let me confirm the following, as I have some concerns.

As usual, reading data using Memory Mapped Mode does not work as expected.

Currently, I use OCTOSPI CH1 with the following pin settings.

OCTOSPIM_P1_NCS : PA4
OCTOSPIM_P1_CLK : PF10
OCTOSPIM_P1_IO0 : PF8
OCTOSPIM_P1_IO1 : PF9
OCTOSPIM_P1_IO2 : PF7
OCTOSPIM_P1_IO3 : PF6
OCTOSPIM_P1_IO4 : PD4
OCTOSPIM_P1_IO5 : PC2
OCTOSPIM_P1_IO6 : PD6
OCTOSPIM_P1_IO7 : PD7

When I put a tester on OCTOSPIM_P1_NCS(PA4) and OCTOSPIM_P1_IO3 (PF6) respectively, I found that each of them is short-circuited.

Currently, I use a Quad Read with Memory Mapped, and assume that due to this short circuit, the data is not being read as expected.（For your information, Single Read with Memory Mapped reads as expected）

OCTOSPIM_P1_NCS(PA4) and OCTOSPIM_P1_IO3 (PF6) are shorted, is this expected?

Just in case, I share the register setting values of OCTOSPIM.

 

[Myasu.1]

hello @KDJEM.1 

I would like to close this ticket as it has been resolved on this side.

Thank you for your cooperation.