SPI Flash Programming – Getting Started with VTOS Program SPI
A guide for programming SPI or Quad SPI flash devices using Kozio’s VTOS program.
Serial Peripheral Interface (SPI) Introduction
SPI has won a significant role in embedded systems because of board real estate savings over a parallel I/O bus. Most embedded processors now include a SPI controller. The Serial Peripheral Interface (SPI) is also referred to as the Synchronous Serial Interface (SSI).
The SPI interface is used for in-system programming of Flash or EEPROM devices. The SPI interface is also used to communicate with a variety of SPI peripherals: sensors, audio codecs, DACs, camera lenses, real-time clocks, LCDs, MMCs, SD cards, Ethernet, USB, and CAN. If you renamed the JTAG signals, it is essentially a 3-wire SPI variant.
There is not an official protocol standard for the SPI bus, so there is a wide variety of protocols used. Every device defines its own protocol – such as the bit ordering and variances in flow control. These variations often require software changes to adhere to the various SPI peripherals being used in a circuit board design. VTOS provides a flexible API and command set supporting any protocol without software changes.
SPI Flash Programming
The four steps required to program SPI/QSPI flash devices using VTOS Program are:
Load VTOS Program firmware onto your target device and establish a connection.
Import a pin mux configuration – required for ARM processor designs.
Configure a SPI or QSPI Flash Device and enter protocol parameters.
Add program options: erase, blank check, program, verify.
Load VTOS Firmware
The Kozio solution relies on firmware running on your target device for fast flash programming. The first step is to load the appropriate VTOS firmware onto your circuit board design. The two most common options for loading firmware are to use a supported JTAG interface, such as NXP’s CodeWarrior TAP, or use the built in capabilities of the processor itself. Many modern processors provide firmware built into the processor that allows you to load images into on-chip memory using USB, Serial, or an SD Card interface. The details of loading firmware are covered in other postings.
The second action is to establish a connection from your PC to your target device. The two supported are options are JTAG and Serial (also referred to as a UART connection). Use the VTOS Program GUI to configure a connection and then to connect. This interface will be used to communicate with VTOS firmware, send commands, and receive responses. This interface may also be used for in-band file transfers but VTO Program also supports file transfers other other interfaces like Ethernet for even faster flash programming.
Import a Pin Mux Configuration
ARM based designs require a pin mux file. There are two options, browse to a Kozio Script file that has pin configuration data, or import a pin mux file from a third-party tool.
On the Zynq-7000, peripherals within the PS (processor subsystem) must be connected to multiplexed I/O pins (PS_MIOxx) for proper operation. Each PS_MIO signal is configured by writing to memory mapped registers of the Zynq-7000. The number of signals that must be configured, varies based on the peripheral interface used. For example, QSPI requires 6 signals; 1 clock, 1 chip select, and 4 data signals.
When using a Xilinx processor, the user can use Vivado pin mux files created for their project and import that pin mux file. The Vivado Design Suite produces a C source file called “ps7_init.c”. This file is meant to compiled into the boot loader on the user board and performs initialization of the Zynq 7000 PLLs, MIO pins, and the DDR memory interface. When the ps7_init.c file is created, it can optionally include data for multiple silicon revisions. The Kozio VTOS Program import feature reads the pin mux data and converts to a format that VTOS uses. Vivado generates multiple sections for each version, so the import step actually creates three separate pin mux files in Kozio’s format. The process will generate three output files. As a default, we pre-fill in the last version, which is the version we want.
For NXP processor designs, the user can use the NXP tools provided, such as the i.MX Pin Tools. For TI processor designs, the user can use their Pin Mux Utility. The user will use these tools and then export the pin mux configuration date. The user can then use the VTOS Program GUI, or VTOS Developer GUI, to import that file and convert it to a Kozio accepted format.
After the import is complete, we run the pin mux file in the VTOS Developer GUI. To use the new pin mux file, launch the VTOS Developer GUI. In your configuration tree, select the Pin Configuration node and use the right-mouse Run option, or double-click on the Pin Configuration mode. This step will communicate with the VTOS firmware and configure the processor using your pin mapping.
Now we can talk to the SPI and QSPI devices.
Configure SPI/QSPI Flash Device
The next step is to add a flash device to your configuration. This step is accomplished by selecting the <Add Device> node in the configuration tree of the VTOS Developer GUI and then using the right-mouse menu option to add a Serial NOR Flash Device. Where the device is added depends on your processor and circuit board design. You will be adding the new device under the SPI Group, and then the specific SPI channel or QSPI channel, such as SPI0, SPI1, or QSPI.
Now click on the new SPI Flash device node in the configuration tree and use the Config Mode tab to enter parameters based on your flash device datasheet and processor design. The table below provides details on each parameter.
|Name||SPI Flash 3:1||This parameter sets a user defined name for the programmable flash device. This name is used during erase, program, and verify operations. When using the VTOS Developer GUI, this field is populated with the names the user entered for the SPI Flash Device. This field is auto-populated by the GUI with a default name, but the user can adjust to be more specific to their design.|
|Chip Select||0||This value varies per board design and is based on your schematics. For some processors, such as the Zynq-7000, there is only a single chip select available on the QSPI interface – which is zero (0).|
|GPIO Channel||-1||This parameter is needed for legacy SPI interfaces. It can be used for a corner-case where the designer decided to use a GPIO pin for pin select instead of the built in chip select feature. This is not typical. The default value of -1 is used to indicate that this parameter is not used.|
|GPIO Pin||-1||This parameter is needed for legacy SPI interfaces, and is not needed for the QSPI interface. See GPIO Channel comments above.|
|Maximum Clock Rate||See datasheet||Set to the maximum operating frequency, in hertz, of the SPI/QSPI device during page-program operations.|
|Maximum Clock Rate Reads||See datasheet||Set to the maximum operation frequency, in hertz, of the SPI/QSPI device during single-lane read operations. Typically this is 50 MHz and will be a slower clock speed than the page-program clock speed.|
|Total Size||See datasheet||Set to the total size of the SPI/QSPI device, in bytes.|
|Erase Sector Size||See datasheet||Set to the erase sector size of the SPI/QSPI device, in bytes.|
|Address Bytes||0||This parameter is obsolete and not longer used.|
|Write Buffer Size||See datasheet||Set to the size of the write buffer of the SPI/QSPI device, in bytes. For QSPI devices, 256 and 512 byte buffers are common.|
|Program Timeout||See datasheet||Set to the maximum page-program timeout, in milliseconds. Typical page-program timeouts are 5-10 milliseconds.|
|Erase Timeout||See datasheet||Set to the maximum sector erase timeout, in milliseconds. Typical sector erase timeouts are 3-5 seconds (3000-5000 milliseconds).|
Configure Program Operations
The next step is to add operations to erase, program and verify flash programming. The table below provides a summary of each operation that can be added to your configuration.
The process is to add multiple operations for each file being programmed. For each file that you want to program, you should add an erase operation, followed by an optional blank check operation. Then add a Program From File or Program From Device, depending on where your source data resides – on another device on your target or a file on your PC. The last step is to add a Image Checksum Test to verify that the data you programmed was programmed successfully. Kozio provides an MD5 checksum tool that you can run on your PC, or during test development, you can simply run this command with a default setting and let VTOS tell you the expected checksum value.
We also provide operations to lock and unlock flash sections. These are optional but may be required for your circuit board design. In addition, the Read To File is provided as a debug step to read the target data and store the contents in a file on your PC.
For each operation added, you will select the Device Name for the device you want to operate on. This selection is a pull-down of options based on the names you entered for each added device. The Offset value defines an offset into the flash device. VTOS defines it own memory map, so you will not be using a physical device address, just an offset starting at byte 0 and on.
Also provided for some operation is a Source Offset, which allows you to skip over specified number of bytes in the source data. This may be useful when you want to strip off a header on a binary file and only program the bytes after the header.
|Image Erase Test||Erase an extent in a device. VTOS automatically rounds up the length to the erase sector size.|
|Image Blank Test||Verify an extent of a device is erased. VTOS automatically checks for all 0’s or all 1’s in the read data based on the device type.|
|Program From Device||Copy data from one extent of a device to separate extent of a device. Can also be used to copy data between two different devices (e.g. copy from SD Card to eMMC, or SDCard to QSPI).|
|Program From File||Opens a file on the host PC, transfers the file to the target over the in-band communication channel (JTAG chain or Serial) and programs the device.|
|Read To File||Reads data from the device on the target and transfers the data to the host PC over the in-band communication channel. The data read is written to a file on the host PC.|
|Image Checksum Test||Reads data from a device on the target, calculates an MD5 checksum over the data and compares against an expected MD5 result.|
|Program From File Using TFTP||Transfers a file to the target device over an Ethernet connection and programs the SPI/QSPI device. Kozio provides a TFTP Server that can be started or stopped from the VTOS Developer GUI.|
|Image Lock Test||Locks an extent of a device on the target, preventing programming and erase operations.|
|Image Unlock Test||Unlock an extent of a device on the target, permitting programming and erase operations.|
Automating Flash Programming
Now that your configuration is all set up, there are a few ways to automate these steps.
- Click on the Run button on the main menu bar. This operation will run all steps configured from top to bottom. With the push a single button you can erase, program, and verify your flash memory operations.
- Click on File -> Export -> Kozio Script File to create a single script file containing all these steps. That script file can be loaded and run in Kozio’s VTOS Runner GUI.
- Click on File -> Export -> NI TestStand Sequence to create a single TestStand sequence file (*.seq) containing all these steps. That binary file can be loaded and run in NI’s TestStand GUI without modification.
- Click on File -> Export -> Desktop Shortcut to create a desktop button. That single button is linked to a batch file that will load and run the Kozio script file exported. Double-click on the button to connect to your target, load firmware, and program flash memory all in a single operation. This can be very handy for programming multiple boards.