AM263x MCU+ SDK  08.02.00
Writing flash driver for a custom flash device

Table of Contents

Introduction

The flash driver provided in the SDK package can communicate with the flashes as listed in Flash.

If a different external flash is being used, the flash driver will need certain modifications and configuration changes to work properly. This guide will help in the process of developing/modifying the flash driver to suit the custom external flash being used.

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.

Summary of steps needed to enable a new flash device

  • Step 1: Create a new driver in the SDK to support the new flash device.
  • Step 2: Obtain flash details from the datasheet of the flash device and map it to the settings in flash driver.
  • Step 3: Test the new flash driver with the changes using qspi_flash_transfer example : QSPI Flash Transfer
  • Step 4: Test the flash driver with QSPI bootloader SBL QSPI and flash writer SBL UART Uniflash by flashing an example Flash a Hello World example

Step 1: Creating a new flash driver

Flash driver structure in the SDK

The flash driver in the SDK composes of two layers :

  • Generic flash layer, which will then call the actual flash driver APIs using registered function pointers
  • Flash device specific layer which will communicate with the flash using the underlying NOR SPI controller APIs

The application should only use the APIs from the generic flash layer, this makes sure that there is no dependency on a particular flash type. This layer mostly needs no modifications to support a new flash. The generic flash driver has 5 major functions which will internally just call registered callbacks specific to the device. They are :

Out of these, the Flash_open is the most important one. That is where the flash would be configured to work in a specific mode and also set the NOR SPI controller to talk to the flash. The callbacks to these will be implemented in the device specific layer.

Adding new files to device specific layer

There are 3 files needed per flash in the device specific layer as per the current driver structure :

  • flash_nor_qspi.c
  • flash_nor_qspi.h
  • flash_nor_qspi_device_<flash-part-number>.c

These files need to be located in the ${SDK_ROOT_DIRECTORY}/source/board/flash folder. For example we have flash_nor_qspi.c, flash_nor_qspi.h and flash_nor_qspi_device_MX25V1635F.c files for the MX25V1635F device. These can be edited to support the new flash device. The implementation of the 5 callbacks mentioned in the above section can be found in flash_nor_qspi.c. A new device data file (similar to flash_nor_qspi_device_MX25V1635F.c) needs to created with the appropriate flash part number. Copy from the existing file and change just the flash part numbers for now. Other details can be updated in a while.

To enable build support for this file, add it to the makefile ${SDK_ROOT_DIRECTORY}/source/board/makefile.{soc}.{core}.ti-arm-clang under FILES_common.

The flash sysconfig also should be updated so that later in examples the flash can be selected appropriately. For this open the /source/board/.meta/flash/flash_{soc}.syscfg.js file. The object flash_devices will have a number of entries corresponding to the currently supported flashes. Add a new entry corresponding the new flash.

  • For name, give the flash part number in ALL CAPS. Note, this has to match with the part number given in flash_nor_qspi_device_<flash_part_number>.c filename
  • For type, use "NOR QSPI". When sysconfig registers the callbacks, it is going to look for gFlashNorQspiFxns
  • For size, give the flash size in bytes

Confirm that the files build and the new flash device is selectable in sysconfig. We can now update the files according to the new flash device.

Step 3: Obtaining flash details from the datasheet

Flash configuration information

In order to program the flash device and NOR SPI controller these are the bare minimum data required from the flash :

  • Flash size in bytes
  • Block size in bytes
  • Page size in bytes
  • Addressing mode support (3 byte or 4 byte)
  • Support of a quad mode protocol (1-1-4)
  • If supported how to enable the flash to work with quad mode
  • Dummy cycles required for a Quad mode
  • Erase and page program timeouts

Using the flash 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.
  • These opcodes and register address values can then be updated in the flash_nor_qspi_device_<flash_part_number>.c file. Make necessary changes in the Flash_norQspiOpen function to set the 4 byte addressing mode correctly. If it is a case of separate opcodes, you only need to set this for the NOR SPI controller. If it needs a register write to one of the flash config registers, then that needs to be done.
  • Check the datasheet to see how to enable the quad read. This is implemented for the MX25V1635F/S25FL128SA flash in the flash_nor_qspi.c file, Flash_norQspiQuadReadEnableEnable function. For this flash QE is bit 1 of the status register 2. Status register 1 is read using Read Status instruction 0x05. Status register 2 is read using instruction 0x35. QE is set via Write Status instruction 01h with two data bytes where bit 1 of the second byte is one. Update the implementation of this function as specified in the datasheet.

Step 3: Test the new flash driver with the changes using QSPI Flash transfer example

  • Update the example.syscfg of the qspi_flash_transfer example QSPI Flash Transfer using SysConfig GUI to select the new flash device you have added.
  • Build and run the example

Step 4: Test the flash driver with QSPI bootloader and flash writer

  • Similar to the qspi_flash_transfer example, update the example.syscfg for QSPI bootloader (sbl_qspi) SBL QSPI and flash writer (sbl_uart_uniflash) SBL UART Uniflash
  • Build the flash writer and the QSPI bootloader.
  • Try to flash an application and boot it using the QSPI bootloader. Follow the steps mentioned in Flash a Hello World example