2019-09-25 12:46 PM
My board has QSPI NOR memory (MT25QL256, 32MB) and STM32H750. I used Studio, CubeMX and CubeProgrammer to work with QSPI external memory on F746G-Disco board with no problem. But I have problem on my board with QSPI. My H750-MT25QL schm is same as in Disco board. Software is generated by CubeMX. Attached are .ioc, linker, map, start-up script error msg.
I have this attribute for the table I want to place in QSPI:
__attribute__((section(".imgqspi")))
const uint16_t image_data_Kidman120x160[19200] = {0x00, ...}
I probed MT25Q's CLK and CS pins while CubeProg was programming the board. There were no activities. It seems like H750 was not talking to MT25. I think I miss some start-up setting for the MCU.
2019-09-25 03:06 PM
QSPI is at 0x90000000 not 0x09000000
You'd need to specify a workable External Loader to manage ICs / Interface beyond the pins on the STM32
09:31:54 : Size : 1024 Bytes
09:31:54 : Address : 0x9000000 <- on the STM32 Cube Programmer side
09:31:54 : Read progress:
09:31:54 : Error: Data read failed
2019-09-27 06:35 AM
That's what I'm looking for "a workable External Loader to manage ICs / Interface." How do I create it? I've read some AN from ST about dev_inf.h and Loader_src.c, but can't follow it completely.
Below is the log from CubeProg, which has the correct address 0x90000000. The problem occurs when CubeProg gets to the external memory.
08:24:44 : ST-LINK SN : 52FF6E067266535551540867
08:24:44 : ST-LINK FW : V2J31S7
08:24:44 : Voltage : 1.80V
08:24:44 : SWD freq : 4000 KHz
08:24:44 : Connect mode: Normal
08:24:44 : Reset mode : Software reset
08:24:44 : Device ID : 0x450
08:24:45 : UPLOADING OPTION BYTES DATA ...
08:24:45 : Bank : 0x00
08:24:45 : Address : 0x5200201c
08:24:45 : Size : 308 Bytes
08:24:45 : UPLOADING ...
08:24:45 : Size : 1024 Bytes
08:24:45 : Address : 0x8000000
08:24:45 : Read progress:
08:24:45 : Data read successfully
08:24:45 : Time elapsed during the read operation is: 00:00:00.007
08:24:53 : Read File: C:\Users\...\Documents\Projects\...\...\Debug\Vue0.1.hex
08:24:53 : Number of segments: 2
08:24:53 : segment[0]: address= 0x8000000, size= 0x10848
08:24:53 : segment[1]: address= 0x90000000, size= 0x9600
08:25:07 : Memory Programming ...
08:25:07 : Opening and parsing file: Vue0.1.hex
08:25:07 : File : Vue0.1.hex
08:25:07 : Size : 106056 Bytes
08:25:07 : Address : 0x08000000
08:25:07 : Erasing memory corresponding to segment 0:
08:25:12 : Erasing memory corresponding to segment 1:
08:25:12 : Erasing external memory sector 0
08:25:17 : Error: failed to erase memory
08:25:17 : Error: failed to erase memory
2019-09-27 06:57 AM
Enumerate the specific pins and AF selection for the QSPI interface. Or attach the BSP implementation that works with your board.
First step would be to have workable QSPI access code in your own application. Build a framework capable of Erase, Write and Read functionality.
Review Keil's documentation for Flash Algorithms, the ST External Loader design is modelled on that design. Implement you own loader, perhaps build a wrapper around the Loader functionality so you can test/evaluate outside of the Cube Programmer. If you have an available USART you can use this to understand/debug the loader once it is running under Cube Programmer.
2019-09-27 07:50 AM
My code is simple and tested OK on 32F746G-Disco board: storing LCD image on QSPI, and MCU to copy to LCD. So QSPI access code is there. My QSPI accessing code is based from codes of 32F746G-Disco. If I don't store data in QSPI, my code initializes MT25QL256ABAEW9 without error.
32F746G-Disco has memory part N25Q128A which is pin compatible to the memory part MT25QL256ABAEW9 on my board, only diff capacities. CubeProg has N25Q128A part in the list of external memory devices, but not MT25QL256ABAEW9. So first step is how do I fix this? Attached are files STM32H750VB_FLASH.ld and Dev_Inf.h. What do I miss?
2019-09-27 08:36 AM
Cube Programmer only lists the devices it can find in its ExternalLoader subdirectory
I don't think the issue relates to the linker script, and the Dev_Inf simply describes the capacity and geometry of the device, the real magic is in the body of the loader itself and its initialization and use of the memory device.
This really isn't something I can explain/tutorialize in 5 mins or less. Also looks like I'm going to have to determine the exact pins myself.
2020-01-02 07:17 AM
I had this solved. See my other post "How to create CubeProg stldr loader file for QSPI external memory?"
2020-01-02 08:24 AM
The other thread to which you are referring.