about Execute in place using dual quad spi

[Myasu.1]

What I want to do is XIP with DUAL QUAD SPI.
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

The connection diagram of the board and FLASH is shown below.

The registers are set as follows.

●OCTOSPI

●OCTOSPIM

In advance, programs to be operated are written in W25Q64JV1 and W25Q64JV2.

When the address of the main function of the program is set in the program counter, an exception occurs and the program cannot be executed.

I have checked the assembly from the debugger and have confirmed that the written program is readable as expected as follows.

By the way, when I wrote the program to W25Q64JV1 only, not dual-quad-spi, and set the address of the main function in the program counter in the same way, it worked as expected.

Can you please advise if there are any register settings, etc. that are missing?

[Tesla DeLorean]

Not unpacking bitmaps or registers..

Show source, use the </> pasting tool.

It Hard Fauts? Dump that failure context.

[Myasu.1]

Hello @Tesla DeLorean 

Thank you for quick reply.

The code to jump to the main function in Flash is as follows.
The following code is executed after the register settings posted previously.

 

#define FLASH_PROGRAM_ADDR		(0x90000581)
・・・
// Execute in place
static void loading_app_msg_xip(uint32_t par)
{
	volatile int (*f)(void);
	
	// jump to main function in exterbal Flash
	f = (int(*)(void))(FLASH_PROGRAM_ADDR);
	f();
}

 

If a breakpoint is set at line 10 above and step execution is performed from there, a hardfault will occur.

I understand that a Hard Fault occurred because the 0~8 bits of XPSR are 3.

Register information when an exception occurs.

[KDJEM.1]

Hello @Myasu.1 ,

Did you get "Hard Fault"?

Could you please check the OCTOSPIM errata section 2.9 for STM32L4R5.

Unaligned write access to OCTOSPIM configuration registers is discarded, with hard fault. The de-assertion of hready AHB signal then takes three cycles, which is not compliant with the AHB standard that defines two cycles.
Workaround: Avoid unaligned write accesses to OCTOSPIM configuration registers.

May be this example can help you: OSPI_NOR_ExecuteInPlace

Thank you.

Kaouthar

 

[Myasu.1]

Hello @KDJEM.1 

Thank you for quick reply.

I understand that a Hard Fault occurred because the 0~8 bits of XPSR are 3.

Thank you for sharing Elatta. I am going to check it out.

[Myasu.1]

Hello @KDJEM.1 

I understand that the example does not use DUAL-QUAD-SPI.

Is there a example of XIP using DUAL-QUAD-SPI?

[Myasu.1]

Hello @KDJEM.1 @Tesla DeLorean 

As shown below, I pulled up CS and did Excute In Place using DUAL-QUAD-SPI as expected.

However, let me confirm one concern.

Currently, I do Execute in place by writing the following program to external flash.

int main(void)
{	
	GPIO_InitTypeDef cfg;
	volatile uint32_t i;
	
	cfg.Pin = GPIO_PIN_7;
	cfg.Mode = GPIO_MODE_OUTPUT_PP;
	cfg.Pull = GPIO_NOPULL;
	cfg.Speed = GPIO_SPEED_FREQ_LOW;
	cfg.Alternate = 0;
	
	// enable clock
	__HAL_RCC_PWR_CLK_ENABLE();
	__HAL_RCC_GPIOC_CLK_ENABLE();
	HAL_PWREx_EnableVddIO2();
	
	// led pin function
	HAL_GPIO_WritePin(GPIOC, GPIO_PIN_7, GPIO_PIN_RESET);
	HAL_GPIO_Init(GPIOC, &cfg);
	
	// LED blink
 	while (1) {
 		HAL_GPIO_WritePin(GPIOC, GPIO_PIN_7, 1);
 		for (i = 0; i < 10000; i++) {}
 		HAL_GPIO_WritePin(GPIOC, GPIO_PIN_7, 0);
 		for (i = 0; i < 10000; i++) {}
	}
	
	return 0;
}

I guessed that if I do execute in place using two external flashes with DUAL-QUAD-SPI, it would be twice as fast as doing execute in place with a single external flash, but it is not the case. Specifically, the above program would be a program to blink LEDs, but both had the same blink cycle.

Is there any reason why it did not double?

[Myasu.1]

Hello @KDJEM.1 @Tesla DeLorean 

I am very sorry.

When doing Execute in Place with two external flashes, I had set the clock to half. When I set the clock to the same clock as when I did Execute In place with one external flash, the LED blinking period doubled.

 

[Myasu.1]

Hello @KDJEM.1 @Tesla DeLorean 

I apologize again and again.

After several XIPs, the XIP doesn't work anymore. The program itself has not changed.

I share the source files with you and would appreciate if you could check them out.

The following is a brief description of the functions in the program.

• octospi_sample_open
  Initialize OCTOSPI and set Memory Mapped Mode
• flash_mng_cmd_mem_mapped_read
  Read flash data using memory-mapped mode
• loading_app_msg_xip
  Jump to Flash program

When reading data using flash_mng_cmd_mem_mapped_read, data stored in the first half area can be read as expected, but data stored in the second half area is 0xFF and cannot be read as expected.

 

flash_mng mem_mapped_read 1408
==================== read ============================
 | 0 1 2 3 4 5 6 7 8 9 A B C D E F
------------------------------------------------------
0x00 | 80 B5 88 B0 00 AF 80 23 FB 60 01 23 3B 61 00 23
0x10 | 7B 61 00 23 BB 61 00 23 FB 61 23 4A 22 4B 9B 6D
0x20 | 43 F0 80 53 93 65 20 4B 9B 6D 03 F0 80 53 7B 60
0x30 | 7B 68 1D 4A 1C 4B DB 6C 43 F0 04 03 D3 64 1A 4B
0x40 | DB 6C 03 F0 04 03 3B 60 3B 68 FF F7 C9 FF 00 22
0x50 | 80 21 16 48 FF F7 AC FF 07 F1 0C 03 19 46 13 48
0x60 | FF F7 14 FE 01 22 80 21 10 48 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

 

I run the same program, but sometimes I can do XIP as expected, and sometimes I can't.
Do you know what the difference is?

For example, do you think that setting IO0 ~ IO7 to pull-ups is a countermeasure?

[KDJEM.1]

Hi @Myasu.1 ,

Could you please try to decrease the OCTOSPI frequency?

Also, please make sure that:

- All OCTOSPI GPIOs are set to very-high speed

- Disable the timeout feature

Thank you.

Kaouthar