Introduction

The flash driver in the SDK is supposed to work based on a configuration structure passed on the driver during the initialization time. This configuration structure has been chosen to support the configuration models of a number of flashes from multiple vendors. Currently, this configuration is generated by SysConfig from the options provided in the SysConfig Flash Module. This guide details the steps to bring up a custom flash using these tools and methods provided in the SDK. In a later version a method will be provided to do this without SysConfig as well.

The QSPI interface present in the SOC can support only the 1S-1S-1S mode or the 1S-1S-4S modes for reading from the flash.

The configuration structure can be obtained albeit automatically if the flash supports SFDP (Serial Flash Discoverable Parameter) table.

Serial Flash Discoverable Parameters (SFDP)

The Serial Flash Discoverable Parameters (SFDP) is a standard which provides a consistent method of describing the functional and feature capabilities of the flash device in a standard set of internal parameter tables. This table can be queried to identify the configurations and adjustments needed to set the flash in a desired state.

The parsing of the SFDP table is time consuming. Considering this, the SFDP parsing feature in this SDK is tied with a diagnostic example of the QSPI driver. In flashes where the SFDP is supported, this example can be used to parse the details into a config structure which can aid bringing up the custom flash. As of now the SFDP parsing in the SDK supports upto JEDS216D standard.

Summary of steps needed to enable a new flash device

Step 1: Build the qspi_flash_diag example : QSPI Flash Diag. This example communicates with the flash in 1S-1S-1S mode and queries the flash for the SFDP table (if SFDP is supported by the flash) among other things. The logs from this example would be required later to configure the flash driver.
Step 2: Open the SysConfig GUI for the example/application you want to try with your flash and enter the details manually using the flash datasheet or using the JSON from qspi_flash_diag log. Save this SysConfig configuration.

Now you can test your example/application with the new flash device! Also test the configuration with QSPI bootloader SBL QSPI and flash writer SBL UART Flash Writer by flashing an example Flash a Hello World example. Let's get into the details of the steps.

Step 1: Building the QSPI Flash Diagnostic example

Refer the example page QSPI Flash Diag on building this application.

You will need have to initialize the SOC in no boot mode as mentioned in SOC Initialization Using CCS Scripting and also load and run this example using CCS, as mentioned in CCS Launch, Load and Run.

Building and running the QSPI Flash Diagnostic example is important because regardless of flash supporting SFDP or not, the diagnostic example gives a basic sanity for the flash. If the flash diagnostic doesn't work, there could be HW connection issues most probably. When you successfully build and run the example, you should get a log with json data like this:

{
    "flashSize": 8388608,
    "flashPageSize": 256,
    "flashManfId": "0xC8",
    "flashDeviceId": "0x4017",
    "flashBlockSize": 65536,
    "flashSectorSize": 4096,
    "cmdBlockErase3B": "0xD8",
    "cmdBlockErase4B": "0x00",
    "cmdSectorErase3B": "0x20",
    "cmdSectorErase4B": "0x00",
    "protos": {
        "p111": {
            "isDtr": false,
            "cmdRd": "0x03",
            "cmdWr": "0x02",
            "modeClksCmd": 0,
            "modeClksRd": 0,
            "dummyClksCmd": 0,
            "dummyClksRd": 0,
            "enableType": "0",
            "enableSeq": "0x00",
            "dummyCfg": null,
            "protoCfg": null,
            "strDtrCfg": null
        },
        "p112": null,
        "p114": {
            "isDtr": false,
            "cmdRd": "0x6B",
            "cmdWr": "0x02",
            "modeClksCmd": 0,
            "modeClksRd": 0,
            "dummyClksCmd": 0,
            "dummyClksRd": 8,
            "enableType": "1",
            "enableSeq": "0x00",
            "dummyCfg": null,
            "protoCfg": null,
            "strDtrCfg": null
        },
        "p118": null,
        "p444s": null,
        "p444d": null,
        "p888s": null,
        "p888d": null,
        "pCustom": null
    },
    "resetType": "0x10",
    "cmdWren": "0x06",
    "cmdRdsr": "0x05",
    "srWip": 0,
    "srWel": 1,
    "cmdChipErase" : "0xC7",
    "flashDeviceBusyTimeout": 600000,
    "flashPageProgTimeout": 400
}

You will see this if your flash supports SFDP. In this case, copy this part save it as JSON file, this would be useful in Step 2. In fact, the TI Board Default Flash configuration is also saved as json.

Step 2: Configuring the flash via SysConfig

Flash SysConfig Module GUI

As you can see in the above image, there are various configurations options available for the flash.

Start with setting the Flash Device as custom flash instead of TI Board Default Flash.
Enter the name of your flash part in the next configurable and select the protocol from the next drop down. If the required protocol is not supported, there is also an option to choose the data lines for CMD, ADDR and DATA sections of the flash datagram.

Rest of the configuration depends on whether the flash supports SFDP or not.

Case 1: Flash Supports SFDP

If your flash supports SFDP and the qspi_flash_diag example is able to print out the SFDP table as shown in Step 1, configuring the flash in your example via SysConfig is quite easy.

Flash Auto Config

To use the JSON file, scroll down to the section which says "Automatically Configure Flash". Now click on the LOAD FROM JSON button which will open a file dialog.
Browse to the JSON file saved in Step 1 and select it. SysConfig should "load" data from the file into the GUI.
You can cross verify the values with datasheet if required, but mostly this won't be necessary.

Case 2: Flash Doesn't Support SFDP

If your flash doesn't support SFDP, the flash configuration details would need to be filled in manually. This can be a pain point, but mostly flashes without SFDP support wouldn't have a lot of configuration as well. Only basic things like quad bit enable, etc would need to be looked up in the datasheet.

Most of the configurables should be self explanatory. Still if some terms seem confusing, look for a question mark icon near the configurable when you hover. Clicking on that should give the long description regarding a certain configurable.

Long Description For Quad Enable Type

Case 3 (Rare Scenario): Flash Supports SFDP, but Protocol Configuration is Custom

We have tried to keep an interface as generic as possible. But because of the variety of flash vendors and configurations, sometimes setting a protocol might differ from the sequences listed in SysConfig interface. Sometimes there might be extra steps required during the initialization for the flash to function correctly. To tackle this issue, we have given the option of two hooks:

Custom Protocol Function
Quirks Function

The custom protocol hook will be invoked in the middle of the Flash_open function and the quirks function will be invoked at the end of the Flash_open function.

You would find these options in the SysConfig GUI for flash under the protocol configuration after you've selected your protocol as __"Custom Protocol"__. The quirks function is always present as the last configurable.

Custom Protocol and Quirks Function Hooks

You should leave these as NULL if your flash doesn't need this.

Obtaining flash details from the SFDP table OR datasheet

This section can be ignored if the flash supports SFDP.

All the details regarding the flash including fast read opcodes, supported erase sizes, dummy clocks needed for each instruction and flash configuration registers information will be available from the flash data sheet.

Flash size, page size and block size can be obtained from the introduction/overview section of the datasheet.
The read, write, register read, register write, read ID and other opcodes can be obtained from "Transaction tables". There will be transaction tables for each protocol (For example 1S-1S-1S transaction table, 1S-1S-4S transaction table)
The number of dummy cycles required for the read opcodes will also be available from the transaction table.
3 byte addressing can work if you are accessing upto the 16 MB. If the flash size is more than that 4 byte addressing mode should be used
Check the datasheet to see if 4 byte addressing mode is supported. There are multiple ways flash devices support 4 byte addressing mode. In most cases, the flash will have separate set of opcodes for 4 byte addressing mode. Sometimes there will be a configuration register which can be set so that flash switches to 4 byte addressing mode.
QE bit setting is one of the most important settings in 1-1-4 protocol. Usually it is part of the SR2 and is non-volatilewritable. But this can change, and as of JEDS216D there are 7 different types of Quad Enables possible!

Miscellaneous Debugging Tips and Tricks

Sometimes if there is a data mismatch or data showing up with one-off bytes (usually in high speed octal transactions), it is advisable to check the dummy cycles, if the controller and flash are in agreement with the same. In 1-1-4 or QSPI protocol, 8 dummy cycles for read is a given, but cross check with the datasheet and provide correct value in the flash sysconfig.

Table of Contents