Specifications

4. Slave Design IP LIN Bus 2.0 Reference Design
38 Cypress Semiconductor – Rev. ** October 25, 2006
ing an application using PSoC Designer. Place the user
modules in the base configuration, finish the routing, and
generate application.
In the main.c file, follow these steps to properly start the LIN
firmware and to update the LIN frames.
1. Call the l_sys_init function to initialize the LIN function.
2. Assign an NAD to the slave node. Though the LDF is
able to list different possible NADs for any slave, the ini-
tially configured NAD must be decided by the main appli-
cation.
3. Enable the global interrupts using the M8C_EnableGInt
macro.
4. Write a 0 to the first byte of all the frame buffers. This is
to clear the status bytes of the buffers.
5. Inside an infinite loop add the code for your application.
6. Check the bfLAST_TRANSACTION_OK flag in the first
byte of each frame buffer to determine if the frame was
received successfully, and process the received data.
Refer to the example code in section 5, Demonstration
Projects on page 43.
7. Continue to update the frames that transmit data to the
master.
8. When updating the frame that contains the response
error bit, check the bResponseError variable, and set the
response error bit if the bResponseError variable is a
non-zero value.
4.6.10 Special Features
4.6.10.1 Power Management
According to the LIN 2.0 specification, if the bus is idle for
four seconds or if the master issues a sleep command, the
slave enters the sleep state. For this, there are some func-
tions included in the LinPowerManagement.c file. In the
main function, periodically check if the GoToSleep bit in the
LIN status register has been set. This register is accessed
by calling the l_read_status function in the core API. If the
GoToSleep bit is set, then call the go to sleep function in the
main application. This function is a blocking function. The
function in turn calls these three functions.
■ ShutdownLin: This function properly stops all the active
LIN resources and makes the pins High Z so that the
processor enters a low-power state. Inside this function,
there is an area where the user must enter code to stop
all the resources used by the main application. Also, if
the main application uses analog resources, including
analog reference and analog buffers, you must turn
them off to minimize current consumption during sleep
state. This function also disables all the interrupts except
the GPIO interrupt.
■ SleepLoop: When this function is entered, the
M8C_Sleep macro is executed to put the processor to
sleep. Once the processor is put to sleep, it wakes up
only upon an interrupt. Because all interrupts except the
GPIO interrupt are disabled, when the master or some
other slave in the cluster issues a wakeup command
(dominant state for a time of 250 µS to 5 mS), the pro-
cessor wakes up and enters a loop where it waits for the
bus to go to recessive state. When this happens, it
checks the length of the dominant state. If this length is
within the specified limit, it returns from this function. If
the dominant state is less than 250 µS or if the state
does not become recessive for more than 5 mS, the pro-
cessor is put to sleep again.
■ RestartLin: This function restores the processor to the
original configuration and also restarts the LIN function.
This function has a marked area where the user can add
code to start the resources required for the main applica-
tion.
4.6.10.2 Node Configuration
One very important feature of LIN 2.0 is the node configura-
tion. This feature is used to set up nodes in a cluster. It is a
tool to avoid conflicts between slave nodes when using off-
the-shelf slave nodes. Configuration is done by having a
large address space consisting of a message ID per frame,
a LIN product identification by slave node and an initial NAD
by slave node. Using these numbers, it is possible to map
unique frame identifiers to all frames transported in a bus. In
the PSoC slave IP during initial programming, all the pro-
tected IDs for all the frames are made 0xFF. The slave sup-
ports 16 frames. Each frame has four entries and the first
entry is the protected ID. This Frame table resides in the last
page of the Flash from address 0x3FC0. During node con-
figuration, the protected ID of the relevant frame is updated
by writing to the Flash. After one configuration, the Flash
retains the configuration. To prevent frequent unwanted
writes to the Flash, each time a node configuration com-
mand is executed, the new ID is compared with the ID
present in the table. If they are found to be the same, then
the write to the Flash is skipped. Thus, a Flash write takes
place only when the protected ID is to be changed, for
instance when the node is removed and put into another
cluster.
There is one design limitation you must take care of when
using the internal Flash to store the Protected ID table. To
update the protected ID in the Flash, you must do a partial
write of the Flash. This requires about 104 bytes on the
stack and the area 0xF8 to 0xFF in the upper area of RAM.
So this limits the amount of RAM that is available for the
user program. About 42 bytes are used by LIN variables and
the ‘C’ virtual registers. Add the 104 bytes of stack usage for
E2PROM, and the 8 bytes of upper RAM area and about 30
bytes of stack for normal program use. This leaves only
about 72 bytes of RAM available for the user program
including the Frame buffers. Of course, this limit only applies
to devices with 256 bytes RAM. For devices with higher
RAM where the stack resides in the last page, this limitation
does not exist.
4.6.10.3 Implementing Event-Triggered
Frames
To implement event-triggered frames, the frame must be
declared as event triggered in the Signal table. This is done
by performing an OR operation between the