Hello Quectel Support Team,
We are using the EC200UCNAC module with an external NOR flash connected on the QSPI pins
(PCM_CLK, PCM_SYNC, PCM_DIN, PCM_DOUT, USIM_DET, WLAN_WAKE )
Is application-level READ (or READ/WRITE) access to external NOR on QSPI supported on EC200?
Our requirement is to store application data in external NOR and potentially read JEDEC ID / status.
Dear @Roopa ,
Thank you for reaching out.
On EC200U series, application-level storage on external NOR (QSPI) is generally supported via the external flash file system (path prefix EFS:), so you can do read/write at file level using standard file AT commands (e.g., AT+QFLDS=“EFS”, AT+QFOPEN/QFREAD/QFWRITE, etc.) as long as your firmware/project includes EFS support and the external flash is properly integrated/enabled.
However, raw QSPI/NOR access such as reading JEDEC ID or status registers is not covered by the EFS/file AT command set (those commands operate on files, not low-level flash registers). If you specifically need JEDEC ID / status, it typically requires a dedicated driver/API (QuecOpen side) or R&D confirmation of any low-level interface support.
To confirm precisely for your setup, please share:
Your firmware version and whether you are using standard AT firmware (AT+QGMR)
Best Regards,
Aghelan
Thanks for replying.
Can I use ql_spi_init_ext() to configure for QSPI and use ql_spi_write(), ql_spi_read_follow_write API’s for 6 wire SPI ?
Dear Roopa,
Thank you for the clarification.
In general, ql_spi_init_ext(), ql_spi_write(), and ql_spi_read_follow_write() are generic SPI master APIs intended for standard SPI transfers (CLK/CS/MOSI/MISO). They are typically suitable when you want to communicate with an SPI peripheral using normal read/write sequences.
For external NOR connected in QSPI / multi-I/O mode (e.g., Quad I/O where data lines are expanded beyond MOSI/MISO), these generic SPI APIs may not be sufficient to operate the NOR in true QSPI mode (for example, performing Quad Read/Write sequences, handling QSPI command formats, or reading JEDEC ID/status through a QSPI-specific controller/driver flow). In such cases, QSPI NOR access usually requires a dedicated QSPI/NOR driver layer or an officially supported interface in the QuecOpen SDK/firmware.
To confirm the correct and supported approach for your EC200UCNAC setup (and avoid recommending an API flow that may not work on your project/firmware), could you please share:
Your EC200UCNAC firmware / QuecOpen SDK version
The external NOR flash part number
What you mean by “6-wire SPI” (QSPI with multiple data lines vs. SPI with WP/HOLD pins)
Once we have this, we can confirm whether the platform supports QSPI NOR access through an existing driver/API, or whether access is limited to file-system level storage (EFS) only.
Best Regards,
Aghelan
Dear @aghelan_loga
Thank you for your response.
The SDK version I am using is LTE01R03A08_C_SDK_U
I have attached my NOR chip
6-wire SPI is QSPI with multiple data lines
Dear Roopa,
Thank you for sharing the details.
Regarding your question: ql_spi_init_ext() + ql_spi_write() / ql_spi_read_follow_write() are generic SPI master APIs intended for standard SPI transfers, and they are not the recommended interface for 6-wire/QSPI multi-IO NOR operation.
For 6-wire/QSPI external NOR on EC200U, QuecOpen provides a dedicated 6-wire SPI NOR flash file system mounting driver/API, and the supported flow is:
ql_spi6_ext_nor_flash_init() (initialize/configure 6-wire SPI)
ql_spi6_ext_nor_flash_sffs_mkfs() (format to SFFS, if needed)
ql_spi6_ext_nor_flash_sffs_mount() (after a successful mount, file system APIs can be used for read/write)
After mounting, please access the external NOR using the file system APIs on the EFS partition (the File System guide defines EFS as the “External 6-wire SPI NOR Flash partition”, and paths follow disk:/path/file, e.g. EFS:/mydir/data.bin).
About JEDEC ID / status: the flash type configuration relies on the flash property table (e.g., hal_spi_flash_prop.csv), and the MID (JEDEC ID) is read using the 9Fh command and matched against the table. If the MID/flash model is not present, it needs to be added/updated in the table.
Also, not all flash types shown are debugged, so if you need confirmation for a specific flash model, please let us know and we can verify the supported/debugged list.
If your primary requirement is storing application data, the above SFFS/EFS method is the supported and most stable solution.
Best Regards,
Aghelan
