How to run my programs in QSPI FLASH?

[noob]

Hello�?

Recently, I was planning to use NUCLEO-L432 to create a smartwatch, but I encountered a fatal problem: running a program using external FLASH can cause the program to freeze.

Because I wanted to use LVGL as a graphical interactive interface, the 256K FLASH of L432KCU6 was not enough. Therefore, I used only burning bootloader on the chip and running the program saved in W25Q128 through QSPI. Due to limited funds, I have adopted the FLASH module, which has led to many strange problems (possibly due to non PCB wiring).

When I set the main frequency to 80MHZ (maximum), the program can only run for 16 minutes and will freeze; It can run for 40 minutes at 70MHZ; It can run for 60 minutes at 60 MHz, and the time of each stuck is the same. And since I divided the project into bootloader and app, I don't know how to debug my app program, so I don't know exactly where it got stuck.

I have no idea about this issue at the moment. May I ask if there is anyone who can provide some suggestions.

Thank you.

[KDJEM.1 · Accepted solution]

Hello @煜 张​ and welcome to the community  ,

Please note that the QUADSPI controller which connects the W25Q128 is limited to 60MHz in SDR, 48MHz in DDR mode as shown in the below figures (DS11451).

 

When your question is answered, please close this topic by choosing Select as Best. This will help other users find that answer faster.

Thank you

Kaouthar

[_EFrie]

This will never work on a breadboard. QSPI is a high integrity required signal, you are probably on the edge, and all it takes is a little bounce, and boom, the MCU brains got scrambled.

[_EFrie]

Or I could add, won't work as shown. Maybe if you lower to 5mhz and put resistors in the right place it could help, but as a whole QSPI signals have to be watched carefully.

[noob]

Thanks for your reply.

The Breadboard is really inferior to the PCB board. I was unable to read FLASH with 4-wire jumper connection at that time. It was not improved until I replaced the jumper with a better copper wire and switched the internal high-speed clock to the external high-speed clock:grinning_face:

[noob]

I am using the ST official development board, and there should be no hardware issues. I have now lowered the global clock to 48MHz and have been running for an hour without any issues. I am planning to run it all night. Although it can be used, I am still worried if 48MHZ will be too slow.:face_screaming_in_fear:

[noob]

Thank you for your reply!

In fact, I never knew there were any requirements as shown in the picture. Thank you for telling me, otherwise I would have abandoned this project.

I am using a 3.3V power supply, and I am not sure what the C Load and Voltage Range in the picture are. However, to ensure normal use, I have set the global clock to 48MHz (now I am worried if it may be too slow or if there is any solution to speed up the operation). There should be no problem now, so I plan to run all night to see.

Anyway, thank you again for your reply. Thank you!:thumbs_up:

[Tesla DeLorean]

I'm surprised there are the pins to make this work on the QFN32..

Get the QSPI working/functional.

Memory Map the QSPI into the STM32's address space using commands you've just validated.

Branch or do control transfer into the code space for the QSPI (0x90000000)

There should be XIP and QSPI examples in CubeL4 trees, perhaps not for NUCLEO, but perhaps for EVAL or DISCO boards, which you can port.

[noob]

Thank you for your reply!

Yes, it is reasonable to use chips with around 144 pins to achieve better results.

In fact, I encountered many problems in order to store and run code on external flash on L432, but ultimately resolved them. The biggest problem is that I am not familiar with QSPI, which leads to a considerable amount of time spent reading data on the fourth line. Secondly, there is no ready-made bootloader program. I wrote a simple download program using QT and distributed the program through a serial port. Although the process was bumpy, I still achieved my goal in the end, and I have a great sense of achievement (laughter)!

The next challenge is how to adapt to writing lvgl code without debugging!