Application Note

Implementing Data Logger with

Z32F384 Internal Flash

AN038801-0816

Abstract
This application note shows how to implement a data logger to record persistence data for
future analysis. The application note uses the Z32F384 device, a member of Zilog’s
ZNEO32! Family of microcontrollers, to write the records to internal Flash.
The purpose of a data logger is to automatically collect data toward providing a compre-
hensive review of conditions upon recording. As an example, the black box used in most
aircraft records data containing the sequence of events occurring immediately preceding a
crash event. Similarly, a weather data logger maintains a record of environmental changes
for tracking storms and weather-related conditions.

Note: The source code files associated with this reference design, AN0388-SC01.zip, and the
example external logger using the Z8F6842 development kit, AN0388-SC02.zip, are
available free for download from the Zilog website.

Features
The main features of the data logger include:
• Records data records on internal Flash using a circular buffer approach
• Example includes the ability to log data in the following manner:
– Externally driven from SPI or I2C buses to record external data
– Keystroke logger, logs the keys received from the console and the interval time
between the keys
• Storage area in Flash is configurable
• Record size is configurable
• Isolated between underlining functions; therefore, other Flash configurations can be
used without changing the code for the upper layers
• Soft time keeper is implemented
• Allows user to display data via the console
– From beginning or ending of the list
– In a complete dump or a page at a time
– Able to continue to capture data, even during output

AN038801-0816 Page 1 of 18
 Implementing Data Logger with Z32F384 Internal Flash
Application Note

• Only Vector table, Interrupt handlers, and Flash write/erase located in RAM; every-
thing else in Flash
• Interrupt processing active during Flash write/erase

Discussion
To implement a data logger, it is necessary to have a way to track all of the data and to
replace old data with new data, while maintaining a history. A circular buffer can be used
to accomplish this requirement. A circular buffer tracks beginning and ending records;
therefore, the starting point may appear anywhere within the blocks. For simplicity, a
Beginning Record will always point to the start of a sector because erases only occur sec-
tor by sector. An Ending Record will point to the location of the next record to write to.
The data is handled as a record. The Data Record size must be evenly divisible into the
Flash Page size and must be less than or equal to the page size. The system is configurable
to create sectors as multiple pages, to provide the capability for other Flash arrangements.
Additionally, the data record must have a time stamp and a status byte. This information is
used to distinguish between valid records and time difference of records (to identify earlier
vs. later records), during initialization.

Hardware
The Z32F384 Hardware Development Kit is used in this application note. This kit pro-
vides an external 8 Mhz crystal and each port is exposed, which allows connection of an
external device to provide data records through the SPI and I2C buses. A FTDI USB to
UART is available to connect the system to a console such as HyperTerm.
The Z32F384 device includes the following features:
• High performance low-power Cortex-M3 core
• 384KB code Flash memory with cache function
• 16 KB SRAM
• 3-Phase PWM with ADC triggering function
– 2 channels
• 1.5 MSPS high-speed ADC with sequential conversion
– 2 units with 16 channel input
• System fail-safe function by clock monitoring
– XTAL OSC fail monitoring function
– System clock fail monitoring function
• Internal clock sources
– Internal ring oscillator (1 MHz ±50%)
– Internal oscillator clock (20 MHz ±3%)
– Internal Phase Lock Loop (PLL) up to 80 Mhz

AN038801-0816 Page 2 of 18
 Implementing Data Logger with Z32F384 Internal Flash
Application Note

• External clock sources

– External crystal oscillator (4~16 MHz)
– External sub oscillator (32 kHz)
• Watchdog timer
• 10 general purpose timer channels
• Timer/capture/PWM mode
• Free run timer
• Various external communication ports
– 4 UARTs
– 2 I2Cs
– 2 SPIs
– High current driving port for UART photo couplers
• Direct Memory Access (DMA) controller with 8 channels
• Debug and emergency stop function
• JTAG and SWD debugger
• Package: LQFP-100 (0.5mm pitch)
• Industrial grade operating temperature (- 40 ~ +85°C)

Firmware Implementation
The code structure is designed such that each file is as self-contained as possible. This
structure provides the ability to extract only the sections the developer is interested in
(along with the required supporting files), which can be added to their own project. The
DataStore section handles storing and retrieving of records, whereas the Datalogger sec-
tion handles the actual log activity, simply sending the data to the DataStore, without
regard to the location of the actual record being stored or retrieved.
The block diagram in Figure 1 shows the file structure. All the arrows point in a single
direction. Each file only knows about the files they are pointing to; however, it is not bidi-
rectional.

AN038801-0816 Page 3 of 18
 Implementing Data Logger with Z32F384 Internal Flash
Application Note

Main.c
Application entry, system
clock initialization and
vector table relocation

I2cslave.c
Uart.c
I2C handling for receiving/
Uart handling
sending external data

Spislave.c
SPI handling for receiving/
sending external data
Frt.c
Datalogger.c
32 bit Free Run Timer for
Handles logging data and
handling Time library (time
printing data out to console.
keeper)

DataStore.c
Get Records Maintains circular buffer Get Records
and record locations

Flash.c
Interface to low level flash
handler

Fmc.c
Low level flash handler for
reading/write/erase
functions

Figure 1. Block Diagram of Data Logger Code Structure

Records
The record size must always be an even divisor of 256 (page size of Flash) and less than or
equal to 256 in size. The record implemented in this application note is defined by the

AN038801-0816 Page 4 of 18
 Implementing Data Logger with Z32F384 Internal Flash
Application Note

structure RECORDDATA. As for most data loggers, each record has a time stamp and a
status byte, both of which are required. Because there is no Real time Clock, the system
uses the 32-bit Free Run Timer peripheral, configured for 1 second intervals to provide the
counter for the Time() function, using the time library. The remaining RECORDDATA
structure can be implemented per the developer’s intention (as long as it conforms to the
correct size). The time stamp is of time_t type, since the time library can be used to dis-
play as desired.

Circular Buffer
The data logger uses a circular buffer (also known as a ring buffer) approach to saving
records to Flash memory. This circular buffer allows the current data to replace older data
after Flash memory is full, resulting in the most recent data being stored. A circular buffer
has no absolute beginning or ending address. The physical buffer does, of course, but the
code wraps from the last physical address to the beginning physical address. Due to the
circular nature of this type of buffer, the beginning address of the data could be anywhere
within the physical buffer. The ending address of the data in the circular buffer could be
less than or greater than the physical beginning address. When the circular buffer ending
address equals the circular buffer beginning address, the beginning address is incremented
and the new data replaces the old data. Flash memory only allows erasure on a page-by-
page basis. The system can be configured for multiple pages per sector so the erasure can
be on a sector-by-sector basis. Because the Flash size can be configured, the data storage
quantity is variable. The circular buffer implementation has two file variables: End-
DataAddress and BegDataAddress. The EndDataAddress variable always points to the
next record to be written. The BegDataAddress variable always points to the start of a
filled sector (the earliest record). The addresses are physical addresses and, as they are
modified, they are wrapped to the beginning if the end has been reached.

Initialization
The initialization of the circular buffer is critical to set the BegDataAddress to the correct
sector of the beginning data and the EndDataAddress to the next unused record. Since the
beginning data could be in any sector (note, circular, so no absolute start value), find the
last valid record, which determines the position to start looking for the beginning record
location. It is only possible to erase sector by sector, so the BegDataAddress will always
point to the beginning of the sector.
Start by retrieving the last record of each sector. The first occurrence of an invalid record
(data that was erased) is the current sector to write to. To find the actual record to write to,
walk backwards through the records to find the first record with valid data. The End-
DataAddress will be set to point to the address of the next record.
After the EndDataAddress has been found, the BegDataAddress can be located. Start the
search at the beginning of the next sector and cycle through the first record of every sector
until a valid record is found. This is the address of the BegDataAddress.
If the system is shut down during an update, you may have written the last record of the
sector but not been able to erase the next sector. This situation prevents the finding of an
open record to start the search from. To account for this, check the last record of every sec-

AN038801-0816 Page 5 of 18
 Implementing Data Logger with Z32F384 Internal Flash
Application Note

tor to find the lowest time stamp. This will be the sector to erase, giving an EndDataAd-
dress location. Then the BegDataAddress is the beginning of the next sector.

Update Record
To update a record in the circular buffer, write the record to the address pointed to by End-
DataAddress. Next, increase the EndDataAddress by one record to point to the next record
to write to.
Because this can exceed the physical boundaries, check to ensure the EndDataAddress has
not exceeded the maximum Flash address. If it has, reset EndDataAddress to the begin-
ning of Flash.
Additionally, check for the occurrence when EndDataAddress equals BegDataAddress,
which indicates that the buffer is full; therefore, erase the sector that the EndDataAddress
is pointing to and move the BegDataAddress to the next sector. If the sector appears after
the ending physical sector, the BegDataAddress is set to the beginning physical address.

Flash
Internal Flash of the Z32F384 MCU is controlled through the Flash Controller peripheral.
Flash consists of 384 K in 96 K 32-bit words. There are 1,536 pages of 256 bytes each. The
controller supports page and macro erasing, but not word erasing. Programming of Flash
is done on a single 32-bit word alignment; therefore, each programming request can be
anywhere from one to eight words at a time. The Flash controller supports direct reading
of Flash via the Flash address, during normal operation. After the Flash controller goes
into Program mode, Flash can only be read via the data register; therefore, any program-
ming or erasing tasks must be executed in RAM.
Programming Flash requires specific timing in order to accomplish the task. If an attempt
to read Flash is made before the Flash controller has completed returning to normal opera-
tion, the system will execute a hard fault exception.
This application note utilizes interrupts to keep track of time, receive characters from the
UART, and input from the SPI and I2C bus. If you leave the interrupt functions in Flash
and an interrupt occurs, the system will fault, since the Interrupt controller will neither be
able to read the vector table located in Flash, nor read the interrupt handling instructions.
To get around this problem, this application note has located the interrupt vector table and
the interrupts into RAM, so the interrupts can continue to be processed while Flash is
being written or erased.
To place the code into RAM, a linker script (simple text file) is created to tell the linker
where to put the code. In Keil MDK, this is called a scatter file. In the scatter file
(AN0388.scat), the location where the object files and sections should be placed is spec-
ified. To help keep only the interrupt handlers in RAM, a macro is used to assign each
interrupt to INTERRUPT SECTION, which has been specified in the scatter file to tell the
linker that this code belongs in RAM. The unused interrupts are configured to an infinite
loop in the startup file; therefore, this was left in ROM. These interrupts should never be
called; if they are, it implies a bug and a hardware fault will be generated. The startup file
can be modified to place all interrupts in RAM, if desired. The scatter file is also instructed
to put the fmc.c object code into RAM. The only remaining item is the Interrupt Vector

AN038801-0816 Page 6 of 18
 Implementing Data Logger with Z32F384 Internal Flash
Application Note

table. This table cannot be automatically added, so the program must copy the vector table
located in Flash to RAM in the code. Again, using the scatter file, there is a direction to
reserve the space needed for the table at the base of RAM for the length of the table. In
RelocateVectorTable() function in Main, the linker variables are used to copy the
vectors over and then assign the NVIC Vector table location to the address.

External Interface
The system uses the SPI and I2C peripherals to allow external connections to read and
write data records. The communication peripherals are configured for slave operations.
The SPI/I2C commands that are handled are as follows:

0x00 Status
0x01 Write Record
0x10 Read Record Count
0x11 Read First Record (beginning of buffer)
0x12 Read Last Record (Last one added)
0x14 Read Next Record (Next record from what was last read)

The Status Byte returned can contain:

0xAA No Record Found

0xBBB Bad Request
0xFF Busy
0x00 Ready

I2C Slave
The I2C slave simply responds to the master transactions; therefore, all the work is done
within the Interrupt routine. The interrupt has been assigned a low priority, and the inter-
rupt function can be interrupted by the Timer and SPI, to prevent slowing down the sys-
tem. When receiving data, the I2C peripheral acknowledges the data received based on the
ACK bit in the control register, issues an interrupt, and holds down the SCL line until the
interrupt has been cleared, allowing time to process the incoming byte. The Master can
continue sending once the I2C peripheral releases the SCL line. When the Master is read-
ing, the I2C peripheral sends the byte located in the DR register and issues an interrupt,
allowing the DR to be populated for the next read from the Master.

SPI Slave
The SPI Slave also simply responds to the master transactions; however, the transaction is
controlled through the Chip Select (SS) pin. When the SS pin is low, the transaction is in
process. As the master clocks out a byte, the master also clocks in a byte, providing the
ability to read and write. The SPI Slave firmware is designed to return the Status value on
every byte sent by the master (although the Status value sent from a command byte is not
valid). There is no flow control like the I2C, so the Slave will respond with data every time
the master sends a byte. This does not offer much time to process the incoming bytes or

AN038801-0816 Page 7 of 18
 Implementing Data Logger with Z32F384 Internal Flash
Application Note

load the data. To handle this challenge, the interrupt routine must be quick, yet give the
master the information so the master doesn't read before the SPI slave is ready. This is
handled by sending a status byte after every byte received. When the master needs to send
data to the slave (such as command or data record), the status is always 0, if it is valid.
When the master wants to read, the status will be BUSY until data is ready, then the data is
sent. This allows the master to read the status byte until it is ready (0x00), then read the
data.
Retrieving records from the data logger can take some time. If the data logger is busy stor-
ing a record, it could be a few milliseconds. To enable the interrupt to be exited quickly to
prevent loss of communications, a feature in the Cortex M3 was utilized. The PendSV
interrupt is a software interrupt, and can only be issued by software. The firmware uses
this interrupt to allow the record retrieval for the SPI Slave to be executed at the lowest
priority, outside of the SPI interrupt (highest priority). The PendSV interrupt handler’s job
is to retrieve the data and provide the status, yet allow the interrupts received to be pro-
cessed. When the SPISlave interrupt receives a command to retrieve data, the PendSV
interrupt is invoked and the SPISlave interrupt is completed. Until there are no interrupts
pending, the PendSV interrupt is not called. After the interrupt chain has been completed,
the PendSVinterrupt is called. If a higher priority interrupt is received while the PendSV is
being serviced, the PendSV ISR is interrupted, the higher priority interrupt is processed,
then returns back to PendSV.

Time Library
The Cortex M3 does not have a Real Time Clock built into the core, so the standard library
Time does not have the ability to retrieve the time. To accomplish this, the time() and
clock() functions in the Time library use an SVC (semi-hosting) interrupt, to allow some
other part of the system to handle the time. This interrupt is used for any part of the system
that requires hardware responses when there is no built-in hardware, such as a console
through the UART. Debuggers will also use this interrupt for printing out logging results,
and Keil’s runtime library uses this interrupt for the sys_exit function.

Note: To see what semi-hosted functions are being called in Keil, add the #pragma:
#pragma import(__use_no_semihosting)
then rebuild the project. There will be link errors for every function that uses semi-hosting
(SVC interrupt).

To simplify the firmware without having to write a SVC interrupt handler, take advantage
of the library functionality. The Time library functions will only be added if there is a call
to the function and no function by the same name in the object code. This offers the ability
for the developer to redefine a function, yet use the rest of the library. Use this ability to
redefine the time() and clock() functions to provide the data from the Free Run Timer,
so the SVC interrupt is not called. When the time library needs to make a call to time(),
the library calls our redefined version, not having to call the SVC interrupt.

AN038801-0816 Page 8 of 18
 Implementing Data Logger with Z32F384 Internal Flash
Application Note

Usage
Although the data being tracked is not very useful, it demonstrates how a developer could
implement the data logger for their specific needs.

Using the Z32F384 Development Kit

Only a USB-UART console connection is required to track keystrokes. To use this feature,
perform the following procedure:
1. Connect a USB cable between the Mini-USB connector on the Z32F384 development
kit and the computer. On the computer, launch a terminal program, such as Hyperterm,
and set the Com Port properties to:
57600 baud, no parity, no flow control, 8 bits, 1 stop bit.
2. Load the AN0388-SC01 file in the ARM toolchain of your choice and build the proj-
ect.
3. Write the firmware to the Z32F384 development kit.
4. If the firmware is not running, start the firmware on the development kit (either
through the debugger or by pressing Reset). If the firmware is running, press the
return key to see the menu.
The console will display the menu shown in Figure 2.

Figure 2. Z32F384 Console

As you select different items on the menu, the keystroke is added to the data logger
records and is handled.

AN038801-0816 Page 9 of 18
 Implementing Data Logger with Z32F384 Internal Flash
Application Note

Using the Z8F6482 Development Kit

To track data from an external source, using the Z8F6482 development kit, observe the
following procedure:
1. On the Z32F384 development kit, remove Jumper from JP2 (this disables the power
from the USB port).
2. Place a jumper between each of the pins on the two development boards (see Table 1).

Table 1. Wiring Connections between the Z8F6482 and Z32F384 Development Boards

Signal Z8F6482 Z32F384

SPI-MISO PF7 J18-50 PA15 J1-32
SPI-MOSI PG1 J18-47 PA14 J1-31
SPI-SS PF6 J18-48 PA12 J1-23
SPI-SCK PG0 J18-45 PA13 J1-30
I2C-SDA PA7 J18-17 PC8 J2-32
I2C-SCL PA6 J18-15 PC7 J2-31
GND GND J18-68-72 GND J1-1,17, 26, J2-1, 26, 50

3. Connect 3.3 V power to CN2 (VDD/Gnd) to power the board (this is required, since
the Z8F6482 MCU cannot handle a 5 volt interface).
4. Connect a serial cable to the Z8F6482 development kit UART connector (J20) and to
a computer.
5. On the computer, launch a terminal program such as Hyperterm. Set the Com port
properties to:
57600 buad, no parity, no flow control, 8 bits, 1 stop bit.
6. Power the Z68F6482 development kit with either a USB cable or provide 5 volts
external power on J14/J15.
7. Load the AN0388-SC02 in the ZDSII for Encore, version 5.2.2 or later.
8. Select Build → Rebuild All from the menu.
9. Connect the USB Smart Cable to the Z8F6482 development kit.
10. Select Debug → Go from the menu to start the firmware.
The console will display the menu shown in Figure 3.

AN038801-0816 Page 10 of 18
 Implementing Data Logger with Z32F384 Internal Flash
Application Note

Figure 3. Z8F6482 Console

Note: If you see a string of strange characters on the console, press the Enter key to redisplay the
menu.

Note: The temperature and ADC readings on the Z8F6482 development kit are tied to the input
voltage. Use R13 to set the voltage correctly. See the Z8F6482 Development Kit User
Manual (UM0263) for more information.

The commands are as follows:

Setdate Sets the date in the RTC peripheral of the F6482, uses the
MM/DD/YYYY format
Settime Sets the time in the RTC peripheral of the F6482, uses the
HH:MM:SS format
Gettime Gets the current date and time from the RTC and displays on
the console
Start Starts Logging every 10 seconds
Stop Stops logging
Switch Changes between using the SPI and I2C Bus for input and
output

To start logging, type in the start command followed by the return key. Every 10 seconds,
a new data record will be sent to the data logger. You can switch between I2C and SPI by
using the switch command. To modify the frequency of sending a new data record, change

AN038801-0816 Page 11 of 18
 Implementing Data Logger with Z32F384 Internal Flash
Application Note

the LOGINTERVALMS macro in main.h. This controls the duration of wait time before
logging the next record in milliseconds.

Implementation
To add the data logger to other projects, the datastore.c, datastore.h, main.h,
flash.c, fmc.c, fmc.h, frt.c, frt.h files can be extracted without change. The
flash.h, datalogger.c, datalogger.h, recordconfig.h, main.c files may need
to be modified for a specific implementation. All the other files are optional, depending on
the desired implementation.

Descriptions for Files to be Modified

The flash.h file contains information about the configuration of Flash. These parame-
ters, such as the size of Flash, the sectors, and beginning and ending addresses, need to be
set to the desired values.
The datalogger.c file contains the procedures to log data to the datastore, retrieve
records and print out the data. These procedures will need to be modified to add and
retrieve data records and print the records out in a format that users can understand. The
datalogger.h file contains the prototypes for the datalogger.c file, which may or
may not need to be updated, depending on the modifications in datalogger.c.
The recordconfig.h file contains the definitions of the data record structure and sup-
porting structures. This will need to be modified to the implementation-specific structures.
The main.c file may need to be modified or removed and portions added to the imple-
mentation’s main file. The main() function simply needs to relocate the vector table and
initialize the data logger.

AN038801-0816 Page 12 of 18
 Implementing Data Logger with Z32F384 Internal Flash
Application Note

Summary
This application note describes how to implement a data logger, using the Z32F384 inter-
nal Flash. The data logger is segregated to allow it to be used elsewhere with minimal
implementation requirements. This example keeps track of keystrokes and handles exter-
nal interface to the data logger through both the SPI and I2C buses. This application note
also utilizes the Z8F6482 development kit to demonstrate how to provide the data through
the external buses to be recorded and how to retrieve the data to list the logs.
The firmware takes advantage of many of the Z32F384 MCU’s features and peripherals,
providing demonstrations on how to use the peripherals.

References
The following documents are associated with this Application Note:
• Z32F384 Product Specification (PS0346)
• Z32F384 Development Kit User Manual (UM0278)
• Z8F6482 Product Specification (PS0294)
• Z8F6482 Development Kit User Manual (UM0263)

AN038801-0816 Page 13 of 18
 Implementing Data Logger with Z32F384 Internal Flash
Application Note

Appendix A. Flowcharts
Figures 4 through 7 show the various flows in the data logger application note.

Start

Find the last block

Find End Address: written. Start with
Start at last record Error: No Empty Records last record of
of Sector 0 Sector 0

Is Record Less N Read Record

than Max?

Y
Set Ending
Check Last Address to Next
Record of Next Record
Sector Set Previous
TimeStamp
Read Record

Find Beginning
Address: Start with
Ending Address
Sector Start + 1 Check Last
sector Record of Next
Sector
N Is Record
Valid?

Y Does Record
Y
equal Ending
Read Record
Address Sector?

Check Previous
Record (of same N
sector)

Is TimeStamp
Read Record N
less than Previous
TimeStamp?
Is record
Y
beginning of
Y
Sector?

Is Record Y
N Set Ending
Valid?
address to
beginning of sector
N
Read record

Check First
Record of Next
Sector Erase Sector

Is Record Y
Valid?
Set Beg Address
to Record Set Beginning
N Address to Next
sector

End

Figure 4. Data Logger Initialization Flowchart

AN038801-0816 Page 14 of 18
 Implementing Data Logger with Z32F384 Internal Flash
Application Note

Start

Write Record
at End
Address

Set End Address

to next record

Is End Address
Y
Less than Max
Flash Address?

Set End Address

to Beginning of
Flash

Is End Address
N
equal to Beg
Address?

Convert End
Address to Sector
Number

Erase Sector

Set Beg Address

to Next Sector

Is Beg Address
Y
Less than Max
Flash Address?

Set Beg Address

to Beginning of End
Flash

Figure 5. Update Record Flowchart

AN038801-0816 Page 15 of 18
 Implementing Data Logger with Z32F384 Internal Flash
Application Note

6WDUW

< ,V6WDWHLQ <

:ULWHIURP
6HQG'DWD 6HQG1H[W%\WH
0DVWHU"
0RGH"
< &OHDU%DG5HTXHVW
6WRS ,V6WDWXV  <
6WDWXV
&RQGLWLRQ" %DG5HTXHVW" 1 1
6WDWHLVLGOH
1
1 6HQG6WDWXV (QGRI'DWD"
1

&RS\WHPSRUDU\ <
,V6WDWH <
EXIIHUWR3HQGLQJ
:ULLWHGDWD"
UHFRUGIRUORJJLQJ 6HWVWDWHWR
FRPSOHWHG
1
6HWWR
DFNQRZOHGJHGDWD
&OHDU&RPPDQG
6WDWHLV,GOH
'RQH

&OHDUFXUUHQW
1 FRPPDQG
,GOH6WDWH" 6HW6WDWXVWR
5HDG\
6WDWHLV,GOH ,V6WDWHZDLWLQJ 1 $GG'DWDWR
< IRUFRPPDQG" WHPSRUDU\EXIIHU

6WDUW 1 <
&RQGLWLRQ"

6DYHFRPPDQG
<

< &OHDUWHPSRUDU\
,V6WDWH:ULWH
EXIIHU
'DWD"
6WDWHLVLGOH

,I:ULWH < &KDQJH6WDWHWR

1
FRPPDQG :ULWHPRGH

1
< 6WDWHLVZDLWLQJIRU
:ULWH5HTXHVW"
FRPPDQG

5HWULHYH'DWD
1

6HW6WDWXVDV%DG
,V6WDWHZULWLQJ < 5HTXHVW
GDWD" 6WDWHLVQRZVHQG 6HW6WDWXVWR1R
,VWKHUHD 1 5HFRUG
VWDWXV
UHFRUG" 6HW6WDWHWR6HQG
6WDWXV
1
<

6HW6WDWH6HQG
'DWD

'RQH

'RQH

Figure 6. I2C Slave Interrupt Flowchart

AN038801-0816 Page 16 of 18
 Implementing Data Logger with Z32F384 Internal Flash
Application Note

SPI Slave Interrupt

Start Is Data N
Done
Received?

Has SS N
Y N Invoke
Changed? State == Get Set Command = Is Command a
PendSV
Command? Data in Write?
Interrupt
Y
N Y

Y Set State to Get

Is SS Low?
Command State == Y Set State to Set State to
Store Data
Writing? Writing Pending

N
N

Y Copy temp buffer

State ==
to pending record
Writing?
for logging

N
State == Send Y Is data Y
Send Next Byte
Data? pending?

Reset state, status N

N
and buffer

Send Busy

Done

Is State == Y Is Status == Y Set State to Send

Pending? Ready? Data

N N
Done

Start
PendSV Interrupt

Y Invoke
If result ==
Get Record PendSV
BUSY
Interrupt

If Result == NO Y Set Status to No

Done
RECORD Record

Set Status to
Ready

Figure 7. SPI Slave Interrupt and PendSV Interrupt Flowcharts

AN038801-0816 Page 17 of 18
 Implementing Data Logger with Z32F384 Internal Flash
Application Note

Customer Support
To share comments, get your technical questions answered, or report issues you may be
experiencing with our products, please visit Zilog’s Technical Support page at
http://support.zilog.com.
To learn more about this product, find additional documentation, or to discover other fac-
ets about Zilog product offerings, please visit the Zilog Knowledge Base at http://
zilog.com/kb or consider participating in the Zilog Forum at http://zilog.com/forum.
This publication is subject to replacement by a later edition. To determine whether a later
edition exists, please visit the Zilog website at http://www.zilog.com.

Warning: DO NOT USE THIS PRODUCT IN LIFE SUPPORT SYSTEMS.

LIFE SUPPORT POLICY

ZILOG’S PRODUCTS ARE NOT AUTHORIZED FOR USE AS CRITICAL COMPONENTS IN LIFE
SUPPORT DEVICES OR SYSTEMS WITHOUT THE EXPRESS PRIOR WRITTEN APPROVAL OF
THE PRESIDENT AND GENERAL COUNSEL OF ZILOG CORPORATION.

As used herein
Life support devices or systems are devices which (a) are intended for surgical implant into the body, or (b)
support or sustain life and whose failure to perform when properly used in accordance with instructions for
use provided in the labeling can be reasonably expected to result in a significant injury to the user. A
critical component is any component in a life support device or system whose failure to perform can be
reasonably expected to cause the failure of the life support device or system or to affect its safety or
effectiveness.

Document Disclaimer
©2016 Zilog, Inc. All rights reserved. Information in this publication concerning the devices, applications,
or technology described is intended to suggest possible uses and may be superseded. ZILOG, INC. DOES
NOT ASSUME LIABILITY FOR OR PROVIDE A REPRESENTATION OF ACCURACY OF THE
INFORMATION, DEVICES, OR TECHNOLOGY DESCRIBED IN THIS DOCUMENT. ZILOG ALSO
DOES NOT ASSUME LIABILITY FOR INTELLECTUAL PROPERTY INFRINGEMENT RELATED
IN ANY MANNER TO USE OF INFORMATION, DEVICES, OR TECHNOLOGY DESCRIBED
HEREIN OR OTHERWISE. The information contained within this document has been verified according
to the general principles of electrical and mechanical engineering.
ZNEO32! and Z8 Encore! XP are trademarks or registered trademarks of Zilog, Inc. All other product or
service names are the property of their respective owners.

AN038801-0816 Page 18 of 18