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.

[Myasu.1]

Hello @KDJEM.1 

I’m sorry for the late reply.

Let me report Result when CSBOUND is set to 3 or 8 (SSHIFT is DISABLE).

The environment is as follows.

• The write data is the program I want to run and the size is 2,220byte
• Frequency is 500 kHz

The results are as follows.
Just in case, let me also report the results of reading using Indirect Mode.

• CSBOUND = 3
  [Memory Mapped Mode]
  Reading using memory mapped mode resulted in 37 data not as expected.
  The data screenshot is written in [SSHIFT_DISABLE_CSBOUND_ENABLE_3_read_using_Memory_mapped_mode.txt].
  [Indirect Mode]
  All read data one byte at a time is as expected.
  (written in [SSHIFT_DISABLE_CSBOUND_ENABLE_3_read_one_byte_at_a_time.txt])
  Reading all 2220 bytes of data at once results in 64 data not as expected. 
  
• CSBOUND = 8
  [Memory Mapped Mode]
  Reading using memory mapped mode resulted in 108 data not as expected.
  The data screenshot is written in [SSHIFT_DISABLE_CSBOUND_ENABLE_8_read_using_Memory_mapped_mode.txt]
  [Indirect Mode]
  All read data one byte at a time is as expected.
  Reading all 2220 bytes of data at once results in more than 512 data not as expected. 

It seems that it is important to know when to negate CS.
Do you have any insights from the above information?

[KDJEM.1 · Accepted solution]

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.