Arm Mbed OS support forum

QSPI and USBMSD support for STM32L433CC with MX25R6435F

I have been using the NUCLEO-L433RC-P target for some time now. Recently I have been trying to get an external QSPI Flash to work (Macronix MX25R6435F). Knowing the Nucleo does not natively support an external flash, I modified file mbed_app.json to add following definitions :

"NUCLEO_L433RC_P": {
            "target.components_add": [
            "target.device_has_add": [
            "drivers.qspi_csn": "PB_11",
            "drivers.qspi_sck": "PB_10",
            "drivers.qspi_io0": "PB_1",
            "drivers.qspi_io1": "PB_0",
            "drivers.qspi_io2": "PA_7",
            "drivers.qspi_io3": "PA_6",
            "platform.stdio-baud-rate": 115200

I followed the same modifications as in this post : STM32H743ZI2 QSPI Support.
Now my Nucleo can “kind of” see the QSPI. Using QSPIFBlockDevice and USBMSD, my goal is to communicate with the flash chip from Windows to write “any” file to it. For this, I am using following code:

#include "mbed.h"
#include <stdio.h>
#include <errno.h>
#include <functional>

#include "BlockDevice.h"
#include "USBMSD.h"

#include "QSPIFBlockDevice.h"
QSPIFBlockDevice* bd = new QSPIFBlockDevice;

#include "FATFileSystem.h"
FATFileSystem fs( "fs" );

int main( void )
   printf( "mounting\r\n" );
   int err = fs.mount( bd );

   printf( "error: %d\r\n", err );
   if ( err != 0 )
      printf( "formatting\r\n" );
      err = fs.reformat( bd );

   printf( "Connecting USB\r\n" );
   USBMSD usb( bd, false );
   while ( true )

   // printf( "end\r\n" );

This code is heavily inspired from mbed examples. Do note that this exact code, but using an SDBlockDevice instead of a QSPIFBlockDevice (with SD card on the SPI port, not the QSPI port, and further adjustments to mbed_app.json), works perfectly.

What I am seeing is that whenever I plug my prototype to my PC, the board takes a long time to appear as USB Mass Storage Device. After that, I can write and read files from the Flash chip via Windows. Once I unplug my board though, and replug it, all data is deleted, which suggests that the code above enters the first if-statement, thus that the return value from fs.mount( bd ); is not 0. Indeed, it is -22, which suggests absence of a file system on the Flash… even though there was one a few seconds ago. After that, the Flash is formatted again and all data is lost, which is unacceptable in my use case.

My questions are as follow:

  • can anyone confirm I have done all the necessary modifications to Mbed OS to have the QSPI reliably working ?
  • what am I doing wrong in my implementation of the FAT file system, that it seems to vanish between power cycles / reset cycles (basically as soon as the USB mass storage device disappears from windows) ?

Any help is welcome ! Thanks in advance !


i wonder, have you managed to get USBMSD working with QSPIBlockDevice?

I currently have similar issues getting both work together.

USB device shows up in my explorer on my pc, but the USBMSD driver will not get initialized properly: I can’t even see the files, just the device and Windows asks me to format which, however, will not work.


I had completely forgotten about this post… Unfortunately I never got it to work and had to move on to other parts of the project.

What I do remember though is that the part about using an SDBlockDevice instead of QSPIF worked quite as described ; using a RAM-stored, temporary file system had the same behaviour. The USBMSD board appeared quickly on my PC and I was able to copy and retrieve files as long as the board was powered on.

At the time I believe I was using mbed-os-6.7.0 ; maybe later versions have corrected that ?


thanks for your prompt reply.

Currently I’m using a FlashBlockDevice and it works as intended. Just wanted to switch over to QSPI to have more storage at hand (for whatever reason the STM32 series only has up to 1024Kb/2048Kb of internal ROM).

Maybe I thought I should try some other vendor’s QSPI flash? Or I’m moving on with SD cards, however, tried to avoid them, QSPI seems so much more handy (higher speeds, less costs for small storage).

I’m trying to avoid switching versions as our internal MBED version has so many bug fixes/modifications already applied which are not available with the newest version.

I was using a Macronix bit (the exact reference is slipping from me), the one Nordic uses on their nRF52840 Dev Kit. That one was supported “out of the box” by mbedOS which would at least allow to skip the configuration steps.

Maybe you should try opening a new thread, that would get pushed up on the forum’s landing page.

Sorry I couldn’t help, and good luck.

Idea is to upload patches. Then you could easily take the newest version…

For MX25R6435F, default configuration is changing QSPI_FREQ:

You could then try to add in your mbed_app.json:
“extra_labels_add”: [

Hi Jerome,

I already tried to report bugs but it takes long until fixed.

Currently I’m trying to get directly involved in the process as I thing mbed is the only embedded os that has a proper C++ interfaces which I consider very important for modern MCU programming. On the other hand there are libs that needed a complete overhaul, e.g. the cellular part. How can I propose major changes in functionality in mbed without compromising the “old” stuff?

on topic: Maybe I can get SPIFlashDevice working with my flash. I’m using the GigaDevice GD25LQ128D. I will also try out the new Macronix flash line and the mentioned MX25R6435F. I let you know my results.

Another thing: The QSPI driver only recognizes 16Mb (one sector) out of the 128Mb. Why does it not detect all sectors?