This is a diagnostic example for NOR-QSPI Flashes. This example doesn't use the flash driver and should ideally pass for any NOR-QSPI flash. For this particular example, the options in SysCfg like the number of transfer lines used, or the clock divider value are ignored. This example will always talk to the flash in the lowest settings possible. The flash device is reset, and is expected to support 1s1s1s mode after reset. Then the QSPI controller is programmed to work in 1s1s1s mode with 3 byte addressing mode.
The test itself is simple, first it tries to read the JEDEC ID of the flash which consists of the flash manufacturer ID and the flash device ID. These are then printed onto the logging console. When doing flash bring-ups in new boards, this example can be run first for sanity. Users can cross check the printed ID with the one in flash datasheet to confirm that basic communication with flash is working.
The test then tries to erase a flash memory block at an offset of 64 KB and then write some known data to that memory. This data is then read back and verified to confirm that reads and writes are working in 1s1s1s mode.
Parameter | Value |
---|---|
CPU + OS | m4fss0-0 freertos |
m4fss0-0 nortos | |
Toolchain | ti-arm-clang |
Boards | xWRL6432-evm |
Example folder | examples/drivers/qspi/qspi_flash_diag |
A GUI tool SysConfig is used to configure different modules and peripherals of the example. Using this tool, users can select and customize different modules and peripherals. The SysConfig tool will generate the code for initializing and configuring these modules. This configuration is saved to a file called example.syscfg for every example. To know more about how to use SDK with SysConfig, Visit this page
Shown below is a sample output when the application is run,