ANALOG DEVICES EE-304 Service Manual

Engineer-to-Engineer Note EE-304

r

a

Technical notes on using Analog Devices DSPs, processors and development tools

Visit our Web resources http://www.analog.com/ee-notes and http://www.analog.com/processors o
e-mail [e-mail] or [e-mail] for technical support.

Using the Blackfin® Processor SPORT to Emulate a SPI Interface

Contributed by J.Galindo and Joe B. Rev 1 – November 10, 2006

Introduction

The Blackfin® family of embedded processors
supports numerous methods of booting
application code, including serial booting from
an SPI flash memory device. The Blackfin SPI
interface is limited to a maximum clock rate of
one-quarter the system clock (SCLK) rate. If the

SCLK is maximized to 133 MHz, this translates to

an SPI performance limitation of ~33 MHz.
However, there are serial flash devices capable
of speeds higher than this, and it is possible to
achieve serial clock speeds of up to ~66 MHz if
one of the Blackfin serial ports (SPORTs) is used
instead, as the maximum SPORT clock
frequency is SCLK/2.

Emulating the SPI Boot Process

If the intent is to boot from an SPI device whose
operating frequency exceeds the maximum
Blackfin SPI frequency of SCLK/4, the SPORT
interface may be an attractive alternative, as it
can run twice as fast as the SPI. However, since
SPORT booting is not supported by the Blackfin
processor boot ROM, the SPORT must be
configured/connected such that it can
successfully communicate with the SPI device
and have the ability to execute the boot process
normally automated by the boot ROM for the
SPI interface. This requires specific use of
hardware and configuration software, as well as
modification to the boot process itself.

This EE-Note describes how to use the Blackfin
SPORT to emulate an SPI interface and how to
then use that emulated hardware to boot an
application from an SPI memory device using the
SPI boot mode of the Blackfin processor. To
make the process work, one must first understand
the boot process of Blackfin processors and have
a fundamental understanding of the boot image

.ldr file) expected by the Blackfin boot ROM.

(
These concepts are discussed in ADSP-BF533

Blackfin Booting Process (EE-240)

[1]

.

This application was tested using the
VisualDSP++ 4.5® development tools and the
ADSP-BF537 EZ-KIT Lite® evaluation system,
but the concepts discussed apply to all members
of the Blackfin processor family.

Copyright 2006, Analog Devices, Inc. All rights reserved. Analog Devices assumes no responsibility for customer product design or the use or application of
customers’ products or for any infringements of patents or rights of others which may result from Analog Devices assistance. All trademarks and logos are property
of their respective holders. Information furnished by Analog Devices applications and development tools engineers is believed to be accurate and reliable, however
no responsibility is assumed by Analog Devices regarding technical accuracy and topicality of the content provided in Analog Devices Engineer-to-Engineer Notes.

Configuring/Connecting the Hardware

The master SPI boot mode is used for this
application. The master mode SPI interface
requires four signals: data in (

MISO), data out

(MOSI), clock (SCK), and chip-select (/SPISS).
Three of these four signals have evident
correlation to SPORT pins:

 MOSI is the transmit data (DTxPRI)
 MISO is the receive data (DRxPRI)
 SCK is the clock (TSCLKx/RSCLKx)

The Blackfin SPORTs support both primary and
secondary transmit/receive data channels. The
primary pins (denoted by the PRI suffix) are
utilized when no secondary channel is required.

a

The Blackfin SPORTs also support dedicated
clock sources for both the transmitter and
receiver. In this application, the SPORT’s
transmit and receive logic are interfaced to the
same SPI memory device; therefore, the
transmitter and receiver clocks are shared, and
are thus connected together externally.

The pin in the SPI interface that has no
equivalent pin on the SPORT is the chip-select
signal, /SPISS. The /SPISS is the gating factor
for the SCK. As a slave SPI device, action is only
taken on SCK edges detected while the /SPISS
signal is being held active low by the bus master.
Most master SPI devices supply the SCK signal
only when they are placing data on the MOSI line,
but extraneous SCK transitions are ignored if the

/SPISS signal is transitioned to inactive high

before the extra SCK pulses are active. This built­in behavior is helpful because the SPORT
employs a continuous clock once the hardware
has been enabled and communications have
begun. The challenge is to make the SPORT
hardware handle the appropriate timing and
control of the /SPISS signal. To address this
need, the frame sync signals in the SPORT
interface are used. Figure 1 depicts how the
SPORT and SPI pins of the Blackfin processor
should be connected to each other and to the SPI
memory device.

If the SPORT is configured to generate an active
low, late frame sync (as is required for every
word transmitted), the behavior of the transmit
frame sync pin (TFSx) is comparable to the

/SPISS signal. For internally generated, active

low, late framing, the

TFS signal is asserted low

in the same SPORT clock cycle as data is placed

DTxPRI, and the signal is held low for the

on
duration of the word being transmitted.

TFSx is

then de-asserted unless new data is ready to be
transmitted, in which case it is held in the active
low state. This is precisely the way the /SPISS
signal would be managed by an SPI master
device. The following assembly source code can
be used to configure the SPORT:

P1.H = HI(SPORT1_TCR1);

P1.L = LO(SPORT1_TCR1);

R3.L =
TCKFE|LATFS|LTFS|TFSR|ITFS|ITCLK;

W[P1] = R3;

The equivalent C code would be:

*pSPORT1_TCR1 =
TCKFE|LATFS|LTFS|TFSR|ITFS|ITCLK;

Booting Via the SPORT Interface

As stated previously, there is no native support
built into the boot ROM for booting over the
SPORT. Achieving this functionality requires the
boot sequence to begin booting over SPI, as
configured by the

BMODE pins, and then transfer

control to the SPORT to continue the boot
process over the faster SPORT interface.

To do this, there is a need for a secondary piece
of software, called a second-stage loader (SSL).
An SSL is simply a kernel that the boot ROM
loads and executes in place to complete the boot
process. This causes the boot ROM to load the
SSL code over SPI, at which point the boot ROM
is exited and execution starts at the beginning of
the SSL code section in memory. In the

.ldr

file, the SSL resides between any needed

Figure 1. SPORT/SPI Hardware Connections

Using the Blackfin® Processor SPORT to Emulate a SPI Interface (EE-304) Page 2 of 7

initialization code to set up external memory and
the actual application code, as shown in Figure 2.

Figure 2. Loader File (.LDR) Content

In this particular application, the SSL consists of
the required initialization code for the SPORT
interface, as well as the SPORT version of the
SPI boot code found in the boot ROM, which is
required to proceed with booting the actual
application that is still out in the SPI memory at
the time the SSL is executed.

Ideally, this can be handled by placing all
SPORT initialization code into the SSL and
tagging it as an init block in the boot stream (as
described in EE-240), such that it boots over SPI,
executes in place, and then completes the boot
process via the SPORT while executing the SSL
on-chip. However, this is a problem because the
boot process simply moves instructions/data via
DMA from blocks of SPI memory to blocks of
Blackfin memory, be it internal instruction/data
RAM or external SDRAM.

When the boot stream gets to the input block
destined for the top of on-chip Blackfin L1
instruction memory, the SSL that is currently
executing this boot code will be overwritten.
This behavior is usually not a factor because the
on-chip boot ROM is in a protected memory
region that is not writeable by the DMA
sequence used to move the application code into
on-chip memory. However, when executing init
block code out of unprotected on-chip memory,
this overwrite will compromise the boot process
and result in an invalid processor state because
the code that is booted in via DMA replaces the
currently executing SSL code, which has not
completed executing yet. This will cause
undesired execution of newly booted instructions
before the boot itself has completed.

A solution to this problem is to place the SSL in
external SDRAM and to change the address
where the boot kernel jumps to after completion
from the top of L1 memory to the address of the
SSL code itself. The nature of the boot ROM is
to set a default reset address in the Event Vector
Table location for the reset vector, which is
stored in the EVT1 register. For some processors,
this address is 0xFFA00000. For the smaller
memory derivative processors, the reset address
is 0xFFA08000. If the application wants to set an
explicit address, an overwrite of the EVT1
register can be done in the code that is located in
the init block. The code sequence to overwrite
the EVT1 register is as follows, and it can be
found in the SDRAM_InitCode.asm file in the
associated .ZIP archive

p0.h = hi(EVT1);

p0.l = lo(EVT1);

r0.h = START_OF_SSL_H;

r0.l = START_OF_SSL_L;

[p0] = r0;

ssync;

Using this scheme, the init block boots over SPI
and executes on-chip, setting up the SDRAM
interface timing appropriate for the application
and reconfiguring the reset address to be the
beginning of the SSL code. The SSL code is then
booted and resolved to SDRAM, which spares
the application from being forced to reserve
valuable on-chip memory. After the init block
and the SSL code are loaded, the boot kernel
finishes and jumps into SDRAM, where the rest
of the boot process is completed via the SPORT
pins, as controlled by the SSL.

This boot process will not be corrupted

L

The SSL code is 925 bytes in size, and should
reside in a portion of SDRAM that is guaranteed
to be unused by the application being booted.
An easy way to do this is by making a small
change to the application’s

as long as the actual application does
not overwrite the section of SDRAM
that the SSL is resolved to.

[2]

:

.ldf file to reserve a

a

Using the Blackfin® Processor SPORT to Emulate a SPI Interface (EE-304) Page 3 of 7