About the problem that stm32h747i_disco_m7 qspi flash cannot work normally

[wugensheng-code]

I try to build mcuboot for stm32h747i_disco_m7, and plan to store the application image on the flash connected to qspi, but now I find that the driver of qspi nor flash cannot work properly, who can help me?

Here is my device tree snippet：

&quadspi {
	pinctrl-0 = <&quadspi_clk_pb2 &quadspi_bk1_ncs_pg6
		     &quadspi_bk1_io0_pd11 &quadspi_bk1_io1_pf9
		     &quadspi_bk1_io2_pf7 &quadspi_bk1_io3_pf6
			 &quadspi_bk2_io0_ph2 &quadspi_bk2_io1_ph3
			 &quadspi_bk2_io2_pg9 &quadspi_bk2_io3_pg14>;
	pinctrl-names = "default";
	status = "okay";

	mt25ql512ab1: qspi-nor-flash-1@0 {
		compatible = "st,stm32-qspi-nor";
		reg = <0>;
		qspi-max-frequency = <72000000>;
		size = <DT_SIZE_M(64*8)>;
		reset-gpios = <&gpiof 6 GPIO_ACTIVE_LOW>;
		reset-gpios-duration = <1>;
		spi-bus-width = <4>;
		status = "okay";

		partitions {
			compatible = "fixed-partitions";
			#address-cells = <1>;
			#size-cells = <1>;

			slot0_partition: partition@90000000 {
				label = "image-0";
				reg = <0x90000000 DT_SIZE_K(2048)>;
			};
			slot1_partition: partition@90200000 {
				label = "image-1";
				reg = <0x90200000 DT_SIZE_K(2048)>;
			};
			scratch_partition: partition@90400000 {
				label = "image-scratch";
				reg = <0x90400000 DT_SIZE_K(1024)>;
			};
		};
	};

	mt25ql512ab2: qspi-nor-flash-2@0 {
		compatible = "st,stm32-qspi-nor";
		reg = <0>;
		qspi-max-frequency = <72000000>;
		size = <DT_SIZE_M(64*8)>;
		// reset-gpios = <&gpiog 14 GPIO_ACTIVE_LOW>;
		status = "okay";
	};
};

This is my serial output：

From the driver code of qspi, it can be seen that when reading SFDP magic fails, the driver will return directly, so can someone tell me where is the problem?

[erwango]

@FRASTM ?

[FRASTM]

Let my try with a stm32h745 disco if I can see similar issue (as I do not have a stm32h747i_disco)

[FRASTM]

There are some pieces missing in the qspi driver to obtain the expected result :

$ west build -p auto -b stm32h747i_disco_m7 samples/drivers/jesd216/

*** Booting Zephyr OS build zephyr-v3.3.0-1723-g75e9c587d8a4 ***
qspi-nor-flash-1@0: SFDP v 1.6 AP ff with 2 PH
PH0: ff00 rev 1.6: 16 DW @ 30
Summary of BFP content:
DTR Clocking supported
Addressing: 3- or 4-Byte
4-KiBy erase: uniform
Support QSPI XIP
Support 1-1-1
Support 1-1-2: instr 3Bh, 1 mode clocks, 7 waits
Support 1-1-4: instr 6Bh, 1 mode clocks, 7 waits
Support 1-2-2: instr BBh, 1 mode clocks, 7 waits
Support 1-4-4: instr EBh, 1 mode clocks, 9 waits
Support 2-2-2: instr BBh, 1 mode clocks, 7 waits
Support 4-4-4: instr EBh, 1 mode clocks, 9 waits
Flash density: 67108864 bytes
ET1: instr 20h for 4096 By; typ 48 ms, max 480 ms
ET2: instr D8h for 65536 By; typ 160 ms, max 1600 ms
ET3: instr 52h for 32768 By; typ 112 ms, max 1120 ms
Chip erase: typ 62464 ms, max 1499136 ms                                        
Byte program: type 15 + 1 * B us, max 360 + 24 * B us                           
Page program: typ 120 us, max 2880 us                                           
Page size: 256 By                                                               
Suspend: 75h ; Resume: 7Ah                                                      
DPD: Enter B9h, exit ABh ; delay 30000 ns ; poll 0x3e                           
HOLD or RESET Disable: supported                                                
QER: 0                                                                          
0-4-4 Mode methods: entry 0x2 ; exit 0x03                                       
4-4-4 Mode sequences: enable 0x14 ; disable 0xa                                 
4-byte addressing support: enter 0x36, exit 0x0f6                               
Soft Reset and Rescue Sequence support: 0x3d                                    
Status Register 1 support: 0x01                                                 
size = <536870912>;                                                             
sfdp-bfp = [                                                                    
        e5 20 fb ff  ff ff ff 1f  29 eb 27 6b  27 3b 27 bb                      
        ff ff ff ff  ff ff 27 bb  ff ff 29 eb  0c 20 10 d8                      
        0f 52 00 00  24 4a 99 00  8b 8e 03 e1  ac 01 27 38                      
        7a 75 7a 75  fb bd d5 5c  4a 0f 82 ff  81 bd 3d 36                      
        ];                                                                      
PH1: ff84 rev 1.0: 2 DW @ 80                                                    
sfdp-ff84 = [                                                                   
        ff e7 ff ff  21 dc ff ff                                                
        ];                                                                      
jedec-id = [32 31 20];   

[FRASTM]

I'am currently Preparing a PR for this : #56279
You can have a look there

[wugensheng-code]

Thanks for your prompt help, I'll go and verify it works.

[wugensheng-code]

I would like to ask, if the attribute of flash-id is on the qspi node, how to use dual flash memory, because a qspi device tree node can only instantiate one driver.

[jurenat]

Hello @FRASTM ,
have you tried the STM32H745I-Disco board with the mentioned project? I am experiencing some issues when I use the jesd216 example. For me, the sample is not working after flashing it, but I need to unplug the power and power cycle the whole board (a simple chip reset, via reset button, is not working no matter how many times I do it). If I do not power-cycle it, the sample will fail with this log:

qspi-nor-flash-1@90000000: device not ready
[00:00:00.000,000] <dbg> flash_stm32h7: stm32h7_flash_init: Flash initialized. BS: 32
[00:00:00.000,000] <dbg> flash_stm32h7: stm32h7_flash_init: Block 0: bs: 131072 count: 16
[00:00:00.000,000] <dbg> flash_stm32h7: flash_stm32h7_write_protection: Disable write protection
[00:00:00.000,000] <dbg> flash_stm32_qspi: qspi_send_cmd: Instruction 0x66
[00:00:00.000,000] <dbg> flash_stm32_qspi: qspi_send_cmd: CCR 0x166
[00:00:00.000,000] <dbg> flash_stm32_qspi: qspi_send_cmd: Instruction 0x99
[00:00:00.000,000] <dbg> flash_stm32_qspi: qspi_send_cmd: CCR 0x199
[00:00:00.000,000] <inf> flash_stm32_qspi: Reading SFDP
[00:00:00.000,000] <err> flash_stm32_qspi: SFDP magic 00000000 invalid
*** Booting Zephyr OS build v3.6.0-4041-g4efc03520966 ***

The log is clear, the SFDP read fails and the communication with FLASH does not work. I added reset-cmd; and reset-cmd-wait = <2>; to the node mt25ql512ab1 in an attempt to perform a SW restart of the memory but without success. I can see on the oscilloscope, that the sequence is done as described in FLASH datasheet.

I also tried to debug the issue and when I delay the initialization by putting a breakpoint at begin the offlash_stm32_qspi_init function, reset the FLASH memory with tweezers (using nReset pin), and then continue with initialization, the sample also works. Have you noticed similar behaviour with your board?

[FRASTM]

Hello @FRASTM , have you tried the STM32H745I-Disco board with the mentioned project? I am experiencing some issues when I use the jesd216 example. For me, the sample is not working after flashing it, but I need to unplug the power and power cycle the whole board (a simple chip reset, via reset button, is not working no matter how many times I do it). If I do not power-cycle it, the sample will fail with this log:

qspi-nor-flash-1@90000000: device not ready
[00:00:00.000,000] <dbg> flash_stm32h7: stm32h7_flash_init: Flash initialized. BS: 32
[00:00:00.000,000] <dbg> flash_stm32h7: stm32h7_flash_init: Block 0: bs: 131072 count: 16
[00:00:00.000,000] <dbg> flash_stm32h7: flash_stm32h7_write_protection: Disable write protection
[00:00:00.000,000] <dbg> flash_stm32_qspi: qspi_send_cmd: Instruction 0x66
[00:00:00.000,000] <dbg> flash_stm32_qspi: qspi_send_cmd: CCR 0x166
[00:00:00.000,000] <dbg> flash_stm32_qspi: qspi_send_cmd: Instruction 0x99
[00:00:00.000,000] <dbg> flash_stm32_qspi: qspi_send_cmd: CCR 0x199
[00:00:00.000,000] <inf> flash_stm32_qspi: Reading SFDP
[00:00:00.000,000] <err> flash_stm32_qspi: SFDP magic 00000000 invalid
*** Booting Zephyr OS build v3.6.0-4041-g4efc03520966 ***

The log is clear, the SFDP read fails and the communication with FLASH does not work. I added reset-cmd; and reset-cmd-wait = <2>; to the node mt25ql512ab1 in an attempt to perform a SW restart of the memory but without success. I can see on the oscilloscope, that the sequence is done as described in FLASH datasheet.

I also tried to debug the issue and when I delay the initialization by putting a breakpoint at begin the offlash_stm32_qspi_init function, reset the FLASH memory with tweezers (using nReset pin), and then continue with initialization, the sample also works. Have you noticed similar behaviour with your board?

Hello,
Yes, I noticed similar behaviour with stm32h745 and stm32h747 disco kits:
The SFDP is correctly read after poworing off/on the target board

*** Booting Zephyr OS build v3.6.0-4147-gadeb19b30cbf ***
qspi-nor-flash-1@90000000: SFDP v 1.6 AP ff with 2 PH
PH0: ff00 rev 1.6: 16 DW @ 30
Summary of BFP content:
DTR Clocking supported
Addressing: 3- or 4-Byte
4-KiBy erase: uniform
Support QSPI XIP
Support 1-1-1
Support 1-1-2: instr 3Bh, 1 mode clocks, 7 waits
Support 1-1-4: instr 6Bh, 1 mode clocks, 7 waits
Support 1-2-2: instr BBh, 1 mode clocks, 7 waits
Support 1-4-4: instr EBh, 1 mode clocks, 9 waits
Support 2-2-2: instr BBh, 1 mode clocks, 7 waits
Support 4-4-4: instr EBh, 1 mode clocks, 9 waits
Flash density: 67108864 bytes
ET1: instr 20h for 4096 By; typ 48 ms, max 480 ms
ET2: instr D8h for 65536 By; typ 160 ms, max 1600 ms
ET3: instr 52h for 32768 By; typ 112 ms, max 1120 ms
Chip erase: typ 62464 ms, max 1499136 ms
Byte program: type 15 + 1 * B us, max 360 + 24 * B us                           
Page program: typ 120 us, max 2880 us                                           
Page size: 256 By                                                               
Suspend: 75h ; Resume: 7Ah                                                      
DPD: Enter B9h, exit ABh ; delay 30000 ns ; poll 0x3e                           
HOLD or RESET Disable: supported                                                
QER: 0                                                                          
0-4-4 Mode methods: entry 0x2 ; exit 0x03                                       
4-4-4 Mode sequences: enable 0x14 ; disable 0xa                                 
4-byte addressing support: enter 0x36, exit 0x0f6                               
Soft Reset and Rescue Sequence support: 0x3d                                    
Status Register 1 support: 0x01                                                 
size = <536870912>;                                                             
sfdp-bfp = [                                                                    
        e5 20 fb ff  ff ff ff 1f  29 eb 27 6b  27 3b 27 bb                      
        ff ff ff ff  ff ff 27 bb  ff ff 29 eb  0c 20 10 d8                      
        0f 52 00 00  24 4a 99 00  8b 8e 03 e1  ac 01 27 38                      
        7a 75 7a 75  fb bd d5 5c  4a 0f 82 ff  81 bd 3d 36                      
        ];                                                                      
PH1: ff84 rev 1.0: 2 DW @ 80                                                    
sfdp-ff84 = [                                                                   
        ff e7 ff ff  21 dc ff ff                                                
        ];                                                                      
jedec-id = [32 31 20];           

[jurenat]

Thanks for your response, I experience the same behaviour. Do you have any idea why this is happening?

[FRASTM]

Thanks for your response, I experience the same behaviour. Do you have any idea why this is happening?

Not 100% sure if it could be linked to the dual flash mode : when resetting the memory, the reset_cmd is sent to only one quad-Nor device (the one specified by the )
It could be a problem with the reset command sent to the dual quad flash at init or a missing command from the runner.
When Runner is the STM32CubeProgrammer, flashing the samples/drivers/jesd216/ will always give a correct SFDP (even after flashing samples/hello_world)
When Runner is the openOCD, flashing the samples/drivers/jesd216/ will always give a un-valid SFDP (even after flashing samples/hello_world). Only a power Off/On can recover the error. Then he SFDP is always correct until the next 'west flash'.

[FRASTM]

Second, I think there is a confusion in the #define STM32_QSPI_RESET_CMD DT_INST_NODE_HAS_PROP(0, reset_cmd)
"This tests whether the property is defined at all, not whether a boolean property is true or false. To get a boolean property’s truth value, use DT_PROP(node_id, prop) instead."
So that STM32_QSPI_RESET_CMD is always true even if the reset-cmd is not set as a property of the "st,stm32-qspi-nor" node (which is always the case with stm32 devices)

We should have instead:
#define STM32_QSPI_RESET_CMD DT_PROP(DT_DRV_INST(0), reset_cmd)

Note that DT_INST_PROP(0, reset_cmd_wait) has a default value of 10 (in µs).

[FRASTM]

I found another configuration with the stm32h750b_dk running the samples/application_development/code_relocation_nocopy/
When flashing (with STM32CubeProgrammer) the application executes correctly in external (dual-quad) flash

*** Booting Zephyr OS build v3.6.0-4153-g62e34e342b82 ***
Address of main function 0x800066d
Address of function_in_ext_flash 0x90000001
Address of var_ext_sram_data 0x240000e0 (10)
Address of function_in_sram 0x24000001
Address of var_sram_data 0x240000e4 (10)
Hello World! stm32h750b_dk

Code is correctly read at address 0x90000000

0x90000000 <function_in_ext_flash>:	0x06	0x4a	0x07	0x49	0x07	0x48	0x08	0xb5
0x90000008 <function_in_ext_flash+8>:	0x00	0xf0	0x12	0xf8	0x06	0x49	0x07	0x48
0x90000010 <function_in_ext_flash+16>:	0x0a	0x68	0xbd	0xe8

But after power off/on, the execution fails

*** Booting Zephyr OS build v3.6.0-4153-g62e34e342b82 ***                                                                                       
Address of main function 0x800066d                                                                                                              
[00:00:00.000,000] <err> os: ***** USAGE FAULT *****                                                                                            
[00:00:00.000,000] <err> os:   Attempt to execute undefined instruction                                                                         
[00:00:00.000,000] <err> os: r0/a1:  0x4800499e  r1/a2:  0x98009001  r2/a3:  0x0000000f                                                         
[00:00:00.000,000] <err> os: r3/a4:  0x00000000 r12/ip:  0x00000000 r14/lr:  0x9000000b                                                         
[00:00:00.000,000] <err> os:  xpsr:  0x61000000                                                                                                 
[00:00:00.000,000] <err> os: Faulting instruction address (r15/pc): 0x9000800a                                                                  
[00:00:00.000,000] <err> os: >>> ZEPHYR FATAL ERROR 36: Unknown error on CPU 0                                                                  
[00:00:00.000,000] <err> os: Current thread: 0x240007f0 (unknown)                                                                               
[00:00:00.058,000] <err> os: Halting system    

The Code in the external flash is not correctly read at address 0x90000000

0x90000000 <function_in_ext_flash>:	0x06	0x49	0x07	0x48	0x07	0xb5	0x08	0xf0
0x90000008 <function_in_ext_flash+8>:	0x00	0xf8	0x12	0x49	0x06	0x48	0x07	0x68
0x90000010 <function_in_ext_flash+16>:	0x0a	0xe8	0xbd	0x40

(until a connection with the STM32CubeProgrammer ( a simple connect/disconnect with external loader selcted is enough)

[Jookia]

I believe I hit this on the stm32f769 Discovery Kit. Restarting fixed it. I've found a reliable way to trigger this is to flash a new image (I'm using west flash -r openocd), hardware reset and software reset doesn't work, only re-powering.

I'm guessing what's happening here is a transaction is interrupted or something during an update and the chip doesn't reset on boot. There's no reset line for the SPI chip so it might just be getting upset.