CS4922-CL datasheet(23/34 Pages) CIRRUS

23 / 34 page

CS4922

host should hold off data delivery until XF1 falls

low once again.

Please see the documentation for the application

code being used in your system for a complete de-

scription.

BOOT PROCEDURE

The CS4922 is a RAM based audio decoder. Con-

sequently, program and data RAM must be loaded

from external memory after power up or any other

time a new program needs to be downloaded. Dur-

ing the loading procedure (boot), data is transferred

through the serial control port to program and data

memory. This procedure is controlled by a pro-

gram stored internally in ROM.

The boot procedure is initiated by a low to high

transition of the reset (RESET) pin with the BOOT

pin high. This initializes the program counter to lo-

cation 1000H, the first location in ROM which pre-

pares the CS4922 for download. After the ROM

program transfers data from the control port to

memory, it internally issues a software reset. The

software reset clears all registers and transfers con-

trol to the application now resident in RAM.

A hardware reset (RESET pin toggled low) with

the BOOT pin low has the same effect as a software

reset.

The CS4922 will boot from a micro controller us-

ing the serial control port. When booting, it can

communicate in an I2C or SPI format. If the CS

(chip select) pin is high when boot is initiated, the

port will communicate in I2C format. If the CS pin

is low when boot is initiated, the port will commu-

nicate in SPI. Please refer to the timing require-

ments found at the beginning of this document.

Nodes in an I2C network have unique network ad-

dresses. A message in an I2C network consists of

the address of the node receiving the message fol-

lowed by the message data. When the control port

is configured for I2C format, it normally compares

the address to an address stored in an internal reg-

ister. During the boot procedure, the control port is

programmed to ignore the address. The SCP sec-

tion on I2C operation explains the mechanics of

writing to the CS4922.

The boot program in internal ROM expects data

transferred through the control port to adhere to a

proprietary download image format. The download

image always concludes with two bytes containing

FF and three bytes containing a check sum. The

check sum is generated by summing all the previ-

ous data, address, and length bytes and truncating

to 24 bits.

During download, the CS4922 generates a check-

sum on the download image as it is received. This

check sum is compared to the value found at the tail

of the download image. If they do not match, the

REQ (request) pin is pulled low and the processor

does not issue the software reset. It stays in a loop

until boot is initiated again.

If the download image format is corrupted to the

point that the CS4922 does not know which bytes

represent the check sum, then REQ will not drop to

indicate download failure. This should never hap-

pen in a stable system.

During initial system testing we recommend down-

loading an image that has only the check sum cor-

rupted (the final 3 bytes). If REQ drops after the

complete application code image has been trans-

ferred, then the download procedure is functioning

properly. If REQ does not drop, then there is a

problem with the download procedure.

CS4922-CL Datasheet(PDF) 23 Page - Cirrus Logic

CS4922-CL Datasheet(HTML) 23 Page - Cirrus Logic

Html Pages

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34

Datasheet Download

Link URL