C6000 Embedded Design Workshop Using SYS/BIOS

Student Guide

BIOS – NOTES 6.70 – January 2013

Technical Training

C6000 Embedded Design Workshop Using BIOS - Introduction 0-1

Notice

Notice
Creation of derivative works unless agreed to in writing by the copyright owner is forbidden. No
portion of this publication may be reproduced, stored in a retrieval system or transmitted in any
form or by any means, electronic, mechanical, photocopying, recording or otherwise, without the
prior written permission from the copyright holder.
Texas Instruments reserves the right to update this Guide to reflect the most current product
information for the spectrum of users. If there are any differences between this Guide and a
technical reference manual, references should always be made to the most current reference
manual. Information contained in this publication is believed to be accurate and reliable.
However, responsibility is assumed neither for its use nor any infringement of patents or rights of
others that may result from its use. No license is granted by implication or otherwise under any
patent or patent right of Texas Instruments or others.

Copyright 2013 by Texas Instruments Incorporated. All rights reserved.

Technical Training Organization
Semiconductor Group
Texas Instruments Incorporated
7839 Churchill Way, MS 3984
Dallas, TX 75251-1903

Revision History
Note: all previous versions used CCSv3.3 and the DM6437 EVM. All future versions of this
workshop will use CCSv4+, C6748 EVM and BIOS 5.41+.

6.00 Sep 2011 – complete re-write to incorporate SYS/BIOS vs. DSP/BIOS

6.10 Dec 2011 – Upgrade to CCSv5.1, latest BSL, lab changes, errata
6.15 Jan 2012 – Lab/slide errata, lab changes
6.20 Feb 2012 – New Chapter 7. Lab/ppt errata.
6.30 May 2012 – Errata
6.40 June 2012 – Errata
6.50 Aug 2012 – Errata, reformat of chapters and additonal topics
6.60 Aug 2012 – Errata, add optional C66x Intro chapter
6.65 Sep 2012 – Errata, added quizes, new lab steps
6.67 Oct 2012 – Errata, add’l lab steps
6.70 Jan 2013 – Errata, upgrade to CCSv5.3

0-2 C6000 Embedded Design Workshop Using BIOS - Introduction

 Welcome
Welcome
Welcome to the Texas Instruments C6000 Embedded Design Workshop Using SYS/BIOS.
This workshop is primarily a software course that touches on the basics of creating a system using
SYS/BIOS APIs. In addition, you will learn some medium to advanced techniques in case they
are needed later on. By no means is this an exhaustive and comprehensive coverage of every
aspect of the BIOS Real-time Kernel. However, about 80% of what you need to know will be
covered here.
We also plan to cover some aspects of the hardware to give you a feel for what is going on under
the hood. This is a secondary focus of the workshop with the primary being the operating system.
It is literally impossible to provide a 3.5 day workshop that covers every detail. Our goal is
breadth on most topics and depth on the more important ones and also to provide resources for
you to find answers to your questions as they come up later on during your design phase.
In this “welcome” chapter an overall outline of the class is provided as well as some
administrative details. While this short chapter provides some useful information and dialogue, it
also allows time for late students to arrive without missing pertinent details associated with
learning the content.

C6000 Embedded Design Workshop Using BIOS - Welcome 0-1

Module Topics

Module Topics
Welcome ......................................................................................................................................................0-1
Module Topics..........................................................................................................................................0-2
Welcome ...................................................................................................................................................0-3
Administrative Topics .........................................................................................................................0-3
Goals of the Workshop ........................................................................................................................0-3
What is “Outside the Scope”?..............................................................................................................0-4
Workshop Outline – 4 Levels of Experience .......................................................................................0-4
Introductions ........................................................................................................................................0-5
For More Information… ......................................................................................................................0-6
Texas Instruments Wiki Site................................................................................................................0-6
BIOS Workshop - Online ....................................................................................................................0-7
Questionnaire (fill out after Lab 1) ..........................................................................................................0-9

0-2 C6000 Embedded Design Workshop Using BIOS - Welcome

 Welcome

Welcome
Administrative Topics

Goals of the Workshop

What Will You Accomplish?

Challenge Areas of Focus
 Define key software design decisions • Priorities
in developing real-time systems: • Multiple Threads
• Memory Footprint
 Apply optimal SYS/BIOS constructs to • Scheduling
implement a given real-time system: • Interrupts
• Dynamic Memory
• Instrumentation
 Use development tools to compile, • CCS
link, debug and benchmark code on a • Compiler/Linker
development platform: • Profiling and Debug
 Learn optimization techniques to • Optimizer
increase system performance: • Cache
• EDMA
What we won’t cover...
5

C6000 Embedded Design Workshop Using BIOS - Welcome 0-3

Welcome

What is “Outside the Scope”?

Workshop Outline – 4 Levels of Experience

0-4 C6000 Embedded Design Workshop Using BIOS - Welcome

 Welcome

Introductions

C6000 Embedded Design Workshop Using BIOS - Welcome 0-5

Welcome

For More Information…

Texas Instruments Wiki Site

0-6 C6000 Embedded Design Workshop Using BIOS - Welcome

 Welcome

BIOS Workshop - Online

C6000 Embedded Design Workshop Using BIOS - Welcome 0-7

Welcome

*** HTTP ERROR 404 – PAGE MISSING ***

0-8 C6000 Embedded Design Workshop Using BIOS - Welcome

 Questionnaire (fill out after Lab 1)

Questionnaire (fill out after Lab 1)

Remove this page and place it on your desk so that you can fill it out after Lab 1 and hand it in to
the instructor.
The instructor will use this to help guide some of the timing in the workshop – which topics to
spend more/less time on. It will also provide some data to correleate the most needed topics (i.e.
if you have NO interest and extreme knowledge, well, that might be a lower priority. On the other
hand, if you have extreme interest and NO knowledge, that begs for more time and depth).

Workshop Questionnaire (fill in during Lab 1)

Rank your current interest and experience (0-5). 0=none, 5=adv/high Name/Date_______________________

Experience Interest Topic

Circle One: ARM DSP ARM+DSP, Device name:
--- --- Hardware
Peripherals (which ones?):
EDMA3 – how it works and how to program it
Memory (circle most important): static, dynamic, internal, external
Cache – how it works and how to program it
C6000 CPU Architecture
C66x Architecture and MCSDK
--- --- Software
Circle One: DSP/BIOS 5.x SYS/BIOS 6.x
Code Composer Studio (CCS) v5.x
C Compiler and Optimizer (how to optimize your C code)
Peripheral Programming (drivers, PSP, IOM, stream I/O)
OMAP-L138/C6748 Flash Programming and Boot
Emulation and CCS Debugging Skills
20

C6000 Embedded Design Workshop Using BIOS - Welcome 0-9

Questionnaire (fill out after Lab 1)

*** why are you staring at a blank page? Do you need therapy? ***

0 - 10 C6000 Embedded Design Workshop Using BIOS - Welcome

 Devices
Introduction
The purpose of this chapter is to provide an overall introduction to the device, peripherals, device
roadmaps and development tools. This sets the stage for each chapter that follows.
At the end of this chapter, you will have a chance to hook up the C6748 EVM and launch CCSv5
to verify that the board is set up properly.

Objectives

Objectives

 Provide an overview of the TI processor

portfolio.
 Introduce the C6748 – our workshop
target architecture
 Highlight a few of the peripherals
on these devices.
 Lab1 – Ensure the lab environment is
hooked up properly.

C6000 Embedded Design Workshop Using BIOS - Devices 1-1

Module Topics

Module Topics
Devices .........................................................................................................................................................1-1
Module Topics..........................................................................................................................................1-2
TI Embedded Processor Families ............................................................................................................1-3
C6000 DSPs .............................................................................................................................................1-4
Classic DSP Problem ...........................................................................................................................1-4
DSP Core .............................................................................................................................................1-4
C6000 DSP Family Roadmap ..............................................................................................................1-5
Peripherals...............................................................................................................................................1-7
Overview (the whole grab bag) ...........................................................................................................1-7
Programmable Real-Time Unit (PRU) ................................................................................................1-8
Switched Central Resource (SCR) & EDMA ......................................................................................1-9
SCR – Connection Matrix ...................................................................................................................1-9
Pin Muxing ........................................................................................................................................1-10
Example Device – TMS320C6748 .........................................................................................................1-11
ARM-based Device Families ..................................................................................................................1-12
Choosing A Device .................................................................................................................................1-13
Chapter Quiz ..........................................................................................................................................1-14
OMAP-L138 (C6748) EVM ...................................................................................................................1-15
Lab 1 – System Setup .............................................................................................................................1-17
A. Computer Login ........................................................................................................................1-17
B. Connecting the OMAP-L138 EVM to the PC ..........................................................................1-18
C. Launch CCS ..............................................................................................................................1-19
Additional Information...........................................................................................................................1-24

1-2 C6000 Embedded Design Workshop Using BIOS - Devices

 TI Embedded Processor Families

TI Embedded Processor Families

TI Embedded Processors Portfolio

SYS/BIOS supports ALL of these platforms except for C5000

4

C6000 Embedded Design Workshop Using BIOS - Devices 1-3

C6000 DSPs

C6000 DSPs
Classic DSP Problem

What Problem Are We Trying To Solve?

x Y
ADC DSP DAC

Digital sampling of Most DSP algorithms can be

an analog signal: expressed with MAC:
count
A
Y = Σ coeffi * xi
i = 1

for (i = 0; i < count; i++){

t Y += coeff[i] * x[i]; }

How is the architecture designed to maximize computations like this?

6

DSP Core

1-4 C6000 Embedded Design Workshop Using BIOS - Devices

 C6000 DSPs

C6000 DSP Family Roadmap

C6000 Embedded Design Workshop Using BIOS - Devices 1-5

C6000 DSPs

1-6 C6000 Embedded Design Workshop Using BIOS - Devices

 Peripherals

Peripherals
Overview (the whole grab bag)

C6x DSP
Graphics
ARM
Accelerator
Video Accelerator(s)

Peripherals PRU Video/Display

(Soft Peripheral) Subsytem
Serial Storage Master Timing
McBSP DDR2 PCIe Timers
CAN Capture
McASP DDR3 USB 2.0 Watch
ASP SDRAM EMAC PWM Analog
UART Display
UART Async uPP eCAP
What’s Digital
SPI SD/MMC HPI RTC Next? Display
I2C ATA/CF EDMA3
LCD
DIY…
CAN SATA SCR GPIO Controller

We’ll just look at three of these: PRU and SCR/EDMA3 13

C6000 Embedded Design Workshop Using BIOS - Devices 1-7

Peripherals

Programmable Real-Time Unit (PRU)

1-8 C6000 Embedded Design Workshop Using BIOS - Devices

 Peripherals

Switched Central Resource (SCR) & EDMA

SCR – Connection Matrix

C6000 Embedded Design Workshop Using BIOS - Devices 1-9

Peripherals

Pin Muxing

1 - 10 C6000 Embedded Design Workshop Using BIOS - Devices

 Example Device – TMS320C6748

Example Device – TMS320C6748

C6000 Embedded Design Workshop Using BIOS - Devices 1 - 11

ARM-based Device Families

ARM-based Device Families

TI Offers the Right ARM Solution

Comprehensive developer ecosystem

32-bit ARM® 32-bit ARM® 32-bit ARM®

MCU for ARM
Cortex™-M Cortex™-M3 + Cortex-A8 &
C28x MCUs Safety-Critical
MCUs ARM9™ MPUs
Applications

Stellaris® Concerto™ Hercules™ Sitara™

Software support

Development tools
ARM ® Cortex™ -M ARM ® Cortex™ -M3 ARM® Cortex™-R4 ARM Cortex-A8
Fixed and floating-point Plus C28x Floating Pt Fixed and floating-point

Up to Up to Up to 350 DMIPS/ 375MHz to

80 MHz 150 MHz 220 MHz 1.5GHz
Flash Flash Up to 3 MB Flash, Cache,
8 KB to 512 KB Up to 1 MB 256 KB RAM RAM, ROM
USB, ENET USB OTG, ENET FPU, ECC, Timer/PWM USB, CAN, SATA,
MAC+PHY CAN, ,CAN, UART Co-Proc, 12bit ADCs, CAN,
SPI, PCIe, EMAC
ADC, PWM, SPI ADC, PWM, SPI EMIF, LIN, SPI, FlexRay
Connectivity,Security, Solar, Emeter, Drives Transportation, Motor Industrial automation,
Control, Certified for use POS & portable
Motion Control, HMI, and Automation in safety critical data terminals,
Industrial Automation (SIL3) systems HMI, medical
$1.00 to $8.00 $8.00 to $17.00 $5.00 to $30.00 $5.00 to $50.00

Responsive design support

26

1 - 12 C6000 Embedded Design Workshop Using BIOS - Devices

 Choosing A Device

Choosing A Device

C6000 Embedded Design Workshop Using BIOS - Devices 1 - 13

Chapter Quiz

Chapter Quiz
Chapter Quiz
1. How many functional units does the C6000 CPU have?

2. What is the size of a C6000 instruction word?

3. What is the name of the main “bus arbiter” in the architecture?

4. What is the main difference between a bus “master” and “slave”?

5. Fill in the names of the following blocks of memory and bus:

256

CPU
128

1 - 14 C6000 Embedded Design Workshop Using BIOS - Devices

 OMAP-L138 (C6748) EVM

OMAP-L138 (C6748) EVM

C6000 Embedded Design Workshop Using BIOS - Devices 1 - 15

OMAP-L138 (C6748) EVM

*** this page is empty, so why are you reading this? ***

1 - 16 C6000 Embedded Design Workshop Using BIOS - Devices

 Lab 1 – System Setup

Lab 1 – System Setup

A number of different Evaluation Modules (EVMs) and DSP Starter Kits (DSKs) can be driven
by Code Composer Studio (CCS). This first lab exercise will provide familiarity with the method
of testing the hardware and setting up CCS to use the selected target. Steps in this lab will
include those noted in the diagram below:

A. Computer Login
1. If the computer is not already logged-on, check to see if the log-on information is posted.
If not, please ask the instructor (student/student is a common ID/psw to try).

C6000 Embedded Design Workshop Using BIOS - Devices 1 - 17

Lab 1 – System Setup

B. Connecting the OMAP-L138 EVM to the PC

Note: For a complete guide to where/how to download ALL software development tools (and
versions) to re-create this workshop environment, read the BIOS Workshop Setup Guide
located at the following directory: C:\SYSBIOSv4\Labs\techdocs. This pdf file shows
every step that the workshop author performed to create the tools environment. This
document is also available on the BIOS Workshop Wiki site at:

http://processors.wiki.ti.com/index.php/TMS320C64x%2B_DSP_System_Integration_Workshop_using_DSP/BIOS

The software should already be installed on the lab workstation. All that should have to be done is
to physically connect the EVM.
2. Connect the XDS510 pod to the board and the other end to the to a USB port on the PC.
If you connect the USB cable to a USB Hub, be sure the hub is connected to the PC or laptop
and power is applied to the hub). If you ever use the on-board emulation (EVM USB jack),
there are actually two mini-USB connectors on the baseboard – make sure you use the proper
one – it is located next to the serial port on the top left-hand part of the board.

Note: Note: If, after plugging in the USB cable, a found new hardware message appears
indicating that the USB driver needs to be installed, notify your instructor and simply go
through the wizard to install “this time only” the “recommended” driver. In most
classroom installations, this has already been performed.

3. Plug in the audio cables:

− Use a stereo mini plug to connect the PC audio line out to the EVM audio LINE IN.
− Use another stereo mini plug to connect the EVM LINE OUT to the
headphones/speaker.
Ensure that the plugs are fully inserted so that the audio will be reliably transferred.
4. Verify DIP_5 and DIP_8 are UP [ON] on Switch 7 (S7).
There are TWO switches or “banks of DIP switches” (8 sliders per bank). The switch on the
left is labeled Switch 2 (S2) and is used as user switches (that you can use as inputs to your
application). The one on the right is labeled Switch 7 (S7) and sets the BOOT MODES for
the DSP and ARM. For emulation, we want the small DIP switches – DIP_5 and DIP_8 (on
S7) in the ON (UP) position.
5. Plug the power cord of the power supply into an AC source.
The power cable must be plugged into AC source prior to plugging the 5 Volt DC output
connector into the EVM.
6. Make sure your board contains a SOM module – the processor itself.
7. Plug the power supply output cable into the EVM’s power receptacle.
When power is applied to the board, the POWER ON LED which is located just above the
RESET button (left of the power switch) will light up. Make sure the power switch is “ON”
and the LED is on.

1 - 18 C6000 Embedded Design Workshop Using BIOS - Devices

 Lab 1 – System Setup

C. Launch CCS
Code Composer Studio (CCS) supports numerous TI processors (including the C6000 and C5000
series) and a variety of target boards (simulators, EVMs, DSKs, and XDS emulators).
1. Play some music on the PC.
On the desktop, locate the “MP3” folder and pick out a song. Double-
click on the song to play it. You may have to plug your headphones in to
hear it. Make sure the volume is at an appropriate level. When Windows
Media Player opens, ensure that “Play Forever” or “Repeat” are selected
so that the music never stops.
2. Launch CCSv5.
Launch CCSv5 by double-clicking on the CCSv5 icon on the desktop as shown. If the
“startup” screen appears (like it is the first time CCSv5 has ever launched on this PC), simply
click in the upper right-hand corner to “Start Using CCS”. If asked to choose a “workspace”,
just choose the default and check “don’t ask again”.
3. Check the Target Config File.
On the menu, select:
View  Target Configurations
Make sure that the following target config file is the “Default”:
XDS510_USB_EVM6748_TTO.ccxml

As shown here:

Don’t close this window…

C6000 Embedded Design Workshop Using BIOS - Devices 1 - 19

Lab 1 – System Setup

4. Launch the TI Debugger.

Because we are simply loading an executable (.out file), it is not necessary to open a project
and build anything. We simply want to load the file, play some music and make sure all
connections are working properly.
The easiest and most convenient way to launch a debug session in CCS is to use the target
config file itself. This is a great way to test the connection to the board instantly. Right-click
on the proper target config file below and select “Launch Selected Configuration…”:

CCSv5 is basically built using two parts: the Editor and the Debugger. In the older CCS 3.3,
the editor and debugger were combined together. In CCSv5, they are separate.
In order to run code on the EVM, we must complete three steps:
• launch the debugger
• connect to the board
• load the program

As you’ll learn soon, all three of these steps can be combined together for convenience.
Launching the Debugger should take about 5-7 seconds. Thankfully, most of the time, we
will leave this “Debug Session” open as we build new code and then the code simply loads
itself to the board and we don’t have to “re-launch” the debugger each time.
Note the change in the “perspective” of the windows. You just launched a “Debug Session”
which contains a set of windows that are different than the C/C++ Edit Perspective.

1 - 20 C6000 Embedded Design Workshop Using BIOS - Devices

 Lab 1 – System Setup

5. Connect CCS to the EVM (target).

If you look near the upper lefthand part of the screen, you will see a symbol that looks like
the following:

This little “connection” icon is greyed out because we are NOT connected to the board yet.
When you click this button, and connection is successful, it will “light up”. Well, that’s our
next step – to connect to the target. You can simply click this button or…
On the menu, select:
Run → Connect Target

During this step, you will see some “Console” comments that are generated by CCS running
the GEL file associated with this EVM/device. The GEL file is setting up the clocks and
memories so that programs will run correctly. Much more on this later…

Note: This is the step where the GEL script runs to initialize the board and memory. The default
GEL file that you download from LogicPD is FLAWED. It gets hung up in the DDR init
phase. We are using a “new and improved” and “yet unreleased” version of this GEL file
– oh, that actually WORKS. It is on the BIOS workshop website. It actually works for
BOTH the C6748 and OMAP-L138 SOMs (it is a thing of beauty). If you are using this
EVM, please download this GEL file from the BIOS workshop wiki and use it –
otherwise, you’ll have a less healthy experience. You have a copy of this file in the
labs/techdocs folder that you will take home on a USB stick at the end of class.

C6000 Embedded Design Workshop Using BIOS - Devices 1 - 21

Lab 1 – System Setup

6. Load the Program (audio_test.out).

Now that the Debug Session is active and we’re connected to the target, let’s load the audio
test file. This .out file was generated by building an example file located in the BSL (Board
Support Library) examples created by Logic PD. You’ll actually build this project in the next
lab. For now, we just want to run it and hear the music.
On the menu bar, click the down arrow next to the “Load” icon:

Browse to the following location:

C:\SYSBIOSv4\Labs\Lab01_Test_Audio\audio_test.out

Load the executable to the board by clicking Ok. You will see the progress indicator while
the program loads. Again, this should only take a few moments. You will see something
similar to the following screen when the program has loaded:

You may see a “Source Not Found” message. Just ignore it.

1 - 22 C6000 Embedded Design Workshop Using BIOS - Devices

 Lab 1 – System Setup

7. “Play” the audio_test program.

Before you click Play, ensure the music is playing and that the volume is at an appropriate
level and you have your headphones on. Near the top of the screen, locate the “Play” button:

Click the green Play button.

You will see the console output displaying progress messages of this little audio test program.
The first test is LINE OUT and the program will send a sine wave signal from the McASP
(audio serial port) to the AIC3106 (TI Analog Interface Chip that contains a DAC/ADC
combo) which drives the LINE OUT jack on the EVM. This sine tone will last 5 seconds.
Then, the music you are playing will “pass through” the LINE IN jack to the LINE OUT jack
for 15 seconds. The music follows this path: LINE IN → ADC → McASP Rcv → CPU Reg
→ McASP Xmt → DAC → LINE OUT. We will exploit this path futher in later labs.
If you hear the sine tone and the music, your board is connected properly. If not, please
inform your instructor.
8. Terminate the Debug Session.
When the music ends, this is your cue to end your Debug Session. Notice that you can
“Pause” the execution as well. Pausing is similar to the old “Halt” button in CCS 3.3.
However, in this lab, we actually want to “Quit the Debug Session” and “Terminate the
connection to the EVM”, so we click the red “Terminate” button to the right of the Play
button.
9. Close CCSv5 and power cycle your board.

10. FILL OUT THE QUESTIONNAIRE.

At the end of chapter 0, you’ll find a questionnaire about your reasons for coming to this
workshop. When finished, hand them to your instructor. They will use these to determine the
greatest topical needs of the class for this week.

You’re finished with this lab. If time permits, you may move on to additional
“optional” steps on the following pages if they exist.

C6000 Embedded Design Workshop Using BIOS - Devices 1 - 23

Additional Information

Additional Information

M
SCR & Megamodule S
Master Slave 32
EDMA3 SCR = Switched Central Resource
TC0
CC TC1
TC2 McBSP L1P
PCI
Utopia
C64x+ MegaModule L1P PERIPH
DDR2
EMAC Mem AET
HPI EMIF Ctrl M S
PCI Cfg
D D
L2
L2 Mem IDMA CPU S
M
S
M
Ctrl
L L

External L1D
S M Mem
128 Cntl Mem
Ctrl PERIPH =
M S M All peripheral’s
128
Cfg registers
L1D S
DATA 32
SCR
CFG
 Master: has its own DMA – can initiate a transfer
 Example: CPU programs EDMA3 Cfg regs (via CFG SCR). EDMA xfrs McBSP DRR L2
SCR
 Not all connections in DATA SCR are valid (see connection matrix)

1 - 24 C6000 Embedded Design Workshop Using BIOS - Devices

 Code Composer Studio v5
Introduction
This chapter will introduce Code Composer Studio (CCS) version 5. Some users are most likely
familiar with CCS v3.3 and have not had a chance to use CCSv4 or v5. Others have been using
v4 for awhile and plan to upgrade to CCSv5. Some may have already been using CCSv5 for
awhile.
Every lab in this workshop will use CCSv5, so the purpose of this chapter is to provide a very
basic overview of terminology and how to perform basic actions to build and debug applications.
Throughout the entire workshop, users will have many opportunities to use CCSv5 in completing
each one of the labs associated with most chapters.
For more detailed information on CCSv5, please refer to the “For More Info” slide near the end
of the CCSv5 section of this chapter.

Objectives

Objectives

 Describe the fundamentals of Code Composer

Studio (CCS) v5
 Demonstrate new features of CCSv5 such as
workspaces, perspectives and views
 Describe the device/system memory map and
how to create a linker.cmd file
 Lab 2 – Create, build and debug several
code examples using CCSv5

C6000 Embedded Design Workshop Using BIOS - Code Composer Studio v5 2-1
Module Topics

Module Topics
Code Composer Studio v5 .........................................................................................................................2-1
Module Topics..........................................................................................................................................2-2
Code Composer Studio v5 - Intro.............................................................................................................2-3
Functional Overview ...........................................................................................................................2-3
Perspectives .........................................................................................................................................2-5
Projects ................................................................................................................................................2-5
Eclipse – “Workspaces” ......................................................................................................................2-7
Target Configuration File (.ccxml) ......................................................................................................2-7
GEL Files ............................................................................................................................................2-8
Build Configurations, Build Options ...................................................................................................2-8
Licensing & Pricing .............................................................................................................................2-9
For More Information... .......................................................................................................................2-9
Device Memory ......................................................................................................................................2-10
C6748 Internal & External Memory ..................................................................................................2-10
Code & Data “Sections” ....................................................................................................................2-11
Linking & Linker Command Files ....................................................................................................2-12
Chapter Quiz ..........................................................................................................................................2-14
Lab 2 – CCSv5 Projects .........................................................................................................................2-15
Lab 2A – Hello World – Procedure ...................................................................................................2-16
BIOS Workshop File Management - Intro ....................................................................................2-16
Create a New Project .....................................................................................................................2-17
Create hello_world main(). ...........................................................................................................2-20
Add a Linker Command File .........................................................................................................2-21
Create a New Target Configuration File (.ccxml) .........................................................................2-22
Analyze the Linker Command File ...............................................................................................2-25
Build, Load & Run. .......................................................................................................................2-25
That’s It. You’re Done!!................................................................................................................2-30
Lab 2B – Test Audio – Procedure .....................................................................................................2-31
File Management ...........................................................................................................................2-31
Create a New Project. ....................................................................................................................2-32
Analyze the Test Audio Example Files .........................................................................................2-34
Play the Test Audio Example ........................................................................................................2-35
Basic Debugging Techniques ........................................................................................................2-36
That’s It. You’re Done!!................................................................................................................2-37
Additional Info & Notes .........................................................................................................................2-38

2-2 C6000 Embedded Design Workshop Using BIOS - Code Composer Studio v5
 Code Composer Studio v5 - Intro

Code Composer Studio v5 - Intro

Functional Overview

C6000 Embedded Design Workshop Using BIOS - Code Composer Studio v5 2-3
Code Composer Studio v5 - Intro

2-4 C6000 Embedded Design Workshop Using BIOS - Code Composer Studio v5
 Code Composer Studio v5 - Intro

Perspectives

Projects

C6000 Embedded Design Workshop Using BIOS - Code Composer Studio v5 2-5
Code Composer Studio v5 - Intro

2-6 C6000 Embedded Design Workshop Using BIOS - Code Composer Studio v5
 Code Composer Studio v5 - Intro

Eclipse – “Workspaces”

Target Configuration File (.ccxml)

C6000 Embedded Design Workshop Using BIOS - Code Composer Studio v5 2-7
Code Composer Studio v5 - Intro

GEL Files

Build Configurations, Build Options

2-8 C6000 Embedded Design Workshop Using BIOS - Code Composer Studio v5
 Code Composer Studio v5 - Intro

Licensing & Pricing

For More Information...

CCSv5 – Getting Started & Video Tutorials

http://processors.wiki.ti.com/index.php/CCSv5_Getting_Started_Guide

http://processors.wiki.ti.com/index.php/Video_Tutorials_CCSv5

23

C6000 Embedded Design Workshop Using BIOS - Code Composer Studio v5 2-9
Device Memory

Device Memory
C6748 Internal & External Memory

C6748 Memory Memory Map

Internal 1170_0000 L2 ROM
 Level 1 Memory (32KB each) 1180_0000
 Cache or RAM
 L1P (prog), L1D (data) L2 IRAM
 Level 2 Memory (256KB)
11E0_0000 L1P RAM
 RAM (prog or data)
 Up to 256KB can be cache 11F0_0000 L1D RAM
 Level 3 Memory (128KB)
6000_0000
 “Shared RAM” (no cache) EMIFA (CS2)
6200_0000
EMIFA (CS3)
6400_0000
L1P EMIFA (CS4)
6600_0000
EMIFA (CS5)

L2 RAM DDR2 8000_0000 L3 RAM

CPU Prog/Data C000_0000
EMIFA
DDR2 (DDR_CS)

L1D L3 FFFF_FFFF

26

2 - 10 C6000 Embedded Design Workshop Using BIOS - Code Composer Studio v5

 Device Memory

Code & Data “Sections”

C6000 Embedded Design Workshop Using BIOS - Code Composer Studio v5 2 - 11

Device Memory

Linking & Linker Command Files

2 - 12 C6000 Embedded Design Workshop Using BIOS - Code Composer Studio v5

 Device Memory

Linker Command File

-l rts6400.lib LIBRARIES

-stack 0x800
STACK/HEAP SIZES
-heap 0x800

MEMORY { MEMORY SEGMENTS

IRAM: origin = 0x11800000, len = 0x40000
FLASH: origin = 0x64000000, len = 0x400000
DDR: origin = 0xC0000000, len = 0x8000000
}

SECTIONS {
.bss {} > IRAM
.far {} > IRAM CODE/DATA SECTIONS
.text {} > DDR
.cinit {} > FLASH Note: later on, BIOS config
} (.cfg) generates this file for us…
33

C6000 Embedded Design Workshop Using BIOS - Code Composer Studio v5 2 - 13

Chapter Quiz

Chapter Quiz
Chapter Quiz
1. Name the two CCS perspectives and the differences between them:

2. What is the CCS “workspace” used for?

3. Which file specifies the target, target connection and GEL file?

4. What does a GEL file do?

5. What is the purpose of a linker.cmd file and what are the two main
items it specifies?

2 - 14 C6000 Embedded Design Workshop Using BIOS - Code Composer Studio v5

 Lab 2 – CCSv5 Projects

Lab 2 – CCSv5 Projects

In this lab, you will have your first opportunity (most likely) to work with CCSv5. Because this is
our first real lab of the workshop, we plan to keep it very simple. First, we’ll create a new project
that performs the famous “hello world” program. In part B, we will use some files written by
Logic PD (the OMAP-L138 EVM developer), combine them into our own project and build and
run it to verify that the audio data path works.
While this is definitely the “BIOS Workshop”, these labs intentionally do not incorporate the
DSP/BIOS Real-time operating system and scheduler. We have plenty of time to learn those
concepts in later labs. 

Application 2A: Classic “Hello World” using printf()

Application 2B: BSL Example - sine tone out (5s) followed by audio pass thru (15s)
Key Ideas: CCSv5 project creation, using linker.cmd files, build/load/run concepts

C6000 Embedded Design Workshop Using BIOS - Code Composer Studio v5 2 - 15

Lab 2 – CCSv5 Projects

Lab 2A – Hello World – Procedure

In this lab, we will create a project that contains one simple source file – “Hello World”. The
purpose of this lab is to practice creating projects and getting to know the look and feel of
CCSv5. If this IDE is not new to you, it will be a good review – and the labs will get more intense
and will contain less “hand holding” as time goes on.

BIOS Workshop File Management - Intro

1. Browse the directory structure for this workshop.
Open Windows Explorer and browse the following locations:

• C:\SYSBIOSv4\Labs & Sols – In \Labs, notice the numbered labs (e.g. Lab3)
and open one or two of them to see the directories they contain. Each Lab directory will
contain at least two directories – one called \Files and the other named \Project.
“Files” will always contain the “starter files” needed for that lab. \Project is where we
will create each project for each lab. \Sols is where you will find all solution files. If
you get stuck on a particular lab and aren’t sure exactly how to do something, check out
the solution for that lab for a hint.

• C:\SYSBIOSv4\Labs\techdocs – this directory contains almost all of the

technical documentation for anything you’ll need to develop code for this processor,
EVM and operating system. We will be using these docs in several of the labs.

• C:\CCStudio_v5\ccsv5 – this is where the IDE is located. Browse its contents

briefly.

• C:\SYSBIOSv4\Labs\DSP_BSL\ - this is the directory that contains the Board

Support Library (BSL) libraries and source code for the EVM we are using. This code
was developed by Logic PD. Also notice there the directories \gel and \DSP eXp
Audio test. Open the \gel directory – there, you’ll find the GEL script we will use
in all of the labs. Open \DSP eXp Audio test – this directory contains example
files for the OMAP-L138 EVM. In fact, we will be using the test_audio example later on
which is located in the \experimenter directory.

• C:\TI\– contains other software components such as Codec Engine, xDAIS and PSP
drivers. We will refer to these later on in the workshop.

This little exercise will help you navigate your way around as we progress through the labs in
the workshop.

2 - 16 C6000 Embedded Design Workshop Using BIOS - Code Composer Studio v5

 Lab 2 – CCSv5 Projects

Create a New Project

2. Launch CCSv5.
Launch CCSv5 by double-clicking on the desktop icon:
If this is the “first time” it has been launched, simply click the “Start Using CCS” icon in the
upper right-hand corner. Otherwise, the C/C++ perspective opens and you’re ready to go.
3. Create a new project.
Select:
File → New → CCS Project

You will then see a window as follows (do NOT click Finish until told to do so):

Name your project “hello_world” and UNCHECK the “Use default location” checkbox. Then
browse to the path shown to locate your project SPECIFICALLY in this folder. Choose all
other settings as shown (Empty Project, no main.c) but DO NOT CLICK FINISH YET !!

C6000 Embedded Design Workshop Using BIOS - Code Composer Studio v5 2 - 17

Lab 2 – CCSv5 Projects

4. Check “Advanced settings”.

Even though this dialogue is HIDDEN and called “Advanced”, it is CRITICAL to check this
to make sure you are creating a project with the right tools, endianness and output format.
Maybe it chose the right defaults…maybe not.
Click on Advanced Settings and make sure they match the settings below (note: you may
have a compiler version that is newer than the one shown – choose the NEWEST compiler if
given a choice):

Click Finish.
5. Edit Perspective.
Please note (at the moment), you are already experiencing a “different perspective”. Look up
in the right-hand corner to see the two default perspectives:

Note that “CCS Edit” is highlighted. We are editing files and working with projects (build
kind of stuff). The windows and views you see in this perspective are “default” and can be
changed to your liking later.
6. Check the Includes Directory.
Well, you’ve done it. You’ve created (maybe) your first CCSv5 project. Congrats. Let’s go
see what it looks like.

Click on the + next to Includes. Notice that CCS automagically included all of the compiler
header files. If you click the + next to this directory of header files, you’ll see the vast sea of
standard TI compiler header files.

2 - 18 C6000 Embedded Design Workshop Using BIOS - Code Composer Studio v5

 Lab 2 – CCSv5 Projects

7. Peruse files created in your \Project Directory.

What you see in the project view in CCS (for the most part) directly reflects what Windows
Explorer View will look like. When a project is created, CCS will create a set of files that
contain your project settings.
Using Windows Explorer, browse the contents of:
C:\SYSBIOSv4\Labs\Lab2A\Project

You should see something like this:

These are the “barebones” files you need to describe your project. Later, when we add
SYS/BIOS to our project, CCS will create another directory called “.config”. These files
together form an “Eclipse” project along with our source files. As we add files to our project,
we will watch the Windows Explorer view reflect our movements.

C6000 Embedded Design Workshop Using BIOS - Code Composer Studio v5 2 - 19

Lab 2 – CCSv5 Projects

Create hello_world main().

8. Create hello_world.c.
Select: File → New → Source File

When the next window pops up, type “hello_world.c” in as the filename:

Notice the inclusion of this source file in the project view. I wonder if this source file now
exists in our \Project directory in Windows Explorer – well, GO SEE. Aha. It does.

9. Write the code for hello_world.c

Ok, you C gurus could probably type this code in 5.5ms. However, for us slow people (like
the author), we like “shortcuts”.
At the first line in your source file, type “h” and then CTRL-SPACE. CCS gives you some
options for some “already written” standard code. Beautiful. (Note: your file name must be a
C source file “.c” to get this behavior).

Double-click the third option because we’re not using DSP/BIOS 6 (which is actually
SYS/BIOS and therefore poorly named) at the moment.
As a Batman cartoon would say “KA-BLAAMMMMM !!!!”
How’s that for speed…?? Now, if only you were paid well for creating complex code like
this, you could tell your boss it will take a week, hit CTRL-SPACE, make the Batman noise
and then go play golf or poker with your friends…
Save your new source file.

2 - 20 C6000 Embedded Design Workshop Using BIOS - Code Composer Studio v5

 Lab 2 – CCSv5 Projects

Add a Linker Command File

10. Add linker.cmd to your project.
As noted in the discussion material, all projects need a linker.cmd file so that the linker
knows WHERE to place your code sections in memory.
Right-click on your project and select “Add Files…”:

Reminder – any starter files that are needed for a lab will be located in the \Labx\Files
directory. In this case, browse to \Labs\Lab2A\Files and select the linker command
file: linker_dsp.cmd.
Note: this file will be slightly different than what was shown in the slides.
When the dialogue appears with the choice of “copy” or “link” – select “copy”.

Hint: Whenever you ADD a file to your project, you will have a choice to “copy” or
“link/reference” the file. If you choose “copy”, CCS will COPY that file from its original
location to the location of the project. Due to this, any EDITs to this file will be done on a
local copy versus the original file. In the next lab, we will LINK a file to our project in
which case a “pointer” to that file will be used. Any edits to a LINKED file actually
occur to the original file.

C6000 Embedded Design Workshop Using BIOS - Code Composer Studio v5 2 - 21

Lab 2 – CCSv5 Projects

Create a New Target Configuration File (.ccxml)

11. Create a new target config file for this processor/EVM.
Do you remember the old “CCS Setup” from CCS v3.3? If you do, then this will seem
familiar. If you don’t then as my 15-yr old would say…”whatever!”.
There are actually two ways to add a target config file to your project. The first and most
“direct” way is to create a new one and ADD it to your project. The second way is to add a
User Defined target config that can be selected as the “default” target config anytime you
wish. In this way, you could hook up a different board/processor, select a different config as
“default” and you’re ready to go. This is the method we will use in this workshop.
Select: View → Target Configurations

Right-click on the “User Defined” directory and choose “New Target Configuration”.

The following dialogue box will appear. Check the “Use shared location” box if it is not
already checked:

Note: FYI – the following setup instructions work for either the C6748 SOM or the OMAP-
L138 SOM – we are ONLY using the C6748 DSP in this workshop (no ARM code
development). The GEL file we plan to use configures both the ARM and DSP, wakes up
the DSP and loads the code to the DSP (basically the ARM9 is ignored in either case).

Name your new target config file: XDS510_TTO_STUDENT.ccxml

and click Finish.

When you are ready to proceed, follow the directions for the emulator used in this workshop
– XDS510.

2 - 22 C6000 Embedded Design Workshop Using BIOS - Code Composer Studio v5

 Lab 2 – CCSv5 Projects

FOR SPECTRUM DIGITAL XDS510 USB USERS ONLY

After clicking “Finish”, the following window will pop up. Notice at the bottom there are
three tabs – two of which are useful to us now – Basic and Advanced. We’ll deal with the
Basic tab first.

Choose the “Connection” and “Device” as shown below:

C6000 Embedded Design Workshop Using BIOS - Code Composer Studio v5 2 - 23

Lab 2 – CCSv5 Projects

When finished providing a name and connection type, click on the Advanced tab. For those of
you who are familiar with the old CCS Setup, the left side of the window should look
familiar.

Click on the “Plug” that says “C674x_0” which signifies the CPU layer. On the right-hand
side of the window, you’ll see the following screen.

THIS is where you specify the GEL script that CCS runs each time you “Connect to Target”.
Of course, this is in a very NON-intuitive place.

Hint: If you are able to select a BOARD in the target configuration file – vs. a DEVICE – it
will most likely come with a GEL file for the entire BOARD and be auto-loaded by CCS
correctly (i.e. without you even knowing it happens). However, when you choose a
DEVICE (like we did), no GEL is specified automatically and will most likely cause
memory read/write errors as you continue development. Word to the wise…

Browse to:
C:\SYSBIOSv4\Labs\DSP_BSL\gel\OMAPL138_EVM_TTO.gel. When you
find this file and your target config file is done – ASK THE INSTRUCTOR TO
CHECK YOUR WORK before saving….

Hint: This GEL file has been updated by TI and recently released by Logic PD. Logic PD’s
default GEL file is not stable – it tends to get hung up in the DDR init code. TI came with
a new one that LogicPD released with a “_TI” suffix. This same GEL file is used in this
workshop with the addition of the _TTO on the name.

2 - 24 C6000 Embedded Design Workshop Using BIOS - Code Composer Studio v5

 Lab 2 – CCSv5 Projects

12. Instructor check – then save your file and set as default.
Ask the instructor to check your target config file first. If it is not correct now, problems will
occur later. If the instructor approves your target config file, click the “Save” button.
To locate your new target config file, select:
View  Target Configurations
Then, click on the + sign next to the User-Defined folder. You will see others listed there that
the workshop author created for the workshop.
Right-click on this new file (your student target config file) and make sure “Set as Default”
is selected (the default ccxml file will be in BOLD letters).
Now imagine, for a moment, that you had two development boards or two processors on one
board that could be used as “targets”. All you simply have to do within CCS is view the target
configs, set the proper one as default, rebuild/load/run – oh, and connect the right board, of
course.

Analyze the Linker Command File

13. Open linker_dsp.cmd for editing.
Based upon the discussion material, this file should look somewhat familiar.
Which address will the first line of code in your program reside at? 0x_________________
Notice that ALL sections (for simplicity) are linked into to shared_ram (L3 on the
C6748). In future labs, we will change the allocations of these sections to locate in other
memory areas.
What is the extension of the filename that will show you the RESULTS of the linking process?
._______
Notice the allocations of –heap and –stack. You will almost ALWAYS have a heap and a
stack in your application. In fact, for this program, printf() requires a stack to be
allocated to contain the formatting information of the printf().

Build, Load & Run.

Goodness, finally we get to run the simple program. Lots of work up to this point, but if
you’re new to CCSv5, you’ll appreciate the slower, detailed approach. In future labs, it will
be assumed that you remember most of these steps and be able to peform these actions
relatively quickly.
14. Build hello_world.
Ok – options. First is the build configuration. Notice the word “[Active – Debug]” next to
your project name:

Active means that this project is the Active project. Doesn’t mean much for now because this
is likely the only project in your project view. As we build up more labs, however, ALL of
the projects listed in your workspace will show up in your project directory. Debug means
that the Debug build configuration is being used – i.e. no optimizations are turned on and
symbolic debug IS turned on.

C6000 Embedded Design Workshop Using BIOS - Code Composer Studio v5 2 - 25

Lab 2 – CCSv5 Projects

Right-click on the project and select “Build Configurations → Set Active”:

Click on “Release” and see “Debug” changed to “Release” in the project. This is how you
change build configurations (set of build options) when you build your code.

Hint: Build Configurations not only contain standard build options like levels of optimization
and debug symbols, but also contain specifc “file search paths” for libraries (-l) and
“include search paths” (-i) for include directories. If you specify these paths in a Debug
configuration and you switch to Release, those paths do NOT copy over to the next
configuration. Why? Because often you have a “debug” or “instrumented” library you are
using during initial debug and a completely different “optimized” library when
attempting to optimize your code.

Change the build configuration back to Debug.

Near the top left-hand corner of CCS, you will see the build HAMMER:

If you simply click the hammer, it will build whichever configuration is set as the default
(either Debug or Release).It will always do an INCREMENTAL build – i.e. build only those
files that have changed since the last build (it is much faster this way). Building “clean” will
be discussed later.
If you want to build a different configuration (e.g. release), simply click the down arrow and
choose Release. This will switch the configuration to Release AND BUILD THE PROJECT
with these settings. We will try this later, but for now, let’s stick with the Debug
Configuration.
Click the HAMMER and build the Debug Configuration. and watch the progress in the
console window. If you get any errors, go fix them. If not, you can move on…

2 - 26 C6000 Embedded Design Workshop Using BIOS - Code Composer Studio v5

 Lab 2 – CCSv5 Projects

15. Run the application.

Where is the “Run” button or “Play” button? Hmm. Doesn’t look like it exists. Well, maybe
we need to change our “perspective” and see what happens. You could simply click the
“Debug” perspective in the upper right-hand corner. However, the debugger is NOT running
and your code is NOT loaded yet and you’re NOT connected to the target.
The first time you want to debug a project, you have to go through a 3-step process. Perform
this now:
a. Right-click on your target configuration file and select “Launch…” This will
automatically change the perspective to “Debug”.
b. Click on the “Connect” button (or use Run → Connect Target):

c. Load the newly created .OUT file. When connected, load your .out file using: Run 
Load  Load Program. When the dialogue box pops up, choose “browse project” which
will show your latest build (.out).

FYI – The next time you want to launch, you can simply click the “Bug” to launch
your debug session. You can click on the down arrow next to the bug to see your options.
Ok – what has changed? Have you noticed that your “perspective” has changed to Debug –
different windows, views, buttons, etc.? In the upper window, you see a “call stack”. This can
be handy when you set breakpoints or your code goes off into the weeds – this helps you
answer “how did we get here?”. You will also notice the “Play”, “Pause”, and “Terminate”
action buttons at the top of the screen.
In the main “source” window, you will see the following:

Notice the arrow on the left-hand side. This indicates that the processor is “at main()” and
ready to run. But wait, didn’t the processor hit reset and do a bunch of stuff already before it
got here? Yes. We’ll investigate that more later. However, for now, it is a nice convenience to
show up at main() ready to go.

C6000 Embedded Design Workshop Using BIOS - Code Composer Studio v5 2 - 27

Lab 2 – CCSv5 Projects

Near the top of the screen, locate the ACTION buttons:

I’d like you to meet “Play” – the green dude, “Pause” the yellow light, and “Terminate”, the
red “kill” or “stop completely and terminate your debug session – darn I shouldn’t have hit
that button because now it will take forever to get back to this point” button. Green and
yellow are your friends. Use the red dude with CAUTION.

Hint: Often, during the initial stages of learning a new tool, some buttons are intuitive and
some are not. The green “Play” is great. However, your mind will think “red” means stop
and you’ll forget about “yellow”. Well, “red” means close completely TERMINATE the
debug session and disconnect from the target. The next time you build code, you will
need to RE-LAUNCH the TI Debugger and RE-CONNECT to the target and RE-RUN
the GEL script. So, learn quickly to only use “Play” and “Pause” frequently and
“Terminate” only when necessary. If you’re familiar with CCSv3.3, “Pause” is the old
“Halt” button. ‘Terminate” is equivalent to shutting down CCS in v3.3.

2 - 28 C6000 Embedded Design Workshop Using BIOS - Code Composer Studio v5

 Lab 2 – CCSv5 Projects

16. Click “Play”.

Watch the console window and you’ll see “hello world” displayed. That was a TON of work
for a simple program. However, it does get easier and some of these steps will never get
repeated because you’ve done them once for the entire workshop and they will be used from
now on.
17. Edit the Debug Perspective.
Remember when we said we could CUSTOMIZE our perspectives? Well, now is our chance.
The HAMMER (build button) is not shown in the Debug perspective. You could opt to use
Project  Build Project (if you have an open Debug session), but the familiar build button
(the hammer) is not shown. Let’s change that.

In the DEBUG Perspective, select Window  Customize Perspective. Select the “Command
Groups Availability” tab and check the “Build Configuration” box as shown. This will add
the “Hammer” build button to the Debug perspective. In your personal version of CCS (at
work), you can customize either the Edit or Debug perspectives in the same way to your
liking.

18. Make a change to the code and build again.

Well, now that we are IN the Debug perspective, the debugger is running and we are
connected to the target, let’s make one small change and build again.
Change “world” to your name, e.g. “hello Jeff”. Now, click the “Build” button. Hey – now
you can just hit the build button in the DEBUG perspective because you customized it.
Otherwise, you’d have to change back to the Edit perspective to see the Build (hammer)
button. Nice, eh?
CCS will now build your code and automatically load it to the target without changing
perspectives and re-launching anything. This is equivalent to the “load program after build”
from the older CCSv3.3.
Click “Play”. See the results.

C6000 Embedded Design Workshop Using BIOS - Code Composer Studio v5 2 - 29

Lab 2 – CCSv5 Projects

19. Introduce an error in the code.

Erase the semicolon (;) at the end of the printf() statement. Build again and watch how errors
are displayed. Fix the error and change back to “hello world” inside the quotes and re-build.
Click “Play” to ensure your code now works properly.
20. Analyze the final Windows Explorer contents.
Explore your \Project folder. There, you will see the standard Eclipse “project” stuff
along with your source files. Where is the .out file? Well, because you were using the
“Debug” configuration, there is a folder named \Debug. Open this folder and inspect the
contents.
What is your .out file named? ____________.out
This is always your project name with a .out extension.
The results of the linking process are contained in the .map file. Open the .map file and
inspect it. You can see the original memory areas allocation at the top and then every section
is declared with its origin and size.
What is the size of the .text section? ____________ bytes.
You can also open the makefile in an editor to inspect its contents. This is the script that was
produced by CCS that is used to build your .out file.

That’s It. You’re Done!!

21. Terminate Debug Session.
Click the red “Terminate All” button. Then, right-click on your project and select “Close
Project”.

RAISE YOUR HAND and get the instructor’s attention when

you have completed PART A of this lab and then move on to
Part B…

2 - 30 C6000 Embedded Design Workshop Using BIOS - Code Composer Studio v5

 Lab 2 – CCSv5 Projects

Lab 2B – Test Audio – Procedure

Typically when you first acquire a new development board, you want to make sure that all the
development tools are in the right place, your IDE is working and you have some baseline code
that you can build and test with. While this is not the “ultimate” test that exposes every problem
you might have, it at least gives you a “warm fuzzy” that the major stuff is working properly.
So, in this lab, we will use the Board Support Library (BSL) test code provided by LogicPD in
one of their example directories. It is a simple audio pass-through that exercises the C6748’s
McASP and the on-board AIC3106 audio codec (ADC + DAC).
There is no “code development” required in this lab. We will simply copy their files, build a
project and run it.

File Management
1. Locate the original audio test files from Logic PD’s BSL.
The files you are about to use came directly from Logic PD’s BSL (board support library)
download. They have many test examples that you can choose from – one of which is an
“audio test” routine. You can find these files at:

You can see the linker_dsp.cmd file above. Click on the \inc and \src directories to locate
the other source files. The author has copied these exact files into the local Labs directory for
you already. Now you know where they came from.
If you browse the following folder, you can see the original contents of the BSL as it looks
when you download it:
C:\SYSBIOSv4\Labs\DSP_BSL\ORIGINAL_LOGIC_PD_FILES

2. Locate the copied files in the Labs folder.

Just to make sure the author did his job, browse the contents of the following folder:

The contents of this folder should look like the above. If not, ask your instructor for help.

C6000 Embedded Design Workshop Using BIOS - Code Composer Studio v5 2 - 31

Lab 2 – CCSv5 Projects

Create a New Project.

3. Create a new project named test_audio.
Well, here we go again. Refer back to the section in part A as a reminder – the key being that
you want your project located in the following directory:
C:\SYSBIOSv4\Labs\Lab2B\Project.
Name your project test_audio.

4. Add files to project.

Add all of the files contained in \Lab2B\Files to your project. Again, refer back to
previous steps you’ve done as a reminder.
5. Link the BSL library to our project.
This project contains a ton of API calls to the Board Support Library (BSL) and therefore we
need to add this library to our project. Remember, we have two options – COPY or
LINK/POINTER. If we ADD the library, CCS will copy the library and put it in our
\Project folder. Well, that’s a bit silly because we don’t plan to modify this file – just
simply use it. Plus, libraries can be quite large – why have two copies of the library?

Right-click on the project and choose “Add Files” and browse to:

Select the .lib file shown and when the dialogue asks you to “copy” or “link”, choose LINK.
Notice that this file has a little “arrow” indicating it is a LINKED file.

Your project should now look like this:

Pause for a moment and MAKE SURE your project looks exactly like this picture. If you’re
missing something, go back and determine what you’re missing and add it. All future steps
assume your project has the exact contents shown above.

2 - 32 C6000 Embedded Design Workshop Using BIOS - Code Composer Studio v5

 Lab 2 – CCSv5 Projects

6. Add include path to your build properties.

Every time you add a library, you need to tell the build tool WHERE the include files are
located for that library.

Right-click on your project and select “Properties”. Under the “C6000 Compiler” listing,
select “Include Options”:

We need to ADD a path to this list for the BSL library include directory.

Click the ADD (+) button:

Browse the File System and navigate to the following directory:

Click OK.

C6000 Embedded Design Workshop Using BIOS - Code Composer Studio v5 2 - 33

Lab 2 – CCSv5 Projects

You should now see your new path added to the “include” list. All of the other paths shown
may or may not have been included AUTOMATICALLY based on your configuration
settings. There is only ONE path you needed to add – the path to the \inc folder for the BSL
library.

Click OK to close the Properties window.

Note: Again – we just added a path to our Build Properties for the Debug Build Configuration.
If you were to switch to Release right now, the path you just added would disappear. So,
when switching between build configurations, BOTH need to have the proper paths set to
work properly. Just beware of this when we ask you to switch modes in the middle of a
lab and Release has errors when Debug doesn’t. Well, now you know what, most likely,
is causing the problem. You can also use “Manage” for configs to delete/copy or create a
new custom configuration.

Analyze the Test Audio Example Files

7. Analyze the contents of this example.
The purpose of this example code is to test the audio path from the CPU to the McASP (audio
serial port) to the AIC3106 (ADC/DAC). Audio is a convenient method to test setup because
you can “hear” problems if they occur.
What is required to get audio to work is first to initialize the McASP and AIC3106 and write
configuration parameters to both to indicate how you want them to behave. Once they are set
up, you can then release them to operate as intended – making noise – hopefully a
recognizable noise. We’ll see…
There are two main source files. Open each and inspect them:
• main_audio.c –The I2C peripheral is used to program the AIC3106, so it must be
configured also. The timer is used to time the output of the sine tone and the audio pass-
thru portions of the example (more later).
• test_audio.c – this is where the action takes place. Near the top of the file, some
McASP setup code is used to turn on the clocks and take the peripheral out of reset. As
soon as that is done, you see two calls to “test line out” and “test line in/out”. The first
call will send a sine tone to the headphones for 5 seconds. The second call will pass
through any audio playing into LINE IN to LINE OUT for 15 seconds.

2 - 34 C6000 Embedded Design Workshop Using BIOS - Code Composer Studio v5

 Lab 2 – CCSv5 Projects

Play the Test Audio Example

8. Build your project.
Make sure you are using the Debug configuration and click the HAMMER (build button). Fix
any errors that occur (there should be none).
9. Debug your project.
Click the BUG to launch the debug session, connect to the target and load your new program
(test_audio.out).
10. BEFORE YOU HIT RUN/PLAY…
11. Get some music playing on the PC.
Ensure that a music file is playing and is set to repeat or play forever. FYI – one common
mistake in this workshop is when a student believes that their code is not working because
they don’t hear any audio. More than half the time, the instructor walks up and says “do you
have audio playing?” The student says “oh” and moves on.  Well, they DID have music
playing, but the song ENDED and was not repeating. Beware of “air” masquerading as bad
code…
12. Play the example.
When the execution arrow reaches main(), click “Play” and watch the console messages.
You should first hear a sine tone for 5 seconds followed by audio passing through from LINE
IN to LINE OUT for 15 seconds. Then, the program shuts down. If the audio performed
properly, move on to the next step. If not, it is debug time. If you get stuck, ask your
instructor for help – or your neighbor.

C6000 Embedded Design Workshop Using BIOS - Code Composer Studio v5 2 - 35

Lab 2 – CCSv5 Projects

Basic Debugging Techniques

Let’s explore some basic debug techniques now and we’ll add many more as we perform
each lab exercise.
13. Set a breakpoint and view a local variable.
First, restart the program by selecting:
Run → Restart

You will see the execution arrow go back to main(). Try:

Run → Load → Reload Program

Open the test_audio.c file and set a breakpoint (double-click to the left of the line
number) on line 265 as shown:

Click “Play”. The breakpoint will get hit after you hear the sine tone. At this point, what if
you wanted to know the contents of the dat variable. You should be able to already see the
“Variables” tab showing near the upper right-hand part of the screen. If not, select:
View → Variables

FYI – when we BREAK the McASP (stop feeding it), it actually breaks. So, don’t expect to
run again and see what happens next. You’re dead.

Right-click on the VALUE of dat and select “Number Format”. Here, you can choose a
variety of formats to view your variables.

2 - 36 C6000 Embedded Design Workshop Using BIOS - Code Composer Studio v5

 Lab 2 – CCSv5 Projects

14. View memory.

Select:
View → Memory Browser
And type in the address 0x80000000 to locate the top of the L3_shared_RAM. We don’t
have any global variables yet, so this view is not that exciting. It will be in future labs.
15. View CPU registers.
Click on the “Registers” tab in the upper right-hand corner or select:
View → Registers

Then select “Core Registers”:

Click the + next to Core Registers. This is the entire contents of all of the CPU registers. You
can also see in the previous list all of the peripheral registers and their contents. Very handy.
16. View CCSv5 Scripts.
In the older CCSv3.3, there was a GEL menu where you could write a GEL file and load it
and it would show up under that menu. GEL scripts are simply a set of commands to help
CCS peform certain duties – like setting up the clocks, PLL, memory, etc.
In CCSv5, these are called SCRIPTS. The scripts are loaded when you pointed to the
OMAPL138_EVM_TTO.gel file way back in the last lab. To view what capabilities these
scripts offer, click on “Scripts” on the menu bar. Don’t run any of them – this is just an
awareness exercise. Also, take a moment and open this gel file in a Window’s editor and scan
the contents. Do NOT make any changes…when done…close the GEL file.
17. Conclusion
FYI – this test code from LogicPD was the seed for most of the labs we use in this workshop.
Over the next 4 days, you will become very familiar with some of the operations of this code
as we build on the McASP/AIC3106 setup and use it to perform certain tasks within the
system – all the while playing with the audio piece.

That’s It. You’re Done!!

18. Terminate your Debug Session, Close the Project and Close CCS.

You’re finished with this lab. Please let your instructor know when you have
finished this lab…

C6000 Embedded Design Workshop Using BIOS - Code Composer Studio v5 2 - 37

Additional Info & Notes

Additional Info & Notes

2 - 38 C6000 Embedded Design Workshop Using BIOS - Code Composer Studio v5

 Introduction to SYS/BIOS
Introduction
This chapter provides an introduction to the basic concepts of SYS/BIOS including thread types
and how to create a new SYS/BIOS project.
The lab at the end of this chapter challenges users to build their first complete system in
SYS/BIOS to blink an LED on the target EVM.

Objectives

Objectives

 Explore the basics features of the SYS/BIOS

Real-time Operating System (RTOS)
 Define SYS/BIOS thread types and how the
scheduler prioritizes threads in a system
 Learn how to create a new SYS/BIOS project
 Lab 3 – Create, build and debug a SYS/BIOS
application that blinks an LED

C6000 Embedded Design Workshop Using SYS/BIOS - Introduction to SYS/BIOS 3-1

Module Topics

Module Topics
Introduction to SYS/BIOS .........................................................................................................................3-1
Module Topics..........................................................................................................................................3-2
Intro to SYS/BIOS ....................................................................................................................................3-3
Overview .............................................................................................................................................3-3
DSP/BIOS vs. SYS/BIOS – Comparison...................................................................................................3-6
Threads & Scheduling..............................................................................................................................3-7
Thread Types .......................................................................................................................................3-7
Creating A BIOS Resource – Example: Hwi Object ...........................................................................3-9
System Timeline .....................................................................................................................................3-10
Real-Time Analysis Tools.......................................................................................................................3-11
SYS/BIOS Projects .................................................................................................................................3-12
Creating a New Project ......................................................................................................................3-12
BIOS Configuration (.CFG) ..............................................................................................................3-13
Platforms ...........................................................................................................................................3-16
Version Control Suggestions .............................................................................................................3-16
For More Info… .....................................................................................................................................3-17
DSP/BIOS Configuration – FYI [OPTIONAL] ......................................................................................3-20
Chapter Quiz ..........................................................................................................................................3-22
Lab 3 – SYS/BIOS Blink LED ................................................................................................................3-23
Lab 3 – Procedure .................................................................................................................................3-24
Download Latest Tools .................................................................................................................3-24
Create New blinkLed Project ........................................................................................................3-25
Add and Link Files ........................................................................................................................3-27
Explore the New CFG File ............................................................................................................3-30
Register ledToggle() as an Idle Thread Function ..........................................................................3-31
Final Modifications Before Build..................................................................................................3-33
Build, Load, Run ! .........................................................................................................................3-34
View the Platform File ..................................................................................................................3-35
ROV At A Glance .........................................................................................................................3-37
Explore SYS/BIOS folders............................................................................................................3-38
That’s It, You’re Done !!...............................................................................................................3-38
Additional Information & Notes ............................................................................................................3-39
More Notes… .........................................................................................................................................3-40

3-2 C6000 Embedded Design Workshop Using SYS/BIOS - Introduction to SYS/BIOS

 Intro to SYS/BIOS

Intro to SYS/BIOS
Overview

SYS/BIOS Overview

Input Input Input

Input Stream Input Stream Input
Input Process Output
Queue Queue
Hwi Swi, Task Hwi
“Driver” “Driver”
SYS/BIOS
Scheduler Data Sharing/Passing Synchronization Memory Mgmt

SYS/BIOS is a scalable, real-time kernel used in 1000s of systems today:

• Pre-emptive Scheduler to design system to meet real-time (including sync/priorities)
• Modular – pre-defined interface for inter-thread communications
• Reliable – 10,000s of applications have used it for more than 10 years
• Footprint – deterministic, small code size, can choose which modules you desire
• Cost – free of charge
5

C6000 Embedded Design Workshop Using SYS/BIOS - Introduction to SYS/BIOS 3-3

Intro to SYS/BIOS

3-4 C6000 Embedded Design Workshop Using SYS/BIOS - Introduction to SYS/BIOS

 Intro to SYS/BIOS

C6000 Embedded Design Workshop Using SYS/BIOS - Introduction to SYS/BIOS 3-5

DSP/BIOS vs. SYS/BIOS – Comparison

DSP/BIOS vs. SYS/BIOS – Comparison

3-6 C6000 Embedded Design Workshop Using SYS/BIOS - Introduction to SYS/BIOS

 Threads & Scheduling

Threads & Scheduling

Thread Types

SYS/BIOS Thread Types

Implements ‘urgent’ part of real-time event
Hwi 
 Hardware interrupt triggers ISRs to run
Hardware Interrupts  Priorities set by hardware

 Performs HWI ‘follow-up’ activity

Swi  ‘posted’ by software
 Periodic (Clock) functions are prioritized as SWIs
Software Interrupts Up to 32 priority levels (16 on C28x)
Priority

 Runs programs concurrently under separate contexts

Task  Usually enabled to run by posting a ‘semaphore’
(a task signaling mechanism)
Tasks
 Up to 32 priority levels (16 on C28x)

Idle 

Multiple Idle functions
Runs as an infinite loop (like traditional while(1) loop)
Background  Single priority level

14

C6000 Embedded Design Workshop Using SYS/BIOS - Introduction to SYS/BIOS 3-7

Threads & Scheduling

3-8 C6000 Embedded Design Workshop Using SYS/BIOS - Introduction to SYS/BIOS

 Threads & Scheduling

Creating A BIOS Resource – Example: Hwi Object

C6000 Embedded Design Workshop Using SYS/BIOS - Introduction to SYS/BIOS 3-9

System Timeline

System Timeline

3 - 10 C6000 Embedded Design Workshop Using SYS/BIOS - Introduction to SYS/BIOS

 Real-Time Analysis Tools

Real-Time Analysis Tools

C6000 Embedded Design Workshop Using SYS/BIOS - Introduction to SYS/BIOS 3 - 11

SYS/BIOS Projects

SYS/BIOS Projects
Creating a New Project

3 - 12 C6000 Embedded Design Workshop Using SYS/BIOS - Introduction to SYS/BIOS

 SYS/BIOS Projects

BIOS Configuration (.CFG)

C6000 Embedded Design Workshop Using SYS/BIOS - Introduction to SYS/BIOS 3 - 13

SYS/BIOS Projects

3 - 14 C6000 Embedded Design Workshop Using SYS/BIOS - Introduction to SYS/BIOS

 SYS/BIOS Projects

BIOS System Overview

 To see the services

used in YOUR
.cfg file, choose:
 BIOS  System O/V
 Notice the green
checkmarks ()

How is the cfg

file used in the
build process?

33

C6000 Embedded Design Workshop Using SYS/BIOS - Introduction to SYS/BIOS 3 - 15

SYS/BIOS Projects

Platforms

Version Control Suggestions

3 - 16 C6000 Embedded Design Workshop Using SYS/BIOS - Introduction to SYS/BIOS

 For More Info…

For More Info…

C6000 Embedded Design Workshop Using SYS/BIOS - Introduction to SYS/BIOS 3 - 17

For More Info…

3 - 18 C6000 Embedded Design Workshop Using SYS/BIOS - Introduction to SYS/BIOS

 For More Info…

C6000 Embedded Design Workshop Using SYS/BIOS - Introduction to SYS/BIOS 3 - 19

DSP/BIOS Configuration – FYI [OPTIONAL]

DSP/BIOS Configuration – FYI [OPTIONAL]

3 - 20 C6000 Embedded Design Workshop Using SYS/BIOS - Introduction to SYS/BIOS

 DSP/BIOS Configuration – FYI [OPTIONAL]

C6000 Embedded Design Workshop Using SYS/BIOS - Introduction to SYS/BIOS 3 - 21

Chapter Quiz

Chapter Quiz

Chapter Quiz
1. What is the main purpose and benefit of using an RTOS?

2. What is the difference between a function and a thread?

3. Name the 4 thread types in BIOS in priority order (hi to low):

4. What does a .cfg file contain and how do you add services to it?

5. What types of instrumentation do the RTA tools provide visibility to?

6. What does a platform file specify and why is it needed?

3 - 22 C6000 Embedded Design Workshop Using SYS/BIOS - Introduction to SYS/BIOS

 Lab 3 – SYS/BIOS Blink LED

Lab 3 – SYS/BIOS Blink LED

In this lab, you will create a new SYS/BIOS project from scratch and extend your CCSv5 skills as
well as dive into configuring a SYS/BIOS project.
This project uses the Logic PD BSL function LED_toggle() to blink the LED on the EVM. This
function will be called during the BIOS Idle thread. After main() calls BIOS_start(), there are no
other threads active in the system other than Idle. So, this function will run continuously – well,
as long as BIOS is running properly, that is. 

C6000 Embedded Design Workshop Using SYS/BIOS - Introduction to SYS/BIOS 3 - 23

Lab 3 – Procedure

Lab 3 – Procedure
Typically when you first acquire a new development board, you want to make sure that all the
development tools are in the right place, your IDE is working and you have some baseline code
that you can build and test with. While this is not the “ultimate” test that exposes every problem
you might have, it at least gives you a “warm fuzzy” that the major stuff is working properly.
So, in this lab, we will use a few Board Support Library (BSL) functions provided by LogicPD to
blink an LED on the EVM. While this is not “killer code”, it will allow us to explore some basic
concepts in using SYS/BIOS.

Download Latest Tools

1. Download latest IPC, XDC, BIOS releases from the target content page.
THIS STEP HAS ALREADY BEEN DONE BY THE AUTHOR.
The current workshop may use the tools delivered with the current CCSv5 release or not.
Often, the latest BIOS, XDC, IPC tools are released before they are integrated into the IDE
release. If you always want to be using “the latest”, you can access the link below to
download the latest releases.
http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/
A screen cap of the page is here:

After downloading these tools, you must then close CCS and re-launch it. If you place these
tools in CCS install dir (as they are in this workshop), CCS will recognize them and ask you
to “enable them” when you re-launch CCS. Then, they will show up in the RTSC
configuration box later on and you can choose the latest tools.

3 - 24 C6000 Embedded Design Workshop Using SYS/BIOS - Introduction to SYS/BIOS

 Lab 3 – Procedure

Create New blinkLed Project

2. Create a new CCS Project.
Go through the steps of creating a new CCS project as you have done before noting the
following:
• Name: sysbios_blinkLed

• Location: C:\SYSBIOSv4\Lab3\Project

When you get to the Project Settings tab, make sure the appropriate selections are there – as
shown:

3. Select the “Typical” SYS/BIOS project template.

In the window below, select the SYS/BIOS “Typical” project template (DO NOT CLICK
NEXT YET):

As you can see, you have several options. “Minimal” would work just fine in our case
because we end up adding what we need to get the project to work. However, the “dummy
mode” choice (safest one) is “Typical” which is a great starting point for any project and you
can add/delete items from there.

Choose the “Typical” CFG file as shown above. This choice gives you two items – a main.c
with the proper header files (.h) added and a starter .CFG file.

C6000 Embedded Design Workshop Using SYS/BIOS - Introduction to SYS/BIOS 3 - 25

Lab 3 – Procedure

4. Check Advanced Settings.

Click on “Advanced Settings” to make sure they are correct (choose the compiler version
shown or higher):

NOW click “Next”…

5. Select the necessary BIOS Packages.
PLEASE READ CAREFULLY. There may be more than one version of each of these 3 tools
on your student machine. The latest versions are shown on TOP of the older versions (as you
can see in the graphic below).
Regardless of what the screen capture shows below, CHOOSE THE LATEST TOOLS of
each one.
It is EASY to miss the XDCTools near the top of the screen. Please make sure you choose the
LATEST XDC Tools by clicking on the down arrow and choosing the LATEST version (the
one that is listed at the TOP of the choices). Then select the latest BIOS version.

Then, make sure you select the proper platform: evm6748 and the release build profile.

When finished, uh..click…uh…FINISH !

3 - 26 C6000 Embedded Design Workshop Using SYS/BIOS - Introduction to SYS/BIOS

 Lab 3 – Procedure

6. Peruse your new project.

Let’s look at each item in the list:

• main.c – this is a generic main.c file that contains a “shell” for you to use in your own
project. The key items are the include statements at the top. For each BIOS MODULE
(Task, Swi, Hwi, Idle, etc), you must include the corresponding header file. More on this
later…
• app.cfg – this is our starter CFG file. We will modify this file as we move through the
lab.

Add and Link Files

7. Delete main.c from your project.
We will add our own main.c file in the next step, so we don’t need the default one. Right-
click on this file and select Delete.
8. Add files to your project.
In the \SYSBIOS\LAB3\Files folder, there are 3 files we need to add. Right-click on the
project and add these files:
• main.h
• main.c
• led.c

Let’s take a look at each one of these files separately:

• main.h – contains #includes for header files necessary for SYS/BIOS, statically
configured objects and some of the main SYS/BIOS modules (like Tasks and
Semaphores). We will add to these as necessary throughout the lab.
• main.c – initializes the I2C comm channel on the EVM as well as the LEDs.
• led.c – contains the function ledToggle() that toggles and LED every half second.
This function will be called during the Idle thread in SYS/BIOS. In a future step, you
will need to register this function as an Idle function for this to work properly.

C6000 Embedded Design Workshop Using SYS/BIOS - Introduction to SYS/BIOS 3 - 27

Lab 3 – Procedure

9. Inspect \Project folder.

Open Windows Explorer and view the contents of the \Project folder for Lab3. Notice
that the source files were COPIED from the \Files folder to the \Project folder when
you ADDED them to your project.
The other way to accomplish this is to simply copy the source files into the \Project
directory and they will show up in your project. The point here is that your project view in
CCS mirrors the Windows Explorer folder contents.
10. Link BSL library to the project.
Usually, libraries are LINKED to the project instead of copied into the \Project folder.
Why? Two reasons:
• they can be rather large – so why have two copies
• libraries are not typically modified, only referenced. Therefore, we want to provide a
POINTER to the library.

Right-click on the project and LINK the following library to your project:

This is Logic PD’s board support library (BSL) that contains functions we need to access to
initialize the I2C communications channel and toggle the LED on the EVM board.

3 - 28 C6000 Embedded Design Workshop Using SYS/BIOS - Introduction to SYS/BIOS

 Lab 3 – Procedure

11. Add include search path for BSL library.

Every time you add a library, you need to tell the build tool WHERE the include file is
located for that library.
Right-click on your project and select “Properties”. Under the “C6000 Compiler” heading,
clock on “Include Options”:

Then click on the “+” sign to add the other path indicated to the BSL \inc folder as you did in
the previous lab:
C:\SYSBIOSv4\Labs\DSP_BSL\bsl\inc

Click OK. Notice that this path is now added to the include search path.

Click OK again.

12. Double-check the project contents.

Look at your project view and make sure it matches the picture below. We are simply making
sure all of the proper files are added or linked at this point:

C6000 Embedded Design Workshop Using SYS/BIOS - Introduction to SYS/BIOS 3 - 29

Lab 3 – Procedure

Explore the New CFG File

13. Explore the new CFG file (but make no changes yet).
Double-click on the .cfg file in your project. It should open 3 key windows:
• Available Products (lower left-hand corner of the screen)
• Outline View (upper right-hand corner)
• Dialogue for highlighted module in the Outline view (in the center, not shown below)

You are looking at the XDC Tools GUI (called XGCONF) which allows users to create BIOS
objects statically. The available products window reflects the checkboxes you checked when
you created the project. The outline view shows currently configured static objects.
We will use both of these dialogues to configure SYS/BIOS throughout all of the labs.

14. Explore the .cfg source code script.

Near the bottom of the middle screen, click on the Source tab:

This will enable you to see the source script – the actual contents of the .CFG file. If you
click on a BIOS module in the outline view (on the right), e.g. Clock, it will show you the
exact script that was used to create that configuration. Feel free to click around some, but
don’t change anything. More on this later…

3 - 30 C6000 Embedded Design Workshop Using SYS/BIOS - Introduction to SYS/BIOS

 Lab 3 – Procedure

Register ledToggle() as an Idle Thread Function

15. Add Idle object to CFG file.
Configuring static BIOS objects is a 4-step process:
a) Indicate you want to USE a module (e.g. Semaphore)

b) Create an INSTANCE of that module (e.g. add a new Semaphore)

c) Configure that instance (e.g. name of Semaphore and starting count value)

d) Include a proper header file to your code (e.g. main.h) for Semaphores
In our case, we want to USE the Idle Module and then configure it to call our
ledToggle() function when it reaches the Idle thread. Because we are STATICALLY
configuring our objects for now, we’ll use the available GUI vs. creating it dynamically.
First, under the heading Scheduling in the Available Products window, right-click on Idle and
select “Use Idle”.

The Idle module will now show up in the outline view (on the right). Click on the Source tab
to see the script that was added to the .CFG file for Idle. Cool. Now it’s time to configure the
Idle thread…
16. Configure Idle thread to call ledToggle().
Click on the Idle tab next to Source. This should bring up the configuration box for the Idle
module. All we have to do is type in the name of the function(s) we want to run during the
Idle thread.
Type in the ledToggle function name into the first slot:

If you have 3 Idle functions and you want them to run in order, place them here in the order
you want them to run. They will then run in a round-robin fashion. If you want to
GUARANTEE the order, then use one Idle function that calls the three functions in order.
Save the CFG file. If you’re curious, you can select the Source tab again and see this function
added to the script near the bottom.

C6000 Embedded Design Workshop Using SYS/BIOS - Introduction to SYS/BIOS 3 - 31

Lab 3 – Procedure

17. Do we need to add a header file for the Idle module?

That is a very good question. For BIOS5 users, the tools created a cfg.h file that was added
to the project automatically. This was created from the old .TCF file for statically defined
objects.
The same is true in SYS/BIOS. For all statically declared objects (like Idle in this case), the
following header file in main.h takes care of this for us:
#include <xdc/cfg/global.h>

If you DYNAMICALLY create a BIOS object in your code, you would then need to
explicitly add the header file for that module to main.h. In that case, we would add:
#include <ti/sysbios/knl/Idle.h>

Inspect main.h and make sure <xdc/cfg/global.h> is included there.

For xdc.runtime modules, like Timestamp, an explicit header file is required. So, for this
workshop, we simply add all of the header files in main.h to cover us for both static,
dynamic and runtime cases.

Getting started with SYS/BIOS can be a challenging proposition at times. Without some
decent labs/material to guide you through this, it is sometimes frustrating to put all the pieces
together in a timely manner. But hey, you’re here – and reading this, so you’re the
beneficiary. Trust the author when he says these can be huge stumbling blocks if you didn’t
have someone to walk you through the basics the first time…

3 - 32 C6000 Embedded Design Workshop Using SYS/BIOS - Introduction to SYS/BIOS

 Lab 3 – Procedure

Final Modifications Before Build

18. Use Timestamp module.
Inspect main.c. Near the bottom of main.c is a function USTIMER_delay() that
creates a millisecond delay. This function is used to create the delay in ledToggle().
Timestamp is a BIOS module that must be added to our configuration before we build our
application.
In the Available Products, under SYS/BIOS: Diagnostics, right-click on Timestamp and
choose Use Timestamp (app.cfg must be the “active” file to see this):

Timestamp should show up in the Outline view. Save your .CFG file.
19. Explore SYS/BIOS System Configuration
The “global” configuration for SYS/BIOS is located in the BIOS module in the outline view.
Click the app.cfg tab to make sure you are viewing this file.
Click the “BIOS” module in the outline view and you’ll see a configuration box which has
the following buttons on top:

The Welcome screen has some text that is interesting and the System Overview has a pretty
diagram. Click on System Overview and notice the green checkmarks – they should match the
BIOS services you have added to your .cfg file.
Now click on the Runtime button. This is where you can modify the global settings for
SYS/BIOS, namely:
• SYS/BIOS library type – instrumented is used during your application’s debug phase and
therefore is the default setting. For production, you may select the non-instrumented
version of the library. The other two are not really used.
• Threading Options – make sure each of these are checked. If not, stuff might not work!
• Runtime Memory Options – the default is dynamic creation/deletion. This covers
STATIC also. This is the proper all-encompassing setting.
• Heap Settings – SYS/BIOS requires a heap. This is where the size is defined.
• Stack Settings – Whoops, where are those? Click on Program in Outline view.

C6000 Embedded Design Workshop Using SYS/BIOS - Introduction to SYS/BIOS 3 - 33

Lab 3 – Procedure

Build, Load, Run !

20. Build, load and run your code (do each sub-step as you read this page).

Your code will most likely NOT run properly – the rest of this page helps you find your error.

Use the Debug build configuration and click Build. If your code builds with errors, fix them.
If your build is successful, let’s open a new debug session.
In the previous lab, you used the 3-step process: launch, connect, load. Just follow this
process again to load your program (don’t forget to “browse project”).
The second time you build (with an open debug session), CCS will auto load the new .out
file.
If you terminate the debug session after launching a program at least ONCE, then you can
simply hit the “bug” below and it will do all 3 steps for you.

After the GEL file runs and program loads, click Run (Play).

Did it work? Is the LED blinking? If so, you can move on to the next part. If not, please
read on – you probably made a common mistake…

Who calls the ledToggle function? ____________________________________

When is the Idle thread executed? _________________________________

Who calls the Idle thread? _________________________

When does the scheduler start? _________________________

Did you call that API to start the scheduler?

If you didn’t already find the API and put it in main(), add the proper function call to start the
scheduler to the end of main() and build/run again. At this point, the LED should blink.
Ok, so this might have been a MEAN thing to do…but sometimes it is the simplest things
like this that can cause you hours of debug, frustration and forum msgs to TI only to find out
“golly, Sarge, I forgot to start the doggone scheduler!” Ok, Gomer…

3 - 34 C6000 Embedded Design Workshop Using SYS/BIOS - Introduction to SYS/BIOS

 Lab 3 – Procedure

View the Platform File

21. View the RTSC platform file.
So, what memory map settings have you been using all this time? Did you care? Where was
this stuff defined?
In the platform file. But you didn’t create a platform file, did you? No. But you specified the
platform file during the creation of this project. How do you view which platform is being
used? In a secret, non-intuitive place, of course.
Actually, that is what the author thought when he first tried using SYS/BIOS. It is NOT
intuitive to find. Again, there are actually multiple ways to open the platform file. The easiest
is as follows: Tools  RTSC Tools…

The following dialogue box will appear:

Ok, now the trouble begins. If you did NOT know how this new SYS/BIOS stuff was
packaged up and this dialogue is asking you for the repository for where these platforms are
stored, you’d go nuts. How would YOU know? That’s what the E2E forum is for. 

Ok, so you’re running this lab and here’s your answer. The platforms are stored in the XDC
Tools path (use latest tools path) (as shown) under \packages. Intuitive right? Wrong.
Your path will be different. It will have “_v5” without the “.1.0” and also point to the
LATEST XDC Tools version. FYI.

Browse to that directory and then select the evm6748 platform as shown. Click Ok.

C6000 Embedded Design Workshop Using SYS/BIOS - Introduction to SYS/BIOS 3 - 35

Lab 3 – Procedure

The following screen then appears with all of the settings.

DO NOT MODIFY THE CONTENTS OF THIS FILE. You are viewing/editing the EVM’s
Platform file that ships with the XDC tools. If you want to play around and edit later, you can
create your own platform and import the EVM’s Platform file and THEN mess it up. For
now, just look around.
If you check the “Customize Memory” box shown below, you can then edit the fields – but
do NOT edit them.
So, now you know where the memory settings are…

So, for this target (evm6748), it looks like the DEFAULT platform file allocates all code,
data and stack into external DDR memory. Ok. We’ll change some of this later.

3 - 36 C6000 Embedded Design Workshop Using SYS/BIOS - Introduction to SYS/BIOS

 Lab 3 – Procedure

ROV At A Glance
22. Inspect the contents of the ROV tool.
As stated in the discussion material, the Run-time Object Viewer (ROV) provides great
information about the state of the scheduler, BIOS threads and memory objects. We will dive
deeper into the contents of ROV in a later chapter, but wanted to open it in this lab and just
browse its contents.

First make sure your program is halted. On the menu, select:

Tools  ROV

You will see a list of modules on the left and if you click on a module, you can see the status
of each along with different tabbed views. The following “headings” like “ROV-BIOS”
indicate the module to click on in the ROV to find the answers. Also, some questions are not
easy – but will allow you to EXPLORE ROV to hopefully find the answers.

Let’s look at (click on) a few in particular and answer some questions:

ROV-BIOS
Are clocks, Swis and Tasks enabled? Yes No
What is the frequency this processor is running at ? _______MHz

ROV-HeapMem (Detailed tab)

What is the total size of the heap? 0x_______ free size available? 0x_______
What is the starting address of the heap? 0x________ Is that in DDR? Yes No

Not found in ROV:

Which configuration (.cfg file) option specified the size of the heap? ____________________
Which file allocated the heap in DDR? _________________

ROV-Hwi (Module tab)

What is the current size of the stack? _______ What was the peak used? _______

ROV-Idle
How many Idle functions are there? 0 1 2

C6000 Embedded Design Workshop Using SYS/BIOS - Introduction to SYS/BIOS 3 - 37

Lab 3 – Procedure

Explore SYS/BIOS folders.

23. Take a train ride through the SYS/BIOS trees…
The tools are loaded, by default (when you download CCS) into the following directory:
\install_Dir\ccsv5\...
Locate C:\CCStudio_v5\ccsv5\. Notice the folders for bios_6, ipc and xdctools. We
will explore each one to locate some important pieces. NOTE: The paths below reflect older
versions of a BIOS installation – simply use the LATEST one installed on your machine.

Where are the BIOS benchmarks located? These will tell us how long each API takes to run
on our system – i.e. the SYS/BIOS overhead.
C:\CCStudio_v5\bios_6_32_05_54\docs\cdoc\ti\sysbios\benchmarks\doc-files

What is the interrupt latency for the ARM Cortex-M3 in cycles? ________
(Hint, click on Results.html)

How many bytes does the bare bones SYS/BIOS kernel require (code)? ________bytes
(Hint, use Sizes_M3.html)

Where are the SYS/BIOS examples located?

C:\CCStudio_v5\bios_6_32_05_54\packages\ti\sysbios\examples\generic
Click on the hello example and then open hello.c and hello.cfg. Inspect their contents. Look
familiar?

Hey, TI said they shipped SOURCE CODE with SYS/BIOS. Prove it. In fact, I’d like to see
the source code for a Swi_post() – I’m wondering if they disable interrupts – if that call is
“thread safe” or “atomic”. Ok…locate:
C:\CCStudio_v5\bios_6_32_05_54\packages\ti\sysbios\knl
See all the header and source files there? Ok. Open Swi.c and browse down to about line 582.
Do you see an API called Hwi_disable() near the top? Yes No

Lastly, where are those platform files (or packages) stored? Browse to:
C:\CCStudio_v5\xdctools_3_22_04_46\packages\ti\platforms\evm6748

This is the actual package we are using in the labs. The XDC tools understand how to
consume this library and metadata.

That’s It, You’re Done !!

24. Terminate your Debug Session and close CCS.

You’re finished with this lab. Please raise your hand and let the instructor
know you are finished with this lab.

3 - 38 C6000 Embedded Design Workshop Using SYS/BIOS - Introduction to SYS/BIOS

 Additional Information & Notes

Additional Information & Notes

Boot Sequence

Described in detail in the

User’s Guide and the
Stellaris/BIOS wiki page

55

C6000 Embedded Design Workshop Using SYS/BIOS - Introduction to SYS/BIOS 3 - 39

More Notes…

More Notes…

3 - 40 C6000 Embedded Design Workshop Using SYS/BIOS - Introduction to SYS/BIOS

 C6000 Hardware Interrupts (Hwi)
Introduction
Hardware Interrupts or “Hwi” are the most basic thread type managed by the BIOS scheduler.
Hwi are similar to conventional ISRs (interrupt service routines), except that BIOS permits the
Hwi to enjoy additional features and improved ease of use. Hwi are present in almost all BIOS
based systems, and are a likely mainstay of small project or those requiring low input-to-output
latency.

Objectives

Objectives

 Briefly describe how a peripheral (McASP)

works and how it generates an event (HWI)
 Describe how hardware interrupts (Hwi’s)
work on a C64x+ architecture
 Demonstrate how to create an Hwi via
CCS’s config tool
 Lab4 – Use an Hwi to respond to McASP
interrupts

C6000 Embedded Design Workshop Using BIOS - C6000 Hardware Interrupts (Hwi) 4-1
Module Topics

Module Topics
C6000 Hardware Interrupts (Hwi) ...........................................................................................................4-1
Module Topics..........................................................................................................................................4-2
System Concepts.......................................................................................................................................4-3
Remember Lab2B ? .............................................................................................................................4-3
McASP Overview ................................................................................................................................4-4
IDL Thread ..............................................................................................................................................4-5
Concepts ..............................................................................................................................................4-5
C64x+ Interrupts .....................................................................................................................................4-6
Interrupts – How they Work… ............................................................................................................4-6
HWI – Creation ...................................................................................................................................4-7
Reminder – Can Create via Static, Dynamic, CFG .............................................................................4-8
HWI – Interrupt Sources......................................................................................................................4-8
HWI – Example ISR ............................................................................................................................4-9
Interrupt Pre-emption ........................................................................................................................4-10
Event Combiner .................................................................................................................................4-10
Creating Custom Platforms ...................................................................................................................4-11
Chapter Quiz ..........................................................................................................................................4-13
Using Double Buffers .............................................................................................................................4-14
Lab 4: An Hwi-Based Audio System ......................................................................................................4-15
Lab 4 – Procedure ..............................................................................................................................4-16
Import Existing Project .................................................................................................................4-16
Application (Audio Pass-Thru) Overview.....................................................................................4-17
Source Code Overview..................................................................................................................4-17
More Detailed Code Analysis .......................................................................................................4-18
Creating A Custom Platform .........................................................................................................4-20
Add Hwi to the Project ..................................................................................................................4-22
Build, Load, Run. ..........................................................................................................................4-23
Debug Interrupt Problem ...............................................................................................................4-23
Other Debug/Analysis Items .........................................................................................................4-24
Conclusion ....................................................................................................................................4-25
That’s It. You’re Done!!................................................................................................................4-25
PART B (Optional) – Using the Profiler Clock .................................................................................4-26
Additional Information...........................................................................................................................4-27
Notes ......................................................................................................................................................4-30

4-2 C6000 Embedded Design Workshop Using BIOS - C6000 Hardware Interrupts (Hwi)
 System Concepts

System Concepts
Remember Lab2B ?

C6000 Embedded Design Workshop Using BIOS - C6000 Hardware Interrupts (Hwi) 4-3
System Concepts

McASP Overview

CPU Interrupts from McASP

CPU XRBUF12 XRSR
RRDY=1 C
“Ready to Read” O
McASP0_INT D
XRBUF11 XRSR E
C
XRDY=1
“Ready to Write”

 RCV/XMT INTs actually combined into one interrupt:

MCASP0_INT
(ISR must determine which “int” occurred – RCV or XMT)
 RRDY triggers when XRBUF12 is filled (32 bits)
 XRDY triggers when XRBUF11 is emptied (32 bits)
 Warning: underrun on XMT? McASP dies… !
7

4-4 C6000 Embedded Design Workshop Using BIOS - C6000 Hardware Interrupts (Hwi)
 IDL Thread

IDL Thread
Concepts

C6000 Embedded Design Workshop Using BIOS - C6000 Hardware Interrupts (Hwi) 4-5
C64x+ Interrupts

C64x+ Interrupts
Interrupts – How they Work…

4-6 C6000 Embedded Design Workshop Using BIOS - C6000 Hardware Interrupts (Hwi)
 C64x+ Interrupts

HWI – Creation

C6000 Embedded Design Workshop Using BIOS - C6000 Hardware Interrupts (Hwi) 4-7
C64x+ Interrupts

Reminder – Can Create via Static, Dynamic, CFG

HWI – Interrupt Sources

4-8 C6000 Embedded Design Workshop Using BIOS - C6000 Hardware Interrupts (Hwi)
 C64x+ Interrupts

HWI – Example ISR

C6000 Embedded Design Workshop Using BIOS - C6000 Hardware Interrupts (Hwi) 4-9
C64x+ Interrupts

Interrupt Pre-emption

Event Combiner
Event Combiner (ECM)
 Use only if you need more than 12 interrupt events
 ECM combines multiple events (e.g. 4-31) into one event (e.g. EVT0)
 EVTx ISR must parse MEVTFLAG to determine which event occurred
Interrupt
Occur? Care? Both Yes? Selector
EVTFLAG[0] EVTMASK[0] MEVTFLAG[0]
EVT 4-31 EVT0

EVTFLAG[1] EVTMASK[1] MEVTFLAG[1]

EVT 32-63 EVT1

EVTFLAG[2] EVTMASK[2] MEVTFLAG[2]

C
EVT 64-95 EVT2 128:12 P
U
EVTFLAG[3] EVTMASK[3] MEVTFLAG[3]
EVT 96-127 EVT3

EVT 4-127

25

4 - 10 C6000 Embedded Design Workshop Using BIOS - C6000 Hardware Interrupts (Hwi)
 Creating Custom Platforms

Creating Custom Platforms

C6000 Embedded Design Workshop Using BIOS - C6000 Hardware Interrupts (Hwi) 4 - 11
Creating Custom Platforms

4 - 12 C6000 Embedded Design Workshop Using BIOS - C6000 Hardware Interrupts (Hwi)
 Chapter Quiz

Chapter Quiz
Chapter Quiz
1. What typically causes an interrupt from a peripheral?

2. What is the sequence from interrupt generation to the ISR?

3. Which parts of the INT sequence does BIOS handle vs. the user?

4. How do you create a new Hwi and what configuration options exist?

5. What is the purpose of the Event Combiner?

6. What is the process to create a new custom platform package?

C6000 Embedded Design Workshop Using BIOS - C6000 Hardware Interrupts (Hwi) 4 - 13
Using Double Buffers

Using Double Buffers

4 - 14 C6000 Embedded Design Workshop Using BIOS - C6000 Hardware Interrupts (Hwi)
 Lab 4: An Hwi-Based Audio System

Lab 4: An Hwi-Based Audio System

In this lab, we will use an Hwi to respond to McASP interrupts. The McASP/AIC3106 init code
has already been written for you. The McASP interrupts have been enabled. However, it is your
challenge to create an Hwi and ensure all the necessary conditions to respond to the interrupt are
set up properly.
This lab also employs double buffers – ping and pong. Both the RCV and XMT sides have a ping
and pong buffer. The concept here is that when you are processing one, the other is being filled.
A Boolean variable (pingPong) is used to keep track of which “side” you’re on.

Application: Audio pass-thru using Hwi and McASP/AIC3106

Key Ideas: Hwi creation, Hwi conditions to trigger an interrupt, Ping-Pong memory
management
Pseudo Code:
• main() – init BSL, init LED, return to BIOS scheduler

• isrAudio() – responds to McASP interrupt, read data from RCV XBUF – put in RCV
buffer, acquire data from XMT buffer, write to XBUF. When buffer is full, copy RCV to
XMT buffer. Repeat.

• FIR_process() – memcpy RCV to XMT buffer. Dummy “algo” for FIR later on…

C6000 Embedded Design Workshop Using BIOS - C6000 Hardware Interrupts (Hwi) 4 - 15
Lab 4: An Hwi-Based Audio System

Lab 4 – Procedure
If you can’t remember how to perform some of these steps, please refer back to the previous labs
for help. Or, if you really get stuck, ask your neighbor. If you AND your neighbor are stuck, then
ask the instructor (who is probably doing absolutely NOTHING important) for help. 

Import Existing Project

1. Open CCS and delete all existing projects from your workspace (right-click, Delete).
2. Import Lab4 project.
You’ve already created one SYS/BIOS project from scratch, so to speed things up, we have
already created the initial project for you – you need to just import it and start modifying it.
At this point, if you have several projects in your workspace (Project View) and you want to
clean up the view, you can right-click on the project and select “Delete”. This will NOT
delete the contents in the folders – it will only delete the project from the workspace and it
will disappear from the Project View. Your choice.

To import the starter project, select the following and navigate to the \Lab4\Project folder:

Project  Import Existing CCS/CCE Eclipse Project

Do NOT (we said NOT) copy the project into the workspace. This will cause some
referencing errors underneath the hood – not pretty. So, LEAVE THE FOLLOWING
CHECK BOX BLANK !!

3. Check the Properties to ensure you are using the latest XDC and BIOS.
For every imported project in this workshop, ALWAYS check to make sure the latest tools
(XDC and BIOS) are being used. The author created those projects at time “x” and then may
have updated the tools on your student PC at “x+1” – some time later – and didn’t redo every
starter project with the latest tools. Therefore, you may be importing a project that is NOT
using the latest versions of the tools (XDC and BIOS).

4 - 16 C6000 Embedded Design Workshop Using BIOS - C6000 Hardware Interrupts (Hwi)
 Lab 4: An Hwi-Based Audio System

Application (Audio Pass-Thru) Overview

4. Let’s review what this audio pass-thru code is doing.
As discussed in the lab description, this application performs an audio pass-thru. The best
way to understand the process is via I-P-O:
• Input (RCV) – each analog audio sample from the audio INPUT port is converted by the
A/D and sent to the McASP port on the C6748. For each sample, the McASP generates
an interrupt to the CPU. In the ISR, the CPU reads this sample and puts it in a buffer
(RCV ping or pong). Once the buffer fills up (BUFFSIZE), processing begins…
• Process – Our algorithm is very fancy – it is a COPY from the RCV buffer to the XMT
buffer.
• Output (XMT) – When the McASP transmit buffer is empty, it interrupts the CPU and
asks for another sample. In the ISR (same ISR for the RCV side), the CPU reads a sample
from the XMT buffer and writes to the McASP transmit register. The McASP sends this
sample to the D/A and is then tramsitted to the audio OUTPUT port.

Several source files are needed to create this application. Let’s explore those briefly…

Source Code Overview

5. Inspect the source code.
Following is a brief description of the source code. Because this workshop can be targeted at
many processors (MSP430, Stellaris-M3, C28x, C6000, ARM), some of the hardware details
will be minimized and saved for the target-specific chapter.
Feel free to open any of these files and inspect them as you read…
• main.h – same as before, but contains more function prototypes
• aic3106_TTO.c – initializes the analog interface chip (AIC) on the EVM – this is the
A/D and D/A combo device.
• fir.c – this is a placeholder for the algorithm. Currently, it is simply a copy function –
to copy RCV to XMT buffers.
• isr.c – This is the interrupt service routine (isrAudio). When the interrupt from the
McASP fires (RCV or XMT), the BIOS HWI (soon to be set up) will call this routine to
read/write audio samples.
• main.c – sets up the McASP and AIC and then calls BIOS_start().
• mcasp_TTO.c – init code for the McASP on the C6748 device.

C6000 Embedded Design Workshop Using BIOS - C6000 Hardware Interrupts (Hwi) 4 - 17
Lab 4: An Hwi-Based Audio System

More Detailed Code Analysis

6. Open main.c for editing.
Near the top of the file, you will see the buffer allocations:

Notice that we have separate buffers for Ping and Pong for both RCV and XMT. Where is
BUFFSIZE defined? Main.h. We’ll see him in a minute.
As you go into main(), you’ll see the zeroing of the buffers to provide initial conditions of
ZERO. Think about this for a minute. Is that ok? Well, it depends on your system. If
BUFFSIZE is 256, that means 256 ZEROs will be transmitted to the DAC during the first
256 interrupts. What will that sound like? Do we care? Some systems require solid initial
conditions – so keep that in mind. We will just live with the zeros for now.
Then, you’ll see the calls to the init routines for the McASP and AIC3106. Previously, with
DSP/BIOS, this is where an explicit call to init interrupts was located. However, with
SYS/BIOS, this is done via the GUI. Lastly, there is a call to McASP_Start(). This is
where the McASP is taken out of reset and the clocks start operating and data starts being
shifted in/out. Soon thereafter, we will get the first interrupt.

7. Open mcasp_TTO.c for editing.

This file is responsible for initializing and starting the McASP – hence, two functions (init
and start). In particular, look at line numbers 83 and 84 (approximately). This is where the
serializers are chosen. This specifies XBUF11 (XMT) and XBUF12 (RCV). Also, look at line
numbers 111-114. This is where the McASP interrupts are enabled. So, if they are enabled
correctly, we should get these interrupts to fire to the CPU.

4 - 18 C6000 Embedded Design Workshop Using BIOS - C6000 Hardware Interrupts (Hwi)
 Lab 4: An Hwi-Based Audio System

8. Open isr.c for editing.

Well, this is where all the real work happens – inside the ISR. This code should look pretty
familiar to you already. There are 3 key concepts to understand in this code:
• Ping/Pong buffer management – notice that two “local” pointers are used to point to the
RCV/XMT buffers. This was done as a pre-cursor to future labs – but works just fine
here too. Notice at the top of the function that the pointers are initialized only if blkCnt
is zero (i.e it is time to switch from ping to pong buffers or vice versa) and we’re done
with the previous block. blkCnt is used as an index into the buffers.
• McASP reads/writes – refer to the read/write code in the middle. When an interrupt
occurs, we don’t know if it was the RRDY (RCV) or XRDY (XMT) bit that triggered the
interrupt. We must first test those bits, then perform the proper read or write accordingly.
On EVERY interrupt, we EITHER read one sample and write one sample. All McASP
reads and writes are 32 bits. Period. Even if your word length is 16 bits (like ours is).
Because we are “MSB first”, the 16-bits of interest land in the UPPER half of the 32-bits.
We turned on ROR (rotate-right) of 16 bits on rcv/xmt to make our code look more
readable (and save time vs. >> 16 via the compiler).
• At the end of the block – what happens? Look at the bottom of the code. When
BUFFSIZE is reached, blkCnt is zero’d and the pingPong Boolean switches. Then, a
call to FIR_process() is made that simply copies RCV buffer to XMT buffer. Then,
the process happens all over again for the “other” (PING or PONG) buffers.

9. Open fir.c for editing.

This is currently a placeholder for a future FIR algorithm to filter our audio. We are simply
“pass through” the data from RCV to XMT. In future labs, a FIR filter written in C will
magically appear and we’ll analyze its performance quite extensively.

10. Open main.h for editing.

main.h is actually a workhorse. It contains all of the #includes for BSL and other items,
#defines for BUFFSIZE and PING/PONG, prototypes for all functions and externs for
all variables that require them. Whenever you are asked to “change BUFFSIZE”, this is the
file to change it in.

C6000 Embedded Design Workshop Using BIOS - C6000 Hardware Interrupts (Hwi) 4 - 19
Lab 4: An Hwi-Based Audio System

Creating A Custom Platform

11. Create a custom platform file.
In previous labs, we specified a platform file during creation of a new project. In this lab, we
will create our own custom platform that we will use throughout the rest of the labs. Plus, this
is a good skill to know how to do.
Whenever you create your own project, you should always IMPORT the seed platform file
for the specific target board and then make changes. This is what we plan to do next…

In Debug Perspective, select: Tools  RTSC Tools  Platform  New

When the following dialogue appears:

• Give your platform a name: evmc6748_student (the author used _TTO for his)
• Point the repository to the path shown (this is where the platform package is stored)
• Then select the Device Family/Name as shown
• Check the box “Add Repository to Project Package Path” (so we can find it later). When
you check this box, select your current project in the listing that pops up. This also adds
this repository to the list of Repositories in the Properties  General  RTSC tab
dialogue.

Click Next.

4 - 20 C6000 Embedded Design Workshop Using BIOS - C6000 Hardware Interrupts (Hwi)
 Lab 4: An Hwi-Based Audio System

When the new platform dialogue appears, click the IMPORT button to copy the seed file we
used before:

This will copy all of the initial default settings for the board and then we can modify them. A
dialogue box should pop up and select the proper seed file as shown (select the _TTO version
of the platform file that the author already created for you:

Modify the memory settings to allocate all code, data and stacks into internal memory
(IRAM) as shown. They may already be SET this way – just double check.
BEFORE YOU SAVE – HAVE THE INSTRUCTOR CHECK THIS FILE.
Then save the new platform. This will build a new platform package.

12. Tell the tools to use this new custom platform in your project.
We have created a new platform file, but we have not yet ATTACHED it to our project.
When the project was created, we were asked to specify a platform file and we chose the
default seed platform. How do we get back to the configuration screen?
Right-clickon the project and select Properties  General and then select the RTSC tab.
Look near the bottom and you’ll see that the default seed platform is still specified. We need
to change this.
Click on the down arrow next to the Platform File. The tools should access your new
repository with your new custom platform file: evmc6748_student.

evmc6748_student

Select YOUR STUDENT PLATFORM FILE and click Ok. Now, your project is using the
new custom platform. Very nice…

C6000 Embedded Design Workshop Using BIOS - C6000 Hardware Interrupts (Hwi) 4 - 21
Lab 4: An Hwi-Based Audio System

Add Hwi to the Project

13. Use Hwi module and configure the hardware interrupt for the McASP.
Ok, FINALLY, we get to do some real work to get our code running. For most targets, an
interrupt source (e.g. McASP) will have an interrupt EVENT ID (specified in the datasheet).
This event id needs to be tied to a specific CPU interrupt. The details change based on the
target device.For the C6748, the EVENT ID is #61 and the CPU interrupt we’re using is
INT5 (there are 16 interrupts on the C6748 – again, target specific).
So, we need to do two things: (1) tell the tools we want to USE the Hwi BIOS module; (2)
configure a specific interrupt to point to our ISR routine (isrAudio).
First, make sure you are viewing the hwi.cfg file. In the list of Available Products, locate
Hwi, right-click and select “Use Hwi”. It will now show up on the right-hand Outline View.
Then, right click on Hwi in the Outline View and select “New Hwi”. When the dialogue
appears, which is different than what you see below, click OK. Then click on the new Hwi
(hwi0) (you’ll see a new dialogue like below) and fill in the following:

Make sure “Enabled at startup” is NOT checked (this sets the IER bit on the
C6748). This will provide us with something to debug later. Once again, you can click on the
new HWI and see the corresponding Source script code.

4 - 22 C6000 Embedded Design Workshop Using BIOS - C6000 Hardware Interrupts (Hwi)
 Lab 4: An Hwi-Based Audio System

Build, Load, Run.

14. Build, load and run the audio pass-thru application.
Before you Run, make sure audio is playing into the board and your headphones are set up so
you can hear the audio. Also, make sure that Windows Media Player is set to REPEAT
forever. If the music stops (the input is air), and you click Run, you might think there is a
problem with your code. Nope, there is no music playing. 

Build and fix any errors. After a successful build, debug the application. Once the program is
loaded, click Run. Do you hear audio? If not, it’s debug time. One quick tip for debug is to
place a breakpoint in the isrAudio routine and see if the program stops there. If not, no
interrupt is being generated. Move on to the next steps to debug the problem…

Hint: The McASP on the C6748 cannot be restarted after a halt – i.e. you can’t just hit halt,
then Run. Once you halt the code, you must click the restart button and then Play.

Debug Interrupt Problem

As we already know, we decided early on to NOT enable the IER bit in the static configuration of
the Hwi. Ok. But debugging interrupt problems is a crucial skill. The next few steps walk you
through HOW to do this. You may not know WHERE your interrupt problem occurred, so using
these brief debug skills may help in the future.
15. Pause for a moment to reflect on the “dominos” in the interrupt game:
• An interrupt must occur (McASP init code should turn ON this source)
• The individual interrupt must be enabled (IER, BITx)
• Global Interrupts must be turned on (GIE = 1, handled by BIOS)
• HWI Dispatcher must be used to provide proper context save/restore
• Keep this all in mind as you do the following steps…

16. McASP interrupt firing – IFR bit set?

The McASP interrupt is set to fire properly, but is it setting the IFR bit? You configured
HWI_INT5, so that would be a “1” in bit 5 of the IFR. Go there now (View → Registers
→ Core Registers). Look down the list to find the IFR and IER – the two of most interest
at the moment. (author note: could it have been set, then auto-cleared already?). You can also
DISABLE IERbit (as it is already in the CFG file), build/run, and THEN look at IFR (this is a
nice trick).
Write your debug “checkmarks” here:

IFR bit set? □ Yes □ No

C6000 Embedded Design Workshop Using BIOS - C6000 Hardware Interrupts (Hwi) 4 - 23
Lab 4: An Hwi-Based Audio System

17. Is the IER bit set?

Interrupts must be individually enabled. When you look at IER bit 5, is it set to “1”?
Probably NOT because we didn’t check that “Enable at Start” checkbox. Open up the config
for HWI_INT5 and check the proper checkbox. Then, hit build and your code will build and
load automatically regardless of which perspective you are in.

IER bit set? □ Yes □ No

Do you hear audio now? You probably should. But let’s check one more thing…

18. Is GIE set?

The Global Interrupt Enable (GIE) Bit is located in the CPU’s CSR register. SYS/BIOS turns
this on automatically and then manages it as part of the O/S. So, no need to check on this.

GIE bit set? □ Yes □ No

Hint: If you create a project that does NOT use SYS/BIOS, it is the responsibility of the user to
not only turn on GIE, but also NMIE in the CSR register. Otherwise, NO interrupts will
be recognized. Ever. Did I say ever?

Other Debug/Analysis Items

19. Using “Load Program After Build” Option and Restart.
Often times, users want to make a minor change in their code and rebuild and run quickly.
After you launch a debug session and connect to the target (which takes time), there is NO
NEED to terminate the session to make code changes. After pausing (halting) the code
execution, make a change to code (using the Edit perspective or Debug perspective) and hit
“Build”. CCS will build and load your new .out file WITHOUT taking the time to launch a
new debug session or re-connecting to the target. This is very handy. TRY THIS NOW.
Because we are using the McASP, any underrun will cause the McASP to crash (no more
audio to the speaker/headphone). So, how can you halt and then start again quickly? Halt
your code and then select Run  Restart or click the Restart button (arrow with PLAY):

So, try this now. Run your code and halt (pause). Run again. Do you hear audio? Nope. Click
the restart button and run again. Now it should work.
These will be handy tips for all lab steps now and in the future.

4 - 24 C6000 Embedded Design Workshop Using BIOS - C6000 Hardware Interrupts (Hwi)
 Lab 4: An Hwi-Based Audio System

Conclusion
20. Use ROV to see Hwi status.
Run, then halt your code. Click on Hwi to see the status.
21. Conclusion – Hwi.
So, at this point, how many threads are running? 1 2 3 4
Which threads are active? Hwi Swi Task Idle
Which thread contains our algorithm? Hwi Swi Task Idle

Right now, we’re doing all of the work (algo) inside an interrupt service routine. Hwi’s
should only be used to read/write hard real-time registers (like the McASP). The
PROCESSING (our algo) should be handed off to the BIOS scheduler via a Swi or Task. This
allows the user to easily modify priorities and let the scheduler do its job effectively.

In this part of the lab, we simply added an Hwi thread to our system and configured it to call
the isrAudio() function. The two key pieces of information were the event id (for the
McASP event) and the CPU interrupt number (INT5 in our case). For each interrupt you have
in your system, you will need to create an Hwi instance and configure it.

In the next lab, we will offload the PROCESSING (algo) to a Swi and a Task – like we should
have. One step at a time.
Before you move on to the next chapter, what steps do you think are required to turn the
FIR_process() function into a Swi ?

Change(s) in isrAudio(): ________________________________

Changes in hwi.cfg: ________________________________

That’s It. You’re Done!!

22. Close the project and delete it from the workspace.
Terminate the debug session and close CCS. Power cycle the board.

RAISE YOUR HAND and get the instructor’s attention when you have
completed PART A of this lab. If time permits, you can quickly do the
next optional part…

C6000 Embedded Design Workshop Using BIOS - C6000 Hardware Interrupts (Hwi) 4 - 25
Lab 4: An Hwi-Based Audio System

PART B (Optional) – Using the Profiler Clock

23. Turn on the Profiler Clock and perform a benchmark.
Set two breakpoints anywhere you like (double click in left pane of code) – one at the “start”
point and another at the “end” point that you want to benchmark.
Turn on the Profiler clock by selecting: Run → Clock → Enable

In the bottom right-hand part of the screen, you should see a little CLK symbol that looks like
this:

Run to the first breakpoint, then double-click on the clock symbol to zero it. Run again and
the number of CPU cycles will display.

4 - 26 C6000 Embedded Design Workshop Using BIOS - C6000 Hardware Interrupts (Hwi)
 Additional Information

Additional Information

C6000 Embedded Design Workshop Using BIOS - C6000 Hardware Interrupts (Hwi) 4 - 27
Additional Information

4 - 28 C6000 Embedded Design Workshop Using BIOS - C6000 Hardware Interrupts (Hwi)
 Additional Information

C6000 Embedded Design Workshop Using BIOS - C6000 Hardware Interrupts (Hwi) 4 - 29
Notes

Notes

4 - 30 C6000 Embedded Design Workshop Using BIOS - C6000 Hardware Interrupts (Hwi)
 Using Swi's and Tasks
Introduction
There is a “thread” of truth in this chapter – it’s all about thread types in SYS/BIOS. In the
previous chapter, we covered hardware interrupts (Hwi). In this chapter, you will learn how to
post a “follow up” activity as either a software interrupts (Swi) or a task (Tasks).
In the lab, you will modify your previous solution to use Swi’s and Tasks.

Objectives

Objectives

 Understand how Swi’s complement Hwi’s

 Compare/contrast Swi & Task
 Describe the use of semaphores and
Tasks in a system & how to create them
 Identify how Tasks are prioritized within
the BIOS Scheduler
 Lab 5 – Use Swi to perform “ALGO” as
follow-up to Hwi. Change Swi to Task.

C6000 Embedded Design Workshop Using SYS/BIOS - Using Swi's and Tasks 5-1
Module Topics

Module Topics
Using Swi's and Tasks ................................................................................................................................5-1
Module Topics..........................................................................................................................................5-2
Using Swi .................................................................................................................................................5-3
Using Tasks ..............................................................................................................................................5-6
Using Semaphores ...................................................................................................................................5-9
Scheduler ...............................................................................................................................................5-11
Scheduling Strategies .............................................................................................................................5-12
Chapter Quiz ..........................................................................................................................................5-13
Lab 5: Using Swi’s and Tasks ................................................................................................................5-15
Lab 5A – Procedure – Using Swi ......................................................................................................5-16
Import Project – From Lab 5 .........................................................................................................5-16
Add a Swi to the System ...............................................................................................................5-16
Build, Load, Run. ..........................................................................................................................5-17
Inspect Your Code Using ROV .....................................................................................................5-17
Lab 5B – Procedure – Using Tasks and Semaphores ........................................................................5-18
Add a Task and Semaphore to the System ....................................................................................5-18
Build, Load, Run. ..........................................................................................................................5-19
Inspect Execution States Using ROV ............................................................................................5-19
That’s It. You’re Done !! ...................................................................................................................5-19
Notes ......................................................................................................................................................5-20

5-2 C6000 Embedded Design Workshop Using SYS/BIOS - Using Swi's and Tasks
 Using Swi

Using Swi

C6000 Embedded Design Workshop Using SYS/BIOS - Using Swi's and Tasks 5-3
Using Swi

5-4 C6000 Embedded Design Workshop Using SYS/BIOS - Using Swi's and Tasks
 Using Swi

C6000 Embedded Design Workshop Using SYS/BIOS - Using Swi's and Tasks 5-5
Using Tasks

Using Tasks

5-6 C6000 Embedded Design Workshop Using SYS/BIOS - Using Swi's and Tasks
 Using Tasks

C6000 Embedded Design Workshop Using SYS/BIOS - Using Swi's and Tasks 5-7
Using Tasks

Modification of a Task’s Priority

origPrio = Task_setPri(Task_self(),7);
// critical section ...
// TSK priority increased or reduced ...
Task_setPri(Task_self(),origPrio);

 TSK_setpri() can raise or lower priority

 Return argument of TSK_setpri() is previous priority
 New priority remains until set again (or TSK deleted/created)
 Can also use Task_getPri() to get a Task’s current priority
 To suspend a TSK, set its priority to negative one (-1)
• TSK removed from scheduler, can be re-activiated with TSK_setpri()
• Handy option for statically created TSKs that don’t need to run at start

15

5-8 C6000 Embedded Design Workshop Using SYS/BIOS - Using Swi's and Tasks
 Using Semaphores

Using Semaphores

C6000 Embedded Design Workshop Using SYS/BIOS - Using Swi's and Tasks 5-9
Using Semaphores

5 - 10 C6000 Embedded Design Workshop Using SYS/BIOS - Using Swi's and Tasks
 Scheduler

Scheduler

C6000 Embedded Design Workshop Using SYS/BIOS - Using Swi's and Tasks 5 - 11
Scheduling Strategies

Scheduling Strategies

5 - 12 C6000 Embedded Design Workshop Using SYS/BIOS - Using Swi's and Tasks
 Chapter Quiz

Chapter Quiz
Chapter Quiz
1. Compare and contrast Swi’s and Tasks:

2. What is the basic structure of a Task?

3. Which function call is used to change the priority of a Task?

4. What does Semaphore_post() do, where is this fxn call typically found?

5. What does a Semaphore_pend() do, where is this fxn call found?

C6000 Embedded Design Workshop Using SYS/BIOS - Using Swi's and Tasks 5 - 13
Chapter Quiz

*** SECURITY BREACH – Trojan Horse inserted this blank page… ***

5 - 14 C6000 Embedded Design Workshop Using SYS/BIOS - Using Swi's and Tasks
 Lab 5: Using Swi’s and Tasks

Lab 5: Using Swi’s and Tasks

This lab provides users with a challenge – extending the audio pass-thru system using Swi’s and
Tasks as follow-up activities to the Hwi.
Many more details about the platform files, RTSC configuration and ROV will also be explored.

C6000 Embedded Design Workshop Using SYS/BIOS - Using Swi's and Tasks 5 - 15
Lab 5: Using Swi’s and Tasks

Lab 5A – Procedure – Using Swi

In this part of the lab, instead of calling FIR_process() directly inside the ISR, we will post a
software interrupt (Swi) so that the scheduler will run the processing function (algo) according to
its rules – when it is the highest priority pending thread in the system.

This requires registering FIR_process() as a Swi and modifying isrAudio() to post it.

Import Project – From Lab 5

1. Open CCS and delete all existing projects from your workspace (right-click, Delete).
Make sure your workspace is CLEAN (i.e. contain no projects).
2. Import existing Lab5 project which has already been created for you.
This is the solution from the previous lab – Lab 4 (Hwi) – not YOUR solution from Lab4.
Double check that this project is using the LATEST XDC and BIOS tools versions.
3. Modify build properties – RTSC tab – to use YOUR student platform that you created in
the previous lab.
4. Build, load, run and verify that it works properly.

Add a Swi to the System

5. Create a Swi object.
Our first step is to create the object and configure it. Normally, we would select “Use Swi”
from the Available Products menu. However, our swi_task.cfg already contains Swi.
So, add a new Swi with the following configuration:
• Name: firProcessSwi

• Function: ________________

• Priority: 1

Save your new .CFG file.

6. Add a Swi_post call to isrAudio().

In isrAudio(), underneath the call to FIR_process(), post the Swi you just created
and comment out the direct call to FIR_process. That’s it. You just turned a function
(FIR_process) into a THREAD – a Swi.
Now the BIOS scheduler has control over when this Swi runs and you, the user, can prioritize
this Swi vs. other Swi by simply setting their priorities and rebuilding. Hey, this is what an
O/S is all about…
7. Modify fir.c to use other version of FIR_process.
Open fir.c and uncomment the version of FIR_process for Swi’s. Comment out the
other one that contains 3 arguments.

5 - 16 C6000 Embedded Design Workshop Using SYS/BIOS - Using Swi's and Tasks
 Lab 5: Using Swi’s and Tasks

8. Modify main.h.
In main.h, there are two prototypes for FIR_process(). Again, uncomment the (void)
version and comment out the prototype for the one with 3 arguments.

Build, Load, Run.

9. You know the drill.
Hear audio? If not, debug the problem. If it is working, you can move on to the next step.

Inspect Your Code Using ROV

10. Use ROV to check the state of your Swi.
Run then halt the program. Open ROV and click on Swi to see the state.
Most likely, if you look at the “state” tab, it will say “Idle”. Set a breakpoint inside the
FIR_process function, restart and run. Now check the state. It should say “running”.

Hint: When looking at dialogues that have columns like ROV, it is sometimes helpful to click
the Auto Fit Columns button. Why this isn’t the default is beyond me:

11. Conclusion

So, which threads are alive now? Hwi Swi Task Idle

Now we need to convert a Swi to a Task. What needs to be done to accomplish this?

isrAudio changes: ________________________________________________________

FIR_process() changes: __________________________________________________

swi_task.cfg changes:

_____________________________________________________

_____________________________________________________

C6000 Embedded Design Workshop Using SYS/BIOS - Using Swi's and Tasks 5 - 17
Lab 5: Using Swi’s and Tasks

Lab 5B – Procedure – Using Tasks and Semaphores

In this part of the lab, instead of posting a Swi, we will post a semaphore to unblock a Task to go
“process” our buffers (i.e. execute the copy algorithm inside of a Task).
So, we need to convert our Swi application to a Task. This involves:

• Creating a Task object that calls FIR_process

• Creating a Semaphore to unblock the Task (post/pend)
• Modifying isrAudio to post a Semaphore instead of a Swi
• Modifying FIR_process to use a while(1) loop and a Semaphore_pend.

Add a Task and Semaphore to the System

12. Delete the current Swi.
Delete the Swi – firProcessSwi – from the .cfg file (via the outline view).

13. Add a new Task.

Add a Task named firProcessTask that calls FIR_process. Use priority 2. Leave all
other default settings as they are.

Hint: When you are modifying the .cfg file and add or delete something, the tools will always
validate your selections. Sometimes, this can take time. The author would like to see a
beach ball or hourglass icon when this is going on, but that’s not a feature yet.
Sometimes, when you click again quickly, the tools aren’t DONE validating and it can
mess up your typing or delay your fast clicking. To see the validation process occurring,
look in the bottom right-hand portion of the screen:

14. Add a new semaphore.

In the .cfg file, add a semaphore named mcaspReady.

15. Modify FIR_process to create a loop and use a Semaphore_pend().

Edit fir.c and add a while(1) loop at the top of the function. Just beneath the loop and
above the existing code, add a Semaphore_pend() and use the wait time as
BIOS_WAIT_FOREVER. Note, you must also specify the proper semaphore to pend on. If
you forgot how to do this, ask your neighbor or look back at the discussion notes.

16. Post the semaphore in isrAudio.

Open isr.c and edit isrAudio (near the bottom) to post a semaphore instead of a Swi. You can
just write a new line of code and comment out the posting of the Swi.

5 - 18 C6000 Embedded Design Workshop Using SYS/BIOS - Using Swi's and Tasks
 Lab 5: Using Swi’s and Tasks

Build, Load, Run.

17. Again, you know the drill.
Build and fix any errors. Load your new Task-based program and Run it. Do you hear audio?
If so, move on. If not, well, quit. Or blame the mistake on someone else – maybe your lab
partner. Ah, just kidding. Go ahead and try to debug it. If you are still struggling after 5
minutes, ask your instructor for help (or a neighbor).

Inspect Execution States Using ROV

18. Open ROV and inspect a few items.
Now that we are using Tasks, click on Task and see the current state. You can also place a
breakpoint inside that Task and Run again to see the state change.
Also, click on Semaphore. You should see your semaphore and its status.
Feel free to click around inside ROV to check other items.

That’s It. You’re Done !!

19. Terminate the Debug Session and close the project and CCS. Delete your project from
the workspace. Then, power cycle the board.

You’re finished with this lab. Please raise your hand and let the instructor
know you are finished with this lab (maybe throw something heavy at them to
get their attention or say “CCS crashed – AGAIN !” – that will get them
running…)

C6000 Embedded Design Workshop Using SYS/BIOS - Using Swi's and Tasks 5 - 19
Notes

Notes

5 - 20 C6000 Embedded Design Workshop Using SYS/BIOS - Using Swi's and Tasks
 Clock Functions & RTA Tools
Introduction
This chapter is all about the SYS/BIOS Clock module and Clock functions as well as exploring
stop-mode RTA tools like the Execution Graph and Logs.
.

Objectives

Objectives

 Describe how to configure Clock Functions

to execute periodically
 Use Timestamp to benchmark code
 Configure all of the RTA tools – including
Logs, Execution Graph and CPU/Thread Load
 Lab 6 – Add Clock Fxn and observe RTA results

C6000 Embedded Design Workshop Using SYS/BIOS - Clock Functions & RTA Tools 6-1
Module Topics

Module Topics
Clock Functions & RTA Tools ..................................................................................................................6-1
Module Topics..........................................................................................................................................6-2
Clock Functions .......................................................................................................................................6-3
Clock Module ......................................................................................................................................6-3
Using Clock Functions ........................................................................................................................6-4
Timestamp ...........................................................................................................................................6-5
Basic Debug Tools ...................................................................................................................................6-6
CCS Views ..........................................................................................................................................6-6
System_printf() ....................................................................................................................................6-6
RTOS Object Viewer (ROV)...............................................................................................................6-7
RTA Tools (Stop Mode) ............................................................................................................................6-8
RTA Agent ..........................................................................................................................................6-8
Logs .....................................................................................................................................................6-9
Execution Graph ................................................................................................................................6-10
CPU/Thread Loading.........................................................................................................................6-11
Chapter Quiz ..........................................................................................................................................6-12
Lab 6: Clock Functions & RTA Tools ....................................................................................................6-13
Lab 6 – Clock Fxns & RTA – Procedure...........................................................................................6-14
Import & Verify Existing Project ..................................................................................................6-14
Use Custom Platform Package From Previous Lab ......................................................................6-15
Add Periodic Clock Function – ledToggle() .................................................................................6-17
Build, Load and Run. ....................................................................................................................6-18
Configure Real-Time Analysis Tools – RTA Agent .....................................................................6-19
View Log Messages ......................................................................................................................6-20
Audio Problem – Explanation .......................................................................................................6-21
View Execution Graph ..................................................................................................................6-22
Audio Glitch ..................................................................................................................................6-23
Profling Code Segments – Using Timestamp_get32() ..................................................................6-26
That’s It. You’re Done !!! .............................................................................................................6-27
Additional Information & Notes ............................................................................................................6-28

6-2 C6000 Embedded Design Workshop Using SYS/BIOS - Clock Functions & RTA Tools
 Clock Functions

Clock Functions
Clock Module

C6000 Embedded Design Workshop Using SYS/BIOS - Clock Functions & RTA Tools 6-3
Clock Functions

Using Clock Functions

6-4 C6000 Embedded Design Workshop Using SYS/BIOS - Clock Functions & RTA Tools
 Clock Functions

Timestamp

C6000 Embedded Design Workshop Using SYS/BIOS - Clock Functions & RTA Tools 6-5
Basic Debug Tools

Basic Debug Tools

CCS Views

System_printf()

6-6 C6000 Embedded Design Workshop Using SYS/BIOS - Clock Functions & RTA Tools
 Basic Debug Tools

RTOS Object Viewer (ROV)

C6000 Embedded Design Workshop Using SYS/BIOS - Clock Functions & RTA Tools 6-7
RTA Tools (Stop Mode)

RTA Tools (Stop Mode)

RTA Agent

6-8 C6000 Embedded Design Workshop Using SYS/BIOS - Clock Functions & RTA Tools
 RTA Tools (Stop Mode)

Logs

C6000 Embedded Design Workshop Using SYS/BIOS - Clock Functions & RTA Tools 6-9
RTA Tools (Stop Mode)

Execution Graph

6 - 10 C6000 Embedded Design Workshop Using SYS/BIOS - Clock Functions & RTA Tools
 RTA Tools (Stop Mode)

CPU/Thread Loading

C6000 Embedded Design Workshop Using SYS/BIOS - Clock Functions & RTA Tools 6 - 11
Chapter Quiz

Chapter Quiz
Chapter Quiz
1. What is the clock module used for and how do you configure it?

2. Which options must be configured for a clock function to run?

3. Which function call is used to benchmark ANYTHING in your code?

4. Name the RTA Tools and the key module you MUST include in the
.cfg file for ANY RTA tool to work?

5. What types of debug data can you see in the ROV?

6 - 12 C6000 Embedded Design Workshop Using SYS/BIOS - Clock Functions & RTA Tools
 Lab 6: Clock Functions & RTA Tools

Lab 6: Clock Functions & RTA Tools

This lab will introduce the SYS/BIOS Clock module. In BIOS5, these were called Periodic (PRD)
functions. In SYS/BIOS, they are called Clock Functions. They operate in a similar fashion, just
different names.
In the first part of this lab, you will create a Clock Fxn that toggles an LED every 200ms. This
will cause some adverse affects in the audio playback.
In the second part of the lab, you’ll use the stop-mode RTA tools (Execution graph mainly) to
pinpoint the problem and fix it.

C6000 Embedded Design Workshop Using SYS/BIOS - Clock Functions & RTA Tools 6 - 13
Lab 6: Clock Functions & RTA Tools

Lab 6 – Clock Fxns & RTA – Procedure

In this lab, you will import the solution from the last lab and add a Periodic Clock Function that
blinks the LED (ledToggle). This will introduce some problems with thread priorities and
you’ll have a chance to use several RTA tools to inspect and debug the problem.

Import & Verify Existing Project

1. Open CCS and delete all existing projects from your workspace (right-click, Delete).
2. Import existing project located at – Labs\Lab6\Project.

3. Verify project contents.

When the project imports, check the contents of the project to verify all files are there. It
should look exactly the same as the following:

Make sure this project is active and the build configuration is set to Debug. Also, if TWO .cfg
files exist, erase app.cfg and KEEP clk_rta.cfg.

4. Check build properties to verify that the LATEST XDC/BIOS tools are selected.

6 - 14 C6000 Embedded Design Workshop Using SYS/BIOS - Clock Functions & RTA Tools
 Lab 6: Clock Functions & RTA Tools

Use Custom Platform Package From Previous Lab

5. Point project to your custom platform package.
Remember in the last lab when you created the platform package – evmc6748_student?
We want to use the same platform in this lab. So, we need to ADD the repository to our
“Products and Repositories” list via Properties.

Right-click on the project and select Properties. Click on General and then click on the RTSC
tab – you should be familiar with this process by now.

We need to do two things: (1) ADD the repository; (2) select the custom platform package.
Look at the bottom of the screen and you’ll notice that the seed platform
(ti.platforms.evm6748) is being used in this project. We want to choose our custom
platform instead.

Click on the down arrow next to platform. Is your platform listed? Nope. The tools are
checking all of the tools paths you have checked up above – namely the XDC tools path for
platforms. Well, our platform repository isn’t listed there.

So, click the Add button on the right to add a repository and browse to the following:
\Labs\SYSBIOS_Platforms

Click OK.

C6000 Embedded Design Workshop Using SYS/BIOS - Clock Functions & RTA Tools 6 - 15
Lab 6: Clock Functions & RTA Tools

When you click OK, you’ll see this path added:

Make sure the checkbox next to this new repository is checked. Then, click on the down
arrow next to platforms and the tools will scan the new path and find the custom platform
package – evmc6748_student. Select that platform:

Click OK.

You have now added a “package” to your project – which is simply a custom platform
package. If, in the future, someone (or TI) delivers you a “package” (which is a library +
metadata), you now know how to add this package to your project and use it.

6. Build, load, run, verify.

Let’s first build and run this project to ensure it works properly before moving on. There
shouldn’t be any problems, but we’re just being safe…

Simply click the Debug “bug”.

This simple click will build the project, launch the debugger session, connect to the target and
load your program. If there are build errors, CCS will “stop short” and not launch the
debugger.
Get some music playing and run the code. The audio should be working fine. This is the
Task-based audio application from the previous lab.

6 - 16 C6000 Embedded Design Workshop Using SYS/BIOS - Clock Functions & RTA Tools
 Lab 6: Clock Functions & RTA Tools

Add Periodic Clock Function – ledToggle()

7. Add a periodic clock function to your project.
The goal here is to add a clock function that runs every 200ms that toggles the LED on the
target board. You accomplished this in a previous lab by registering the ledToggle()
function as an Idle function (with a ½ second delay built in). In this lab, we want to do the
similar process, but use the Clock module to accomplish this.
To add a clock function requires two steps: (1) Use and configure the Clock module in
SYS/BIOS; (2) create a new clock function and configure it.
So, first we’ll add the Clock module to our rta.cfg and configure it.
Locate the Clock module in Available Products and “Use” it. The Clock module
configuration dialogue will appear. Notice that the system “tick rate” is set to 1000uS per
interrupt – that would be 1ms.
MODIFY “tick rate” to 100000 = 100ms. Save it.
Next, notice the hardware timer that is selected – ANY. Click the down arrow and see that you
can choose a specific timer on the target architecture. Leave the setting at “ANY” for this lab.
ANY just means pick “ANY” timer. Of course, in your own application, we’d suggest picking
a specific timer – but now you know how it works.

In the Outline view, add a new Clock function with the following parameters (USE 2 ticks):

This creates a Clock object that will run ledToggle() every 2 ticks – or every 200ms –
since the tick rate is 100ms.
8. Inspect ledToggle().
Open led.c and inspect the ledToggle() function. We made a few changes from the
earlier version. First, we added a count value so that we could see how many times the LED
was toggled later when we debug our code. This information is sent to the RTA tools during
the Idle thread via the Log_info1() function call.

The other change was removing the half-second “delay” call to the BSL library. We no
longer need a “delay” because this function will run every 200ms.

C6000 Embedded Design Workshop Using SYS/BIOS - Clock Functions & RTA Tools 6 - 17
Lab 6: Clock Functions & RTA Tools

9. Think about the threads in a system for a moment.

How many threads do we have in our system now? 1 2 3 4 5

Circle the threads that are active now: Hwi Swi Task Idle

FYI. If you haven’t been circling Idle the past few times we’ve asked this question, you
should be. Idle is always active even if there is no explicit Idle function added to the system.
All runtime debug information (ROV and other RTA tools) is collected during the Idle thread
and then displayed to the user when the application halts.

Did you circle Swi? If not, well, you should have. What thread type is a Clock function? It is
a Swi.
How many Hwi’s are in the system? 1 2 3

Remember that the Clock Module in SYS/BIOS uses a hardware timer to create periodic
ticks. Every time a “tick” happens, a timer ISR is run to determine which of the Clock
functions should be executed. So, we’re getting a timer interrupt every 100ms and ledToggle
will run every 2 ticks.
So, right now, we have TWO Hwis (McASP interrupt, Timer interrupt), Swi
(ledToggleClock), Task (audio copy algo) and Idle (background, RTA). Wow, 5 threads
already. And who executes the threads in our application? The BIOS scheduler. Who sets the
priorities within each thread type? The user. More on that in a few more steps…

Build, Load and Run.

10. Build, Load, Run.
When you run your code, is the audio working? Is the LED blinking? Your audio may sound
a bit glitchy, but we’ll fix that later.
Most likely, the LED is NOT running. Why? Who knows? That’s what you get paid to figure
out. Let’s use ROV to figure out the problem.
Halt your code and open ROV.Click on the Clock module to check its status. See anything
that looks like a problem? Is the clock STARTED? Oops.
Go back to your rta.cfg file and open the configuration for your clock function and make
sure the checkbox for “Start at boot time…” is checked:

Rebuild your application and run again. Is the LED blinking now? It should be. If not, try to
debug the problem for a few minutes before asking your instructor.
11. Which interrupt is the Timer using?
Our target device (C6748) has 16 CPU interrupts. Which interrupt number is associated with
the hardware timer the Clock module is using? We know the McASP Hwi is using interrupt
#5. Which interrupt # is the timer using (check ROVHwi)?
_________

6 - 18 C6000 Embedded Design Workshop Using SYS/BIOS - Clock Functions & RTA Tools
 Lab 6: Clock Functions & RTA Tools

Configure Real-Time Analysis Tools – RTA Agent

12. Add RTA Agent to our project.
RTA tools require the RTA Agent to be built into our project. If we want to see Logs (like the
msg about how many times the LED toggled) or any other RTA tools in action, the RTA
Agent is critical. Also, we want to use STOP-MODE debug versus the runtime RTDX mode.
In the Available Products, expand Realtime Analysis and select the Agent (i.e. right-click and
select “Use…”). When the dialogue appears, inspect the contents.
13. Configure RTA Agent.
We want to make a few small changes. By default, Task logging is enabled and the buffer
size is 4K. On the C6000 target, we have large memory blocks (e.g. 256K) that we can use to
log real-time execution information. Other targets vary in terms of their available memory.
So, let’s make two changes. First, enable Swi logging and then change the buffer size to 32K
as shown:

This will allow us to see the Swi (ledToggleClock) interrupting our audio Task
(firProcessTask) in the execution graph. Also, adding the Agent to our project will
allow us to see the Log info that we sent inside the ledToggle() function.

Save clk_rta.cfg.

C6000 Embedded Design Workshop Using SYS/BIOS - Clock Functions & RTA Tools 6 - 19
Lab 6: Clock Functions & RTA Tools

View Log Messages

14. View Log messages in the RTA tools.
Rebuild your program with the new Agent added. DO NOT RUN YET.

Select Tools from the menu and open the RTA “Raw Logs” window:

Hint: In the current release of the tools, there is a small bug in the stop-mode RTA display. If
you halt your program and then open and RTA window, there is no “stop” (breakpoint) to
trigger the action of reading the data. You can simply hit the single-step button and then
the window will read the proper data. Another option is to open the window BEFORE
you click halt – as we are doing here.

Click Run, wait a few seconds, then click halt. What you see are ALL of the Log messages
being sent to the logger object. This includes a bunch of SYSBIOS logs you may not be
interested in.
How can we see JUST the stuff WE want? Wow that is selfish. So be it. In the right-hand
portion of the Raw Logs window, do you see the dropdown where it says “All Log Buffers” ?
Select “Main Logger” in that window to only show the Log info from our ledToggle()
function:

Now you can see the messages from our ledToggle() function:

6 - 20 C6000 Embedded Design Workshop Using SYS/BIOS - Clock Functions & RTA Tools
 Lab 6: Clock Functions & RTA Tools

Audio Problem – Explanation

15. Does the audio stream sound perfectly clear?

You should be hearing a small to medium disruption in the audio stream. You may need to
play “lighter” music to hear it. Rock music will probably mask the disruption. When you
play the audio, watch the LED blinking – does the disruption correlate to the LED blink?
Yep.
Houston, we have a problem. Over the next few steps, we’ll investigate this problem further
by using some of our RTA tools – namely the Execution Graph.

Our two main threads are the audio processing Task and the blinking of the LED (Clock).

Which thread type is a Clock function? Hwi Swi Task Idle

Which one of these is the higher priority? Swi Task

So, our LED toggle routine is HIGHER priority than the audio processing. That’s not a good
thing – unless you want your audio to sound glitchy. Would checking a user input button
every 200ms be more important than the MP3 algo itself? Nope.

So, how can we solve this problem?

Jot down a few notes indicating how YOU would solve this problem…

______________________________________________________________

______________________________________________________________

C6000 Embedded Design Workshop Using SYS/BIOS - Clock Functions & RTA Tools 6 - 21
Lab 6: Clock Functions & RTA Tools

View Execution Graph

16. View the execution graph results.
Assuming you’ve heard the glitch by now, let’s find out if we can SEE the glitch using our
handy RTA stop-mode tools – like the Execution Graph.
Reload your program by selecting:
Run  Reload Program.

BEFORE YOU RUN, open the Execution Graph window (Note: RTA tools need a “trigger”
like a breakpoint to occur when the window is OPEN to display the data you want. If you
forget to open the window first, simply clicking “single step” might help). Then click Run,
wait a few seconds, then halt. Make sure you increae the vertical size so that you can see the
Legend.
The execution graph shows exact timing of events within the system. Zoom in/out and go
left/right so that you find an area of the graph similar to this screen shot. You can hold down
[Alt] and drag an area to zoom in on specifically:

Let’s dissect this graph piece by piece (your colors may vary):
• The first thick line is the Idle thread. When nothing else is running, Idle is executed.
• Notice when the BIOS Scheduler runs. Very cool.
• FIR_process() fxn is shown on the bottom of this graph and contains our algo (copy
function) which occurs when the audio buffers fill up – it is periodic. An Hwi (not
shown) posts the semaphore – which you can see and unblocks the FIR_process()
function to run (you can also see the unblocking flag).
• Every 100ms, the Clock module interrupts the system with the timer interrupt – the
second long thick line in the graph above – again, periodic. Every 2 times the clock
function runs, the ledToggle() function runs.

See anything strange in the picture above?

When ledToggle() is running, FIR_process() is pre-empted and is missing frames of
audio data. Hence the noise you hear. Semaphores are being posted (green flags), but the
Task (FIR_process) can’t run because ledToggle has priority. YUCK !!

6 - 22 C6000 Embedded Design Workshop Using SYS/BIOS - Clock Functions & RTA Tools
 Lab 6: Clock Functions & RTA Tools

17. Timing Analysis.

We can use the Execution Graph to determine some timings. While we’re here, we might as
well have a bit of fun before we fix the audio glitch.
To perform timing measurements, select the measurement tool:

When you click on this button, you will then be able to “lay down” a starting point for the
time measurement. Place the first line at the beginning of the ledToggle fxn starting to run.
Click this button again and place the other vertical measurement marker at the end of the
ledToggle audio-killer.
Notice you now have two markers (X1 and X2). Look in the upper left-hand part of the
window to see the measurement:

So, this ledToggle() routine takes 10.6 million nanoseconds. Pull out the calculator,
attempt to find the engineering notation button, check the calculator user guide for some help,
etc, then finally realize the answer is: 10.7ms. Holy “audio-killer” batman. That is a LONG
routine – as we can observe in the Execution Graph.

What is the time between periodic ticks? (of the Clk fxn): ______________ns
What is the time between audio frames being processed? ______________ns

These are very handy tools for debug – not only the visual for the thread scheduling but also
being able to measure times between events and events themselves.

Audio Glitch
18. Audio Glitch – Solution - Discussion.
So, how would fix this problem?
Hopefully you came up with an idea or two earlier. Here’s a hint…
ledToggle() is currently running as a Swi. How can we run it as a Task? Sure. Here’s the
procedure to do this:
• Turn ledToggle() into a Task.
• Have the periodic clock function call a “helper function” (Swi) that posts a semaphore to
unblock the new ledToggle() Task. So, the Swi is very short instead of spending all those
cycles toggling the LED.
• Last item is priority. Set the audio Task at a higher priority than the new ledToggle Task.
• Rebuild, load, run.

So, let’s go do it !

C6000 Embedded Design Workshop Using SYS/BIOS - Clock Functions & RTA Tools 6 - 23
Lab 6: Clock Functions & RTA Tools

19. Solve Audio Glitch.

We need to perform the following four steps (don’t do them yet, this is just a summary – the
steps to do each one follow this summary):
• Create a new Task and point it to ledToggle()
• Create a new Semaphore to use (ledToggleSem)
• Create a helper function (ledTogglePost) that is called by the Clock Function Swi to
post the semaphore
• Configure the Clock Function to call the helper function (ledTogglePost).

In led.c:
• Add a while(1) loop and a Semaphore_pend to the ledToggle() function – just
like you did for FIR_process() in the previous lab.
• At the bottom of the file, uncomment the “helper” function ledTogglePost() and
modify the Semaphore name.
In rta.cfg:
• Create a new Task named ledToggleTask. Point this Task object to the proper
function (ledToggle) and give it priority #1. Is ledToggle() the proper function?
• Create a Semaphore named LedToggleSem.
• Modify Clock Function to call the ledTogglePost (Swi) helper function.
• Make sure firProcessTask is at priority #2 (higher than ledToggleTask).

20. Let’s review what we just did.

21. So, here’s the domino of events:

2 ticks (200ms) expires and the Clock Function (ledToggleClock) calls
ledTogglePost() which posts ledToggleSem – thereby unblocking
ledToggleTask which points to ledToggle() and it toggles the LED.
ledToggleTask priority is set LOWER than firProcessTask – therefore the audio
algo (copy) has higher priority and no audio frames will be lost.

We will hopefully be able to see this in action once we rebuild, run and view the Execution
Graph.

6 - 24 C6000 Embedded Design Workshop Using SYS/BIOS - Clock Functions & RTA Tools
 Lab 6: Clock Functions & RTA Tools

22. Rebuild, load, run.

Ensure the Execution Graph window is open. Run, wait a few seconds, then halt. Once again,
zoom in on an area that looks like the following:

As you can see, the FIR_process() function preempts the ledToggle() function and
you hear almost no noise in the system. Any noise left is simply an issue of the I2C channel
being driven on board – those LED and other BSL functions are NOT tuned for pure audio –
they are only used for proving board connectivity.
23. View Execution Graph options.
Right-click on the graph and view the options like “deleting measurement markers”.
24. See Raw Logs synced with the Execution Graph.
Open the Raw Logs window and click on a point in the graph OR the log – you will see that
the log window and execution graph are SYNCED with each other. Right-click on the Logs
window and DETACH so you can see them at the same time. Then click. Very nice.
25. View the CPU and Thread Loading.
Open the CPU and Thread Load Graph windows. Your CPU load should be around 40% and
you can see two threads in the Thread Load graph. If these windows don’t have any data in
them, reload your program, run for a few seconds and halt.
26. Add “dynamic view” of CPU load to your code.
Really? We can determine our CPU load when we’re running our code? That’s a great debug
tool and might be handy in our main production code also.
Open led.c and add the following two lines of code as shown. The declaration for
cpu_load should already be near the top of ledToggle() – just uncomment it:

C6000 Embedded Design Workshop Using SYS/BIOS - Clock Functions & RTA Tools 6 - 25
Lab 6: Clock Functions & RTA Tools

27. Check the BIOS System Overview “view”

In the CFG file, click on “BIOS” and then click System Overview. Notice how the green
checkmarks denote the services you have added to your cfg file. Some people like this
graphical view quite a bit. Well, at least you know it’s there…
28. Build, Load and Run.
Halt after a little while and check your Raw Logs to see the results. The author showed about
a 38% CPU load. If you get errors of some kind, ALWAYS CHECK THE PLATFORM
FILE!!

Profling Code Segments – Using Timestamp_get32()

29. Benchmark the call to LED_toggle() BSL function.
Using the SYS/BIOS function call Timestamp_get32(), you can benchmark code between
any two points you determine. We want to add some code that reads a timer value twice,
subtracts the two and puts the result into a variable that we can spit out to a Log.
In BIOS5, we had a module called STS (Statistics). This module is no longer available in
SYS/BIOS, so the following technique will allow us to get similar results. The great news is
that SYS/BIOS does support function calls that read a hardware timer value. For the C6748,
the time is called TSCL/H – Timestamp Counter Lo/Hi (64 bits). You can read a 64-bit or 32-
bit value. The key fxn call is:
Timestamp_get32();
This will take a snapshot of the timer and give you a value. If you do that at the “start” and
“end” points of what you want to measure, then subtract the values, there is your benchmark.
Then, take the “result” and send it via a Log_info() function call. Done.
Open led.c and edit the ledToggle() function as shown. We need to create three 32-bit
values and add a few Timestamp_get32() calls. Here is the code to add:

Simply uncomment the lines of code to match the above….

6 - 26 C6000 Embedded Design Workshop Using SYS/BIOS - Clock Functions & RTA Tools
 Lab 6: Clock Functions & RTA Tools

30. Build, load and run.

Use the Log RTA tools to see your benchmarks. Is the calculated benchmark close to the
measurement using the Execution Graph? The author got ~3.2 million cycles:

Yes, this is a long function – hey, it’s BSL code – not meant to be efficient. But, the point
here is that you gained the skill of learning how to profile code in real-time and see it in a
Log message.
Ok, so we got 10.7ms when we measured ledToggle with the Execution Graph markers, but
only 3.2M cycles when we profiled it with Timestamp. Do these numbers jive? Well, if the
target device (6748) is running at 300Mhz, one cycle is 3.3ns. 3.3ns * 3.2M cycles = 10.6ms.
Hey, they do match.
So, the key thing to remember is that the Execution Graph shows benchmarks in
NANOSECONDS. The benchmarking with Timestamp_get32() provides results in CYCLES.

That’s It. You’re Done !!!

31. Terminate your debug session, close project, and close CCS.

You’re finished with this lab. Take a break, you’ve earned it. If you’re the first
one done, gloat a bit. If you’re the last one done, tell everyone you did all of
the “optional labs” at the end and watch them squirm because they didn’t
“see them”. Then smile and take your seat. 

C6000 Embedded Design Workshop Using SYS/BIOS - Clock Functions & RTA Tools 6 - 27
Additional Information & Notes

Additional Information & Notes

6 - 28 C6000 Embedded Design Workshop Using SYS/BIOS - Clock Functions & RTA Tools
 Inter-thread Communication
Introduction
This chapter covers the basics of inter-thread communication – the multiple ways to pass data
from one thread to another and also synchronize threads through the use of Mutexs and Events.
Several other communication methods are discussed as well as shown below…
.

Objectives

Objectives

 Describe HOW to share resources

between threads on a single-core DSP
 Compare different use cases (concurrent
access vs. producer/consumer model)
 Analyze several BIOS building blocks for
data sharing and signaling
 Identify where semaphores can be a good
choice vs. where they produce problems

C6000 Embedded Design Workshop Using SYS/BIOS - Inter-thread Communication 7-1

Module Topics

Module Topics
Inter-thread Communication ....................................................................................................................7-1
Module Topics..........................................................................................................................................7-2
Overview of the Problem..........................................................................................................................7-3
Producer – Consumer Model ...................................................................................................................7-4
Introduction .........................................................................................................................................7-4
Events ..................................................................................................................................................7-5
Queues .................................................................................................................................................7-6
Mailboxes ............................................................................................................................................7-7
Advanced Issue-Reclaim Services .......................................................................................................7-8
Concurrent Access Model ........................................................................................................................7-9
Introduction .........................................................................................................................................7-9
Using Globals ....................................................................................................................................7-10
Critical Resource Protection (Enter/Exit Gates) ................................................................................7-10
Modifying Scheduler Behavior..........................................................................................................7-11
Using MUTEXs .................................................................................................................................7-11
Shared Semaphores (Semaphore Queue) ...........................................................................................7-12
Priority Inversion ...............................................................................................................................7-12
Modifying Task Priority Using Task_setPri() ...................................................................................7-13
Using MUTEX Gates ........................................................................................................................7-13
Understanding Deadlock ...................................................................................................................7-14
Threads at SAME Priority......................................................................................................................7-15
Chapter Quiz ..........................................................................................................................................7-16
Additional Information...........................................................................................................................7-17
Notes ......................................................................................................................................................7-18

7-2 C6000 Embedded Design Workshop Using SYS/BIOS - Inter-thread Communication

 Overview of the Problem

Overview of the Problem

Sharing Data Between Threads - Problem

 What are common ways that threads share resources?

Thread A Data Thread B

 Just use Globals and don’t worry about it !!

 Come on, mutex’s are better. They are easy and we use
them all the time. They cause no problems.
 What problems can occur when using globals/mutex’s?

 Well, since we’re in the SYS/BIOS workshop, there must

be some services this RTOS provides to help us…

Yes, BIOS can help...but let's first look at the types of "sharing" that are possible...

Resource Sharing – Two Types

 “Producer – Consumer” Model

Thread A Msg
Thread B

BIOS “Container”
• Thread A produces a buffer or Msg and places it in a container.
• Thread B blocks until it is available, then consumes it when signaled (no contention)
• Data communication is achieved using BIOS “containers” (objects)

 “Concurrent Access” Model Resource = Data or Peripheral

Thread A Resource Thread B

• Any thread could access “Resource” at any time (no structured protocol or container)
• Pre-emption of one thread by another can cause contention or priority inversion

Let's look at the producer-consumer model first...

6

C6000 Embedded Design Workshop Using SYS/BIOS - Inter-thread Communication 7-3

Producer – Consumer Model

Producer – Consumer Model

Introduction

Producer – Consumer Model – Intro

Thread A Msg Thread B
produce consume
BIOS
“Container”
How it Works:
 Data is UNIDIRECTIONAL – one thread waits for the other to produce
 Thread B often BLOCKS until data is produced

Advantages:
 Both threads use same protocol – contention is often avoided
 Threads become more “modular” and therefore reuse improves

Examples:
 BIOS: Queue, Mailbox, Stream I/O
 May have built-in synchronization or user can add signaling via
Semaphores and Events (discussed next…)
8

7-4 C6000 Embedded Design Workshop Using SYS/BIOS - Inter-thread Communication

 Producer – Consumer Model

Events

Using Events (New in SYS/BIOS)

Hwi 5 Post EV0 EV0 myTask
EV1 mask = EV0 + EV2 + EV5;
Post EV2 while(1)
Hwi 7 EV2 { // “simplified” ver
EV3
AND Event_pend (mask);
OR // do work
EV4
Post EV5 }
Hwi 9 EV5

 Semaphore_pend()only waits on one flag – a semaphore.

 What if you want to “unblock” based on multiple events?
 Use Events. Can OR or AND event IDs with bit masks
 Events are “binary semaphores”. Only one Task can block on one
Evt object at a time.
What about "implicit posts" ?
 The key “Explicit Post” and Pend APIs are:
Event_post (&Evt, Event_Id_xx);
Event_pend (&Evt, andMask, orMask, timeout);
10

Implicit “Event Post”

Semaphore Post EV0 EV0 myTask
EV1 mask = EV0 + EV2 + EV5;
Post EV2 while(1)
Mailbox EV2 { // “simplified” ver
EV3
AND Event_pend (mask);
OR // do work
EV4
Post EV5 }
MessageQ EV5

 Other APIs, as shown above, can also post events – implicitly – the
eventId is part of the params structure:

Specify Event
Id here…

 So, even a standard Semaphore_post(Sem) can post an event !

Note: see “Event” example under SYS/BIOS Templates 11

C6000 Embedded Design Workshop Using SYS/BIOS - Inter-thread Communication 7-5

Producer – Consumer Model

Queues

Queue Concepts…

Thread A put Msg1 Msg2 Msg3 get Thread B

Queue
 A Queue is a BIOS object that can contain anything you like
 “Data” is called a “Msg” and is simply a structure defined by the user
 Msgs are “reclaimed” on a FIFO basis
 Key APIs:
Queue_put();
Queue_get();

 Advantages: simple, not copy based

 Disadvantage: no signaling built in
How would you synchronize the writer and reader?
13

Synchronizing Queues…

Thread A put Msg1 Msg2 Msg3 get Thread B

Queue

 Use a Semaphore to synchronize writer/reader:

TALKER LISTENER
Queue_put(&myQ, msg); Semaphore_pend(&Sem, -1);
Semaphore_post(&Sem); msg = Queue_get(&myQ);

Note: “Queue+Sem” is the basis for how “streams” are built to interface with I/O drivers –
e.g. Platform Support Package (PSP) drivers from TI. (More in a later chapter…)

Let's see how Queues are used in a system...

14

7-6 C6000 Embedded Design Workshop Using SYS/BIOS - Inter-thread Communication

 Producer – Consumer Model

Using Queues in a System…

 User Setup:
A. Declare Queue in CFG
struct myMsg {
B. Define (typedef) structure of Msg Queue_Elem elem;
short *pInBuf;
C. Fill in the Msg – i.e. define “elements” short *pOutBuf;
D. Send/receive data from the queue } Msg;

 Example – RCV side of peripheral driver (Hwi):

1. Double Buffer System – main init puts TWO Msgs in toDevQ
2. HWI gets EMPTY Buffer from toDevQ (and fills it up with data)
3. HWI puts FULL Buffer into toTSKQ (gets next EMPTY) main
4. TSK gets FULL buffer from toTSKQ (process) put
1
put
5. TSK puts EMPTY buffer into toDevQ

Note: two Queues allow Msgs to get 2 toHwi 5 put

circulate between threads.
toHwi = EMPTY, toTSK =FULL Hwi Task
put 3 toTSK 4 get
15

Mailboxes

Using Mailboxes

Thread A post Msg1 Msg2 Msg3 pend Thread B

Mailbox
 Mailboxes – a fixed-size BIOS Object that can contain anything you like
 Fixed length defined by:
• Number of Msgs (length of mailbox)
• Message Size (MAUs)
 Key APIs (both can block):
Mailbox_post (&Mbx, &Msg, timeout); // blocks if full
Mailbox_pend (&Mbx, &Mail, timeout); // blocks if empty

 Advantages: simple FIFO, easy to use, contains built-in semaphore for signaling
 Disadvantage: copy-based (both reader/writer own a copy) – best if used to pass
pointers or small Msgs
Advanced producer/consumer uses...
17

C6000 Embedded Design Workshop Using SYS/BIOS - Inter-thread Communication 7-7

Producer – Consumer Model

Advanced Issue-Reclaim Services

Advanced “Producer-Consumer” Services
 More advanced versions of the “producer-consumer” model are built
into SYS/BIOS and other drivers/frameworks:
Platform Support Package (PSP) Drivers
• Issue/Reclaim buffers to/from a STREAM (input and output Queues)

Messaging between cores (DSP  DSP, ARM  DSP)

• Lowest layer uses BIOS MessageQ (similar to Queue’s
Codec Engine
but trans-processor)
• SysLink is a layer above MessageQ – a driver ported to Linux SysLink/IPC
and SYS/BIOS
• Codec Engine (CE) is an algorithm framework built on top of SysLink MessageQ
to provide users with the ultimate flexibility of launching algos on the
DSP (SYS/BIOS) from the ARM (Linux)
Optional chapters and another 4-day workshop address these topics in detail
19

7-8 C6000 Embedded Design Workshop Using SYS/BIOS - Inter-thread Communication

 Concurrent Access Model

Concurrent Access Model

Introduction

“Concurrent Access” Model – Intro

Thread A Data Thread B

How it Works:
 Data is “up for grabs” – often first-come, first-serve
 User must add “protection” to avoid contention between different priority threads

Advantages:
 Common usage – many systems use MUTEXs for resource protection

Disadvantages:
 MUTEXs can cause priority inversion or deadlock – both ugly scenarios
 Modifying scheduler behavior (e.g. disabling INTs) can cause jitter in the system

Examples:
 BIOS: Scheduler Mgmt, Gates, MUTEX (Semaphore), Task_setPri
 Note: watch out for “globals” accessed by multiple threads w/no protection…

Let's first look at a simple use of globals...

21

C6000 Embedded Design Workshop Using SYS/BIOS - Inter-thread Communication 7-9

Concurrent Access Model

Using Globals

What’s Wrong With Using Globals ??

 If two threads share a global, what’s the problem?
Thread A (hi) Thread B (lo)
void A (void) { void B (void) {
… …
cnt += 1; cnt += 1;
LD
ADD
ST
} }

 What happens if Thread B gets pre-empted by A?

 The assembly code underneath does LD, ADD, ST…
 B could store the wrong value…
What methods can be used to solve this problem?
23

Critical Resource Protection (Enter/Exit Gates)

Critical Resource Protection

 Some sort of PROTECTION mechanism has to be used to
protect threads from conflict when sharing a resource
 In simple terms, let’s define CRITICAL SECTION as the time
when the SHARED RESOURCE is being accessed:
Enter Exit

Thread
CRITICAL SECTION

 For example, if a Task and Hwi are sharing a resource, the

GATE, or Enter/Exit commands in the Task might be:
Enter (Global INT = OFF) Exit (Global INT = ON)

Task
CRITICAL SECTION
 MUTEXs, between Tasks, could also be used during Enter/Exit
What other forms of “protection” exist? 24

7 - 10 C6000 Embedded Design Workshop Using SYS/BIOS - Inter-thread Communication

 Concurrent Access Model

Modifying Scheduler Behavior

Modifying BIOS Scheduler Behavior

 “When in doubt, just turn off interrupts !”
 This might sound funny…but it is a common method to solve contention
problems in systems
 Modifying the scheduler’s behavior is the ONLY solution for Hwi/Swi:
Usage (Notice Enter/Exit gates)
Hwi_disable(); turn off global INTs
void B (void)
Hwi_restore(); restore global INTs
{ . . .
Swi_disable(); turn off all Swi’s
pGIE = Hwi_disable();
Swi_restore(); restore Swi’s cnt += 1; //critical
Task_disable(); turn off all Tasks Hwi_restore(pGIE);
Task_restore(); restore Tasks . . .
Task_setPri(); Set Task Pri }

 Advantages: common, simple  Disadvantages: can cause jitter, latency

26

Using MUTEXs

Using MUTEXs
Thread A Data Thread B

 MUTEX = Mutually Exclusive (only one thread at a time)

 Mutex is commonly used in systems to protect a critical resource
being accessed by multiple threads
 Users can create a mutex using semaphores with an initial count of 1
Task Hi Task Low
Semaphore_pend(Sem); Semaphore_pend(Sem);
Semaphore: Sem
Initial Count = 1 D D
Semaphore_post(Sem); Semaphore_post(Sem);

 Advantages: common, simple

 Disadvantage: can cause priority inversion
Shared semaphores can cause problems...
28

C6000 Embedded Design Workshop Using SYS/BIOS - Inter-thread Communication 7 - 11

Concurrent Access Model

Shared Semaphores (Semaphore Queue)

Shared Semaphores…
INT! post
Hwi
Enter (pend)
INT!
BLOCKED !! ACCESS
TSK Hi
Enter (pend) Exit (post)
block ACCESS
TSK Lo

 MUTEX = TSK Hi and TSK Lo pend on the SAME semaphore

 Pending threads are placed in a FIFO semaphore queue:
READY TSK Lo TSK Hi …

 Therefore, TSK Lo runs first. This is ok, but CAN lead to priority inversion…
What if some TSK MEDiums were living in the system?
29

Priority Inversion

Priority Inversion
INT! Post (sems)
Hwi
Enter (pend)
INT!
BLOCKED !!
TSK Hi

RUN !
TSK MED
Enter (pend)
block
TSK Lo

 TSK MED (and all other priorities between Hi and Lo) get to RUN first
 Then, TSK Lo runs before TSK Hi because Lo pended on Sem first
 TSK Hi is VERY FRUSTRATED
What could you do with TSK Lo’s priority just
before the “Enter” to avoid this priority inversion?
30

7 - 12 C6000 Embedded Design Workshop Using SYS/BIOS - Inter-thread Communication

 Concurrent Access Model

Modifying Task Priority Using Task_setPri()

Temporarily Elevate Priority – Task_setPri()

Hwi
INT!
Ready Running (data access) !!
TSK Hi
Enter - setPri(Hi) Exit - setPri(Lo)
data access pre-empted
TSK Lo

 TSK Lo can elevate its priority just before data access and then
lower its priority just after data access using: Task_setPri();
 Advantage: no semaphore/mutex required !

Mutex Priority Gates can come in handy for situations like this…
31

Using MUTEX Gates

Mutex Gates
INT! enter leave
run block data
TSK Hi
enter leave
Lo inherits
Hi’s Pri
data pre-empted pre-empted
TSK Lo
data

 Mutex gates work similar to the Hwi/Swi/Task gates discussed earlier

 Use the following code in BOTH (TSK Hi and TSK Lo)
gateKey = GateMutexPri_enter(gateMutexPri); // enter Gate
cnt += 1; // protected access
GateMutexPri_leave(gateMutexPri, gateKey); // exit Gate

 TSK Lo inherits priority of TSK Hi if TSK Hi requests resource access (enter)

 Advantages: simple to code, does automatic Task_setPri() of TSK Lo
GateMutex also available (similar to standard Mutex usage)
33

C6000 Embedded Design Workshop Using SYS/BIOS - Inter-thread Communication 7 - 13

Concurrent Access Model

Understanding Deadlock

How DEADLOCK Can Occur…

Data
Thread A Thread B
Data

 Deadlock occurs when two threads block each other (stalemate)

 Conditions for deadlock include:
• Use of MUTEX with multiple resources (with circular pending)
• Threads at different priorities

Task A Task B Solutions:

Sem_pend(res_1); Sem_pend(res_2); • Use timeouts on _pend
// use resource1 // use resource1
STUCK ? STUCK ? • Eliminate circular _pend
Sem_pend(res_2); Sem_pend(res_1); • Lock one resource at a
// use resource2 // use resource1 time, or ALL of them
Sem_post(res_1); Sem_post(res_2);
Sem_post(res_2); Sem_post(res_1);

35

7 - 14 C6000 Embedded Design Workshop Using SYS/BIOS - Inter-thread Communication

 Threads at SAME Priority

Threads at SAME Priority

Threads At SAME Priority
Thread A Data Thread B
Pri = X Pri = X

 Can threads at the SAME priority pre-empt each other? NO !

 So, it is a good idea to place threads that share a critical resource
AT THE SAME PRIORITY. Life is good…
 Advantages galore:
• Built-in FIFO scheduling (no pre-emption or scheduler mods)
• No signaling required (no Semaphore, no blocking)
• Less memory/time overhead for pre-emption (context switch)
• No corruption or contention – easy to maintain
• VERY simple – solves ALL types of critical resource sharing problems
(e.g. priority inversion and deadlock)

Note: watch out for “Murphy” if someone changes priorities !

37

C6000 Embedded Design Workshop Using SYS/BIOS - Inter-thread Communication 7 - 15

Chapter Quiz

Chapter Quiz
Chapter Quiz
1. Name the two basic data sharing models and examples of each:

2. Compare and contrast mailboxes and queues:

3. Which fxn calls are commonly used to modify scheduler behavior?

4. What problems can occur when using MUTEX’s, what is the sol’n?

5. What is the recommended solution for sharing data between threads

where possible?

7 - 16 C6000 Embedded Design Workshop Using SYS/BIOS - Inter-thread Communication

 Additional Information

Additional Information
QUE API Summary
QUE API Description
QUE_put Add a message to end of queue – atomic write
QUE_get Get message from front of queue – atomic read
QUE_enqueue Non-atomic QUE_put
QUE_dequeue Non-atomic QUE_get
QUE_head Returns ptr to head of queue (no de-queue performed)
QUE_empty Returns TRUE if queue has no messages
QUE_next Returns next element in queue
QUE_prev Returns previous element in queue
QUE_insert Inserts element into queue in front of specified element
QUE_remove Removes specified element from queue
QUE_new ….
QUE_create Create a queue
Mod 10
QUE_delete Delete a queue

Example: Passing Buffer Info Via Mailbox

MBX_post - add message to end of mailbox typedef struct MsgObj {
Void writer(Void) Int len;
{ Int * addr;
MsgObj msg; };
Int myBuf[SIZE];
...
msg.addr = myBuf;
msg.len = SIZE*sizeof(Int);
MBX_post(&mbx, &msg, SYS_FOREVER); block if MBX
... is already full
}
handle to msg obj
MBX_pend - get next message from mailbox * msg to put/get
Void reader(Void) timeout
{
MsgObj mail;
Int size, *buf;
... block until
MBX_pend(&mbx, &mail,SYS_FOREVER); mail received
buf = mail.addr; or timeout
size = mail.len;
...
}
43

C6000 Embedded Design Workshop Using SYS/BIOS - Inter-thread Communication 7 - 17

Notes

Notes

7 - 18 C6000 Embedded Design Workshop Using SYS/BIOS - Inter-thread Communication

 Using Dynamic Memory
Introduction
In this chapter, we will compare and contrast static and dynamic systems. The benefit of using
dynamic systems are you create and use the memory when it is needed and then free it back to the
heap when it is not needed any longer. For memory limited targets, this is essential in order to fit
data and code in a smaller footprint.

Objectives

Objectives

 Compare/contrast static and dynamic systems

 Define heaps and describe how to configure them
 Describe how to eliminate the drawbacks of
using std heaps (fragments, non-determinism)
 Implement dynamic object creation
 Lab 8 – Create Semaphores and Tasks dynamically

C6000 Embedded Design Workshop Using SYS/BIOS - Using Dynamic Memory 8-1
Module Topics

Module Topics
Using Dynamic Memory ............................................................................................................................8-1
Module Topics..........................................................................................................................................8-2
Static vs. Dynamic ....................................................................................................................................8-3
Memory Policies ..................................................................................................................................8-3
Dynamic Memory Concepts .....................................................................................................................8-4
Using Dynamic Memory .....................................................................................................................8-4
Creating A Heap ..................................................................................................................................8-6
Different Types of Heaps..........................................................................................................................8-7
HeapMem ............................................................................................................................................8-7
HeapBuf...............................................................................................................................................8-8
HeapMultiBuf ......................................................................................................................................8-9
Default System Heap .........................................................................................................................8-10
Dynamic Module Creation .....................................................................................................................8-11
Using Error Block..............................................................................................................................8-12
Memory/Section Placement (Fine Tuning) ............................................................................................8-13
Chapter Quiz ..........................................................................................................................................8-14
Lab 8 – Using Dynamic Memory ...........................................................................................................8-15
Lab 8 – Using Dynamic Memory – Procedure .................................................................................8-16
Create Project & View New Items ................................................................................................8-16
Modify Platform ............................................................................................................................8-17
Inspect New Dynamic Code ..........................................................................................................8-17
Create ledToggle Task and Semaphore Dynamically ...................................................................8-19
Exploring the HEAP......................................................................................................................8-20
Build, Load, Run. ..........................................................................................................................8-20
Create firProcessTask and mcaspReady Dynamically ..................................................................8-21
Build, load and Run.......................................................................................................................8-21
That’s It. You’re Done !!...............................................................................................................8-21
Notes ......................................................................................................................................................8-22

8-2 C6000 Embedded Design Workshop Using SYS/BIOS - Using Dynamic Memory
 Static vs. Dynamic

Static vs. Dynamic

Memory Policies

C6000 Embedded Design Workshop Using SYS/BIOS - Using Dynamic Memory 8-3
Dynamic Memory Concepts

Dynamic Memory Concepts

Using Dynamic Memory

Dynamic Example (Heap)

“Normal” (static) C Coding “Dynamic” C Coding

#define SIZE 32 #define SIZE 32

char x[SIZE]; /*allocate*/ Create x=malloc(SIZE); // MAUs
char a[SIZE]; a=malloc(SIZE); // MAUs
x={…}; /*initialize*/ x={…};
a={…}; a={…};

filter(…); /*execute*/ Execute filter(…);

Delete free(x);
free(a);

 High-performance DSP users have traditionally used static embedded systems

 As DSPs and compilers have improved, the benefits of dynamic systems often allow
enhanced flexibility (more threads) at lower costs
9

8-4 C6000 Embedded Design Workshop Using SYS/BIOS - Using Dynamic Memory
 Dynamic Memory Concepts

C6000 Embedded Design Workshop Using SYS/BIOS - Using Dynamic Memory 8-5
Dynamic Memory Concepts

Creating A Heap

8-6 C6000 Embedded Design Workshop Using SYS/BIOS - Using Dynamic Memory
 Different Types of Heaps

Different Types of Heaps

HeapMem

C6000 Embedded Design Workshop Using SYS/BIOS - Using Dynamic Memory 8-7
Different Types of Heaps

HeapBuf

8-8 C6000 Embedded Design Workshop Using SYS/BIOS - Using Dynamic Memory
 Different Types of Heaps

HeapMultiBuf

C6000 Embedded Design Workshop Using SYS/BIOS - Using Dynamic Memory 8-9
Different Types of Heaps

Default System Heap

8 - 10 C6000 Embedded Design Workshop Using SYS/BIOS - Using Dynamic Memory

 Dynamic Module Creation

Dynamic Module Creation

C6000 Embedded Design Workshop Using SYS/BIOS - Using Dynamic Memory 8 - 11

Dynamic Module Creation

Using Error Block

8 - 12 C6000 Embedded Design Workshop Using SYS/BIOS - Using Dynamic Memory

 Memory/Section Placement (Fine Tuning)

Memory/Section Placement (Fine Tuning)

Placing a Specific Section into Memory
 Via the Platform File (hi-level, but works fine):

 Via the app.cfg GUI (finer control):

• SYS/BIOS GUI now supports specific placements of sections (like .far, .bss, etc.)
into specific memory segments (like IRAM, DDR, etc.):

GUI

CFG script
32

Placing “Heaps” in Memory

 Create a new heap (heapBuf64) and section name (.heapBuf64):

 Place new section name via:

 Script code added:

33

C6000 Embedded Design Workshop Using SYS/BIOS - Using Dynamic Memory 8 - 13

Chapter Quiz

Chapter Quiz
Chapter Quiz
1. Compare/Contrast static/dynamic memory use and when to use each:

2. Which features has BIOS added to the common malloc() function?

3. Name the heap types and common use of each?

4. Can you create BIOS threads and modules during runtime? If so, how?

5. Explain the operation of the error block?

8 - 14 C6000 Embedded Design Workshop Using SYS/BIOS - Using Dynamic Memory

 Lab 8 – Using Dynamic Memory

Lab 8 – Using Dynamic Memory

In this lab, you will modify the previous lab by creating the Tasks and Semaphore dynamically
vs. statically. This will entail deleting the static configurations and writing some code to perform
these actions dynamically – during runtime.
You will have a chance to inspect the heap usage in ROV along the way as well.

C6000 Embedded Design Workshop Using SYS/BIOS - Using Dynamic Memory 8 - 15

Lab 8 – Using Dynamic Memory

Lab 8 – Using Dynamic Memory – Procedure

Create Project & View New Items
1. Delete any existing projects from your workspace.
2. Create a new SYS/BIOS project in \Lab8\Project.

So, it’s been awhile – do you remember how? Name the project “dyn_audio” and create
the project in the above folder. As a reminder, don’t forget the following steps:

• Create a new project called “dyn_audio”

• Create the project in the \Lab8\Project folder (NOT the default workspace)
• Set the device family and variant for C674x
• Check the advanced settings and make sure they are correct (latest compiler version)
• Select a SYS/BIOS template – TYPICAL (note: this will add an app.cfg and
main.c file to your project that you will need to DELETE when finished creating
your project)
• After clicking Next, choose the latest SYS/BIOS version and point to your
_student platform you created earlier. Note: you must add the repository path for
your platforms to the current list to see the _student platform. When done, Click
Finish.
• Delete main.c and app.cfg files in your project view – these were provided with
the SYS/BIOS Typical template – we don’t need them (we will replace these shortly).
• Link in the BSL library and add the include path for this library (refer to Lab 3
procedure if you don’t remember how…)
• Using Windows Explorer, copy all the files from the Lab8\Files folder to
Lab8\Project folder (they will then magically show up in your CCS Project
View).
After all of this is done, your project should look like this:

8 - 16 C6000 Embedded Design Workshop Using SYS/BIOS - Using Dynamic Memory

 Lab 8 – Using Dynamic Memory

Modify Platform
3. Ensure you are using the correct platform.
Access the RTSC configuration via Properties  General  RTSC tab. If the custom
platform repository (\Labs\SYSBIOS_Platforms) is not added to the list (beneath
XDAIS), add it. If it is there, change the platform file to the one you created in the previous
labs (the STUDENT version) – the one that places all code/data/stacks in IRAM.

Hint: The Logic PD BSL functions that use I2C (namely LED, DIP, etc) are so inefficient that
they have a hard time running reliably out of DDR. This is why we keep using IRAM vs.
DDR in the platform once we added those capabilities.

4. Build, load, run, verify.

Power-cycle your board. Then, build the project and run it. Make sure the audio is working
correctly and the LED is blinking. This is essentially the solution for your previous lab. If
everything is fine, move on…

Inspect New Dynamic Code

5. Inspect the changes to main.c.
Open main.c for editing. In order to create Tasks and Semaphores dynamically, we need to
write a small portion of code which includes a few globals and then the actual creation code
in main().

Near the top of the file, observe the following globals for the Task and Semaphore handles:

They are currently commented out, but we will “uncomment” them as the need arises.

C6000 Embedded Design Workshop Using SYS/BIOS - Using Dynamic Memory 8 - 17

Lab 8 – Using Dynamic Memory

Browse down further to see the top of main():

This is where all the action is. This code is NOT COMPLETE. Most of it is there, but you’ll
need to edit some of it and uncomment lines of code as the lab progresses.

The first two chunks of code create the Semaphore and Task for ledToggle.

The 2nd two pieces of code do the same for our FIR_process() function and Semaphore.
What we plan to do is ONE AT A TIME. We’ll get the ledToggle working dynamically
first, then do the same thing for FIR_process and mcaspReady.

8 - 18 C6000 Embedded Design Workshop Using SYS/BIOS - Using Dynamic Memory

 Lab 8 – Using Dynamic Memory

6. Inspect main.h.
The only items in main.h are the externs for the global variables:

Again, we’ll uncomment these as we move onward.

Create ledToggle Task and Semaphore Dynamically

7. Delete static configuration for ledToggleTask and ledToggleSem.
Before deleting the Task, write down the values for ledToggleTask below:
fxn: ____________
priority: _______
In dyn.cfg, delete the Task – ledToggleTask. Also, delete the Semaphore –
ledToggleSem.

8. Edit main.c and uncomment code to create ledToggle Task and Semaphore.
Open main.c and uncomment the global declarations for ledToggleTask and
ledToggleSem. These create our handles to these two objects.

Next, uncomment the first line of code in main():

This creates a structure called taskParams that holds the parameters for a Task – namely
priority and other items you can set dynamically. We will use it in this lab only to set priority.

Next, uncomment the line of code that creates ledToggleSem. Modify the name “Sem” to
use the proper name. We are setting the initial semaphore count to 0.

Now, uncomment the three lines of code that create ledToggleTask. Modify the priority
number and name of the function that this Task object is pointing to. If you can’t figure this
out, just think about what you used in the STATIC configuration – it’s the same stuff.
9. Open main.h and uncomment a few lines.
In main.h, uncomment the two externs for ledToggleSem and ledToggleTask.

C6000 Embedded Design Workshop Using SYS/BIOS - Using Dynamic Memory 8 - 19

Lab 8 – Using Dynamic Memory

Exploring the HEAP

10. Determine where the heap settings are and the current heap size.
In dyn.cfg, click on the BIOS module and then click the Runtime button:

This is where the default heap size is set – 4K or 0x1000. Up above, you’ll notice that the
default instance creation is set to dynamic creation and deletion – which ALSO supports
static configuration. In the author’s opinion, there is never a need to change this – even if
you’re static only – like we have been until this lab.

So, when we look at ROV shortly, we’ll see the Heap size at 0x1000 and, if things work
properly, we should see some of that heap used for our dynamic Task and Semaphore we
created.

Hint: In the current tools shipped with CCS5.1, you can also see the Heap size listed under the
Program module. It is always ZERO and does NOT reflect the setting under BIOS
Runtime. This can be confusing to new users. So, just stick with the BIOS module in
the Outline View for heaps and you’re fine. Just FYI…

Build, Load, Run.

11. Build, load, run, verify program.
Go ahead. Is the audio running? LED blinking? Well, if the LED is blinking, you have
successfully created a dynamic thread (Task) and Semaphore. This is way cool. Congrats.
Halt your program and open ROV. Click on HeapMem  Detailed Tab.

What is the total size of the heap? 0x_________

What is the total FREE size? 0x________

Notice anything alarming about these sizes? ___________________ Ok. So we now proved
that the heap is being used for our stuff. Let’s do it again with FIR_process()…

8 - 20 C6000 Embedded Design Workshop Using SYS/BIOS - Using Dynamic Memory

 Lab 8 – Using Dynamic Memory

Create firProcessTask and mcaspReady Dynamically

12. Follow the same procedure to dynamically create the Task (firProcessTask) and
Semaphore (mcaspReady).
As a reminder:
• Delete the static configurations for the Task and Semaphore
• In main.c, uncomment the global declarations and the 4 lines of code in main().
Don’t forget to change “Sem”, set the Task priority and the Task fxn name.
• In main.h, uncomment the externs.

Build, load and Run

13. Do it.
Did it work? Get an error? What do you think the problem is?
Wow. Not enough heap memory for two semaphores and two Tasks? There was a clue earlier
that this might happen. The previous time you wrote down sizes, was the size LEFT less than
half the total size? Yep. So, a combo of a Semaphore and a Task object take up 2K+ bytes in
memory.
14. Increase the heap size.
Modify the heap size to 8192. Rebuild, run. It should work fine this time. Open ROV and
check the total size and the free size:
Total size: 0x________
Free size: 0x________
15. Conclusions.
So, what’s better – static or dynamic memory models? Honestly, it is sometimes a conscious
choice and other times it is dictated by the system requirements and limited memory options.
If you have many items you’d like to run on-chip, but have limited resources, a dynamic
system might fit your needs. However, if you never FREE memory back to the heap, well,
that’s kind of like a static system. For smaller memory targets (like MSP430) where all
threads live for the life of the program, static is THE way to go. If you have a more complex
system and a larger memory footprint, dynamic memory may fit nicely.
The great news is that SYS/BIOS supports both. The system designer can freely choose either
or a combination of the two.

That’s It. You’re Done !!

16. Terminate the session, close the project and close CCS. Power cycle the board.

You’re finished with this lab. RAISE YOUR HAND AND SAY “DONE !!” so
the instructor knows – thanks. If the instructor pays you no attention or acts
like he doesn’t care, make sure you note that on the review form later. 

C6000 Embedded Design Workshop Using SYS/BIOS - Using Dynamic Memory 8 - 21

Notes

Notes

8 - 22 C6000 Embedded Design Workshop Using SYS/BIOS - Using Dynamic Memory

 C64x+/C674x+ CPU Architecture
Introduction
In this chapter, we will take a deeper look at the C64x+ architecture and assembly code. The
point here is not to cover HOW to write assembly – it is just a convenient way to understand the
architecture better.

Outline

Objectives

 Provide a detailed overview of the

C64x+/C674x CPU architecture
 Describe the basic ASM language
and h/w needed to solve a SOP
 Analyze how the hardware
pipeline works
Learn basics of software pipelining

C6000 Embedded Design Workshop Using BIOS - C64x+/C674x+ CPU Architecture 9-1
Module Topics

Module Topics
C64x+/C674x+ CPU Architecture .............................................................................................................9-1
Module Topics..........................................................................................................................................9-2
C64x+ CPU Architecture ........................................................................................................................9-3
What Does a DSP Do?.........................................................................................................................9-3
CPU – From the Inside…Out ..............................................................................................................9-4
Instruction Sets ......................................................................................................................................9-10
“MAC Instructions”...............................................................................................................................9-12
C66x MAC Instructions (whoa !) ...........................................................................................................9-14
Hardware Pipeline .................................................................................................................................9-15
Software Pipelining ................................................................................................................................9-16
Instruction Delays ..............................................................................................................................9-16
Scheduling an Algorithm ...................................................................................................................9-16
Resulting Pipelined Code… ..............................................................................................................9-17
Chapter Quiz ..........................................................................................................................................9-18

9-2 C6000 Embedded Design Workshop Using BIOS - C64x+/C674x+ CPU Architecture
 C64x+ CPU Architecture

C64x+ CPU Architecture

What Does a DSP Do?

C6000 Embedded Design Workshop Using BIOS - C64x+/C674x+ CPU Architecture 9-3
C64x+ CPU Architecture

CPU – From the Inside…Out

9-4 C6000 Embedded Design Workshop Using BIOS - C64x+/C674x+ CPU Architecture
 C64x+ CPU Architecture

C6000 Embedded Design Workshop Using BIOS - C64x+/C674x+ CPU Architecture 9-5
C64x+ CPU Architecture

9-6 C6000 Embedded Design Workshop Using BIOS - C64x+/C674x+ CPU Architecture
 C64x+ CPU Architecture

C6000 Embedded Design Workshop Using BIOS - C64x+/C674x+ CPU Architecture 9-7
C64x+ CPU Architecture

9-8 C6000 Embedded Design Workshop Using BIOS - C64x+/C674x+ CPU Architecture
 C64x+ CPU Architecture

C6000 Embedded Design Workshop Using BIOS - C64x+/C674x+ CPU Architecture 9-9
Instruction Sets

Instruction Sets

9 - 10 C6000 Embedded Design Workshop Using BIOS - C64x+/C674x+ CPU Architecture

 Instruction Sets

C6000 Embedded Design Workshop Using BIOS - C64x+/C674x+ CPU Architecture 9 - 11

“MAC Instructions”

“MAC Instructions”

9 - 12 C6000 Embedded Design Workshop Using BIOS - C64x+/C674x+ CPU Architecture

 “MAC Instructions”

Complex Multiply (CMPY)

A0 r1 i1
x x
A1 r2 i2
= =
CMPY A0, A1, A3:A2 r1*r2 - i1*i2 : i1*r2 + r1*i2
32-bits 32-bits

single .M unit

 Four 16x16 multiplies per .M unit

 Using two CMPYs, a total of eight 16x16 multiplies per cycle
 Floating-point version (CMPYSP) uses:
 64-bit inputs (register pair)
 128-bit packed products (register quad)
 You then need to add/subtract the products to get the final result
28

C6000 Embedded Design Workshop Using BIOS - C64x+/C674x+ CPU Architecture 9 - 13

C66x MAC Instructions (whoa !)

C66x MAC Instructions (whoa !)

9 - 14 C6000 Embedded Design Workshop Using BIOS - C64x+/C674x+ CPU Architecture

 Hardware Pipeline

Hardware Pipeline

C6000 Embedded Design Workshop Using BIOS - C64x+/C674x+ CPU Architecture 9 - 15

Software Pipelining

Software Pipelining
Instruction Delays

Scheduling an Algorithm

9 - 16 C6000 Embedded Design Workshop Using BIOS - C64x+/C674x+ CPU Architecture

 Software Pipelining

Resulting Pipelined Code…

C6000 Embedded Design Workshop Using BIOS - C64x+/C674x+ CPU Architecture 9 - 17

Chapter Quiz

Chapter Quiz
Chapter Quiz
1. Name the four functional units and types of instructions they execute:

2. How many 16x16 MACs can a C674x CPU perform in 1 cycle? C66x ?

3. Where are CPU operands stored and how do they get there?

4. What is the purpose of a hardware pipeline?

5. What is the purpose of s/w pipelining, which tool does this for you?

9 - 18 C6000 Embedded Design Workshop Using BIOS - C64x+/C674x+ CPU Architecture

 C and System Optimizations
Introduction
In this chapter, we will cover the basics of optimizing C code and some useful tips on system
optimization. Also included here are some other system-wide optimizations you can take
advantage of in your own application – if they are necessary.

Outline

Objectives

 Describe how to configure and use the

various compiler/optimizer options
 Discuss the key techniques to increase
performance or reduce code size
 Demonstrate how to use optimized libraries
 Overview key system optimizations
 Lab 10 – Use FIR algo on audio data,
optimize using the compiler, benchmark

C6000 Embedded Design Workshop Using BIOS - C and System Optimizations 10 - 1

Module Topics

Module Topics
C and System Optimizations ...................................................................................................................10-1
Module Topics........................................................................................................................................10-2
Introduction – “Optimal” and “Optimization” .....................................................................................10-3
C Compiler and Optimizer .....................................................................................................................10-5
“Debug” vs. “Optimized” ..................................................................................................................10-5
Levels of Optimization ......................................................................................................................10-6
Build Configurations .........................................................................................................................10-7
Code Space Optimization (–ms) ........................................................................................................10-7
File and Function Specific Options ...................................................................................................10-8
Coding Guidelines .............................................................................................................................10-9
Data Types and Alignment ...................................................................................................................10-10
Data Types .......................................................................................................................................10-10
Data Alignment ...............................................................................................................................10-11
Using DATA_ALIGN .....................................................................................................................10-12
Upcoming Changes – ELF vs. COFF ..............................................................................................10-13
Restricting Memory Dependencies (Aliasing)......................................................................................10-14
Access Hardware Features – Using Intrinsics .....................................................................................10-16
Give Compiler MORE Information ......................................................................................................10-17
Pragma – Unroll() ............................................................................................................................10-17
Pragma – MUST_ITERATE() .........................................................................................................10-18
Keyword - Volatile ..........................................................................................................................10-18
Setting MAX interrupt Latency (-mi option) ...................................................................................10-19
Compiler Directive - _nassert() .......................................................................................................10-20
Using Optimized Libraries ...................................................................................................................10-21
Libraries – Download and Support ..................................................................................................10-23
System Optimizations ...........................................................................................................................10-24
BIOS Libraries.................................................................................................................................10-24
Custom Sections ..............................................................................................................................10-26
Use Cache ........................................................................................................................................10-27
Use EDMA ......................................................................................................................................10-28
System Architecture – SCR .............................................................................................................10-29
Chapter Quiz ........................................................................................................................................10-30
Lab 10 – C Optimizations ....................................................................................................................10-31
Lab 10 – C Optimizations – Procedure................................................................................................10-32
PART A – Goals and Using Compiler Options ...............................................................................10-32
Determine Goals and CPU Min...................................................................................................10-32
Using Debug Configuration (–g, NO opt) ...................................................................................10-33
Using Release Configuration (–o2, no –g) ..................................................................................10-34
Using “Opt” Configuration .........................................................................................................10-36
Part B – Code Tuning ......................................................................................................................10-38
Part C – Minimizing Code Size (–ms) .............................................................................................10-41
Part D – Using DSPLib ...................................................................................................................10-42
Conclusion .......................................................................................................................................10-43
Additional Information.........................................................................................................................10-44

10 - 2 C6000 Embedded Design Workshop Using BIOS - C and System Optimizations

 Introduction – “Optimal” and “Optimization”

Introduction – “Optimal” and “Optimization”

Know Your Goal and Your Limits…

count

Y = Σ coeffi * xi
for (i = 0; i < count; i++){
Y += coeff[i] * x[i]; }
i = 1

Goals:
 A typical goal of any system’s algo is to meet real-time
 You might also want to approach or achieve “CPU Min” in
order to maximize #channels processed
CPU Min (the “limit”):
 The minimum # cycles the algo takes based on architectural
limits (e.g. data size, #loads, math operations required)

Real-time vs. CPU Min

 Often, meeting real-time only requires setting a few compiler options (easy)
 However, achieving “CPU Min” often requires extensive knowledge
of the architecture (harder, requires more time)
6

C6000 Embedded Design Workshop Using BIOS - C and System Optimizations 10 - 3

Introduction – “Optimal” and “Optimization”

10 - 4 C6000 Embedded Design Workshop Using BIOS - C and System Optimizations

 C Compiler and Optimizer

C Compiler and Optimizer

“Debug” vs. “Optimized”

“Debug” vs. “Optimized” – Benchmarks

FIR
for (j = 0; j < nr; j++) {
sum = 0;
Dot Product
for (i = 0; i < nh; i++) for (i = 0; i < count; i++){
sum += x[i + j] * h[i]; Y += coeff[i] * x[i]; }
r[j] = sum >> 15;
}

Benchmarks:
Algo FIR (256, 64) DOTP (256-term)
Debug (no opt, –g) 817K 4109
“Opt” (-o3, no –g) 18K 42
Add’l pragmas 7K 42
(DSPLib) 7K 42
CPU Min 4096 42
 Debug – get your code LOGICALLY correct first (no optimization)
 “Opt” – increase performance using compiler options (easier)
 “CPU Min” – it depends. Could require extensive time… 10

“Debug” vs. “Optimized” – Environments

“Debug” (–g, NO opt): Get Code Logically Correct
 Provides the best “debug” environment with full symbolic
support, no “code motion”, easy to single step
 Code is NOT optimized – i.e. very poor performance
 Create test vectors on FUNCTION boundaries (use same
vectors as Opt Env)

“Opt” (–o3, –g ): Increase Performance

 Higher levels of “opt” results in code motion – functions
become “black boxes” (hence the use of FXN vectors)
 Optimizer can find “errors” in your code (use volatile)
 Highly optimized code (can reach “CPU Min” w/some algos)
 Each level of optimization increases optimizer’s “scope”…
11

C6000 Embedded Design Workshop Using BIOS - C and System Optimizations 10 - 5

C Compiler and Optimizer

Levels of Optimization

Levels of Optimization
FILE1.C -o0, -o1 -o2 -o3 -pm -o3
{
{ LOCAL
single block
}
FUNCTION
{ across
... blocks
FILE
} across
} functions PROGRAM
across files
{
. . . Increasing levels of opt:
} •  scope, code motion
•  build times
FILE2.C
{ •  visibility
. . .
}
12

10 - 6 C6000 Embedded Design Workshop Using BIOS - C and System Optimizations

 C Compiler and Optimizer

Build Configurations

Code Space Optimization (–ms)

C6000 Embedded Design Workshop Using BIOS - C and System Optimizations 10 - 7

C Compiler and Optimizer

File and Function Specific Options

10 - 8 C6000 Embedded Design Workshop Using BIOS - C and System Optimizations

 C Compiler and Optimizer

Coding Guidelines

Programming the ‘C6000

Source Efficiency* Effort
C Compiler 80 - 100% Low
C ++ Optimizer

Linear Assembly 95 - 100% Med

ASM Optimizer

ASM Hand 100% High

Optimize

T TO
Technical Training
Organization 22

C6000 Embedded Design Workshop Using BIOS - C and System Optimizations 10 - 9

Data Types and Alignment

Data Types and Alignment

Data Types

10 - 10 C6000 Embedded Design Workshop Using BIOS - C and System Optimizations

 Data Types and Alignment

Data Alignment

C6000 Embedded Design Workshop Using BIOS - C and System Optimizations 10 - 11

Data Types and Alignment

Using DATA_ALIGN

10 - 12 C6000 Embedded Design Workshop Using BIOS - C and System Optimizations

 Data Types and Alignment

Upcoming Changes – ELF vs. COFF

EABI : ELF ABI

 Starting with v7.2.0 the C6000 Code Gen Tools (CGT) will begin
shipping two versions of the Linker:
1. COFF: Binary file-format used by TI tools for over a decade
2. ELF: New binary file-format which provides additional features
like dynamic/relocatable linking
 You can choose either format
 v7.3.x default may become ELF (prior to this, choose ELF for new features)
 Continue using COFF for projects already in progress using
“--abi=coffabi” compiler option (support will continue for a long time)
 Formats are not compatible
 Your program’s binary files (.obj, .lib) must all be built with the same format
 If building libraries used for multiple projects, we recommend building two
libraries – one with each format
 Migration Issues
 EABI long’s are 32 bits; new TI type (__int40_t) created to support 40 data
 COFF adds a leading underscore to symbol names, but the EABI does not
 See: http://processors.wiki.ti.com/index.php/C6000_EABI_Migration
37

C6000 Embedded Design Workshop Using BIOS - C and System Optimizations 10 - 13

Restricting Memory Dependencies (Aliasing)

Restricting Memory Dependencies (Aliasing)

10 - 14 C6000 Embedded Design Workshop Using BIOS - C and System Optimizations

 Restricting Memory Dependencies (Aliasing)

Aliasing?
What happens if the function is void fcn(*in, *out)
called like this? {
fcn(*myVector, *myVector+1) LDW *in++, A0
ADD A0, 4, A1
STW A1, *out++
in }

a in + 4
• Definitely Aliased pointers
• *in and *out could point to
b the same address

c • But how does the compiler know?

• If you tell the compiler there is no
d aliasing, this code will break (LDs
in software pipelined loop)
e
• One solution is to “restrict” the
... writes - *out (see next slide…)
45

C6000 Embedded Design Workshop Using BIOS - C and System Optimizations 10 - 15

Access Hardware Features – Using Intrinsics

Access Hardware Features – Using Intrinsics

10 - 16 C6000 Embedded Design Workshop Using BIOS - C and System Optimizations

 Give Compiler MORE Information

Give Compiler MORE Information

Pragma – Unroll()

C6000 Embedded Design Workshop Using BIOS - C and System Optimizations 10 - 17

Give Compiler MORE Information

Pragma – MUST_ITERATE()
4. MUST_ITERATE(min, max, %factor)
#pragma UNROLL(2);
#pragma MUST_ITERATE(10, 100, 2);
for(i = 0; i < count ; i++) {
sum += a[i] * x[i];
}

 Gives the compiler information about the trip (loop) count

In the code above, we are promising that:
count >= 10, count <= 100, and count % 2 == 0
 If you break your promise, you might break your code
 MIN helps with code size and software pipelining
 MULT allows for efficient loop unrolling (and “odd” cases)
 The #pragma must come right before the for() loop
53

Keyword - Volatile

10 - 18 C6000 Embedded Design Workshop Using BIOS - C and System Optimizations

 Give Compiler MORE Information

Setting MAX interrupt Latency (-mi option)

-mi Details
 -mi0
 Compiler’s code is not interruptible
 User must guarantee no interrupts will occur
 -mi1
 Compiler uses single assignment and never produces a loop
less than 6 cycles
 -mi1000 (or any number > 1)
 Tells the compiler your system must be able to see interrupts
every 1000 cycles
 When not using –mi (compiler’s default)
 Compiler will software pipeline (when using –o2 or –o3)
 Interrupts are disabled for s/w pipelined loops

Notes:
 Be aware that the compiler is unaware of issues such as memory
wait-states, etc.
 Using –mi, the compiler only counts instruction cycles
56

C6000 Embedded Design Workshop Using BIOS - C and System Optimizations 10 - 19

Give Compiler MORE Information

MUST_ITERATE Example
int dot_prod(short *a, Short *b, int n)
{
int i, sum = 0;
#pragma MUST_ITERATE ( ,512)
for (i = 0; i < n; i++)
sum += a[i] * b[i];
return sum;
}

 Provided:
 If interrupt threshold was set at 1000 cycles (-mi 1000),
 Assuming this can compile as a single-cycle loop,
 And 512 = max# for Loop count (per MUST_ITERATE pragma).

 Result:
 The compiler knows a 1-cycle kernel will execute no more than 512 times
which is less than the 1000 cycle interrupt disable option (–mi1000)
 Uninterruptible loop works fine

 Verdict:
 3072 cycle loop (512 x 6) can become a 512 cycle loop
T TO
Technical Training
Organization 57

Compiler Directive - _nassert()

10 - 20 C6000 Embedded Design Workshop Using BIOS - C and System Optimizations

 Using Optimized Libraries

Using Optimized Libraries

C6000 Embedded Design Workshop Using BIOS - C and System Optimizations 10 - 21

Using Optimized Libraries

10 - 22 C6000 Embedded Design Workshop Using BIOS - C and System Optimizations

 Using Optimized Libraries

Libraries – Download and Support

C6000 Embedded Design Workshop Using BIOS - C and System Optimizations 10 - 23

System Optimizations

System Optimizations
BIOS Libraries

10 - 24 C6000 Embedded Design Workshop Using BIOS - C and System Optimizations

 System Optimizations

C6000 Embedded Design Workshop Using BIOS - C and System Optimizations 10 - 25

System Optimizations

Custom Sections

10 - 26 C6000 Embedded Design Workshop Using BIOS - C and System Optimizations

 System Optimizations

Use Cache

C6000 Embedded Design Workshop Using BIOS - C and System Optimizations 10 - 27

System Optimizations

Use EDMA

Multiple DMA’s : EDMA3 and QDMA

VPSS EDMA3 C64x+ DSP
(System DMA)
L1P L1D
Master Periph DMA QDMA
(sync) (async)
L2

DMA QDMA
 Enhanced DMA (version 3)  Quick DMA
 DMA to/from peripherals  DMA between memory
 Can be sync’d to peripheral events  Async – must be started by CPU
 Handles up to 64 events  4-8 channels available

Both Share (number depends upon specific device)

 128-256 Parameter RAM sets (PARAMs)
 64 transfer complete flags
 2-4 Pending transfer queues

10 - 28 C6000 Embedded Design Workshop Using BIOS - C and System Optimizations

 System Optimizations

System Architecture – SCR

System Architecture – SCR

Switched
 SCR – Switched Central Resource “Masters” Central “Slaves”
Resource
 Masters initiate accesses to/from
slaves via the SCR SRIO C64 Mem

 Most Masters (requestors) and Slaves DDR2

(resources) have their own port to SCR CPU
EMIF64
 Lower bandwidth masters (HPI,
PCIe, etc) share a port TC0 TCP
 There is a default priority (0 to 7) to TC1
CC SCR VCP
SCR resources that can be modified:
TC2
• SRIO, HOST (PCI/HPI), EMAC
TC3
• TC0, TC1, TC2, TC3 PCI66
• CPU accesses (cache misses)
• Priority Register: MSTPRI PCIe McBSP

HPI Utopia

EMAC

Note: refer to your specific datasheet for register names… 82

C6000 Embedded Design Workshop Using BIOS - C and System Optimizations 10 - 29

Chapter Quiz

Chapter Quiz
Chapter Quiz
1. How do you turn ON the optimizer ?

2. Why is there such a performance delta between “Debug” and “Opt” ?

3. Name 4 compiler techniques to increase performance besides -o?

4. Why is data alignment important?

5. What is the purpose of the –mi option?

6. What is the BEST feedback mechanism to test compiler’s efficiency?

10 - 30 C6000 Embedded Design Workshop Using BIOS - C and System Optimizations

 Lab 10 – C Optimizations

Lab 10 – C Optimizations
In the following lab, you will gain some experience benchmarking the use of optimizations using
the C optimizer switches. While your own mileage may vary greatly, you will gain an
understanding of how the optimizer works and where the switches are located and their possible
affects on speed and size.

C6000 Embedded Design Workshop Using BIOS - C and System Optimizations 10 - 31

Lab 10 – C Optimizations – Procedure

Lab 10 – C Optimizations – Procedure

PART A – Goals and Using Compiler Options
Determine Goals and CPU Min
1. Determine Real-Time Goal
Because we are running audio, our “real-time” goal is for the processing (using low-pass FIR
filter) to keep up with the I/O which is sampling at 48KHz. So, if we were doing a “single
sample” FIR, our processing time would have to be less than 1/48K = 20.8uS. However, we
are using double buffers, so our time requirement is relaxed to 20.8uS * BUFFSIZE = 20.8 *
256 = 5.33ms. Alright, any DSP worth its salt should be able to do this work inside 5ms.
Right? Hmmm…
Real-time goal: music sounds fine.
2. Determine CPU Min.
What is the theoretical minimum based on the C674x architecture? This is based on several
factors – data type (16-bit), #loads required and the type mathematical operations involved.
What kind of algorithm are we using? FIR. So, let’s figure this out:
• 256 data samples * 64 coeffs = 16384 cycles. This assumes 1 MAC/cycle
• Data type = 16-bit data
• # loads possible = 8 16-bit values (aligned). Two LDDW (load double words).
• Mathmatical operation – DDOTP (cross multiply/accumulate) = 8 per cycle
So, the CPU Min = 16384/8 = ~2048 cycles + overhead.
If you look at the inner loop (which is a simple dot product, it will take 64/8 cycles = 8 cycles
per inner loop. Add 8 cycles overhead for prologue and epilogue (pre-loop and post-loop
code), so the inner loop is 16 cycles. Multiply that by the buffer size = 256, so the
approximate CPU min = 16*256 = 4096.
CPU Min = 4096 cycles.
3. Import Lab 10 Project.
Import Lab 10 Project from \Labs\Lab10\Project folder. Change the build properties to use
YOUR student platform file and ensure the latest BIOS/XDC tools are selected.
4. Analyze new items – FIR_process and COEFFs
Open fir.c. You will notice that this file is quite different. It has the same overall TSK
structure (Semaphore_pend, if ping/pong, etc). Notice that after the if(pingPong), we
process the data using a FIR filter.
Scroll on down to cfir(). This is a simple nested for() loop. The outer loop runs once
for every block size (in our case, this is DATA_SIZE). The inner loop runs the size of
COEFFS[] times (in our case, 64).
Open coeffs.c. Here you will see the coefficients for the symmetric FIR filter. There are 3
sets – low-pass, hi-pass and all-pass. We’ll use the low-pass for now.

10 - 32 C6000 Embedded Design Workshop Using BIOS - C and System Optimizations

 Lab 10 – C Optimizations – Procedure

Using Debug Configuration (–g, NO opt)

5. Using the Debug Configuration, build and play.
Build your code and run it. The audio sounds terrible (if you can hear it at all). What is
happening ?
6. Analyze poor audio.
The first thing you might think is that the code is not meeting real-time. And, you’d be right.
Let’s use some debugging techniques to find out what is going on.
7. Check CPU load.
Make sure you clicked Restart. Run again. What do the CPU loads and Log_info’s report?
Hmmm. The CPU Load graph (for the author), showed NOTHING – no line at all.
Right now, the CPU is overloaded (> 100%). In that condition, results cannot be sent to the
tools because the Idle thread is never run.
But, if you look at Raw Logs, you can see the CPU load reported as ZERO (which we know
is not the case) and benchmark is:

About 913K cycles. Whoa. Maybe we need to OPTIMIZE this thing. 

What were your results? Write the down below:

Debug (-g, no opt) benchmark for cfir()? _________________ cycles

Did we meet our real-time goal (music sounding fine?): ____________

Can anyone say “heck no”. The audio sounds terrible. We have failed to meet our only real-
time goal.
But hey, it’s using the Debug Configuration. And if we wanted to single step our code, we
can. It is a very nice debug-friendly environment – although the performance is abysmal. This
is to be expected.

C6000 Embedded Design Workshop Using BIOS - C and System Optimizations 10 - 33

Lab 10 – C Optimizations – Procedure

8. Check Semaphore count of mcaspReadySem.

If the semaphore count for mcaspReadySem is anything other than ZERO after the
Semaphore_pend in FIR_process(), we have troubles. This will indicate that we are
NOT keeping up with real time. In other words, the Hwi is posting the semaphore but the
processing algorithm is NOT keeping up with these posts. Therefore, if the count is higher
than 0, then we are NOT meeting realtime.
Use ROV and look at the Semaphore module. Your results may vary, but you’ll see the
semaphore counts pretty high (darn, even ledToggleSem is out of control):

My goodness – a number WELL greater than zero. We are definitely not meeting realtime.
9. View Debug compiler options.
FYI – if you looked at the options for the Debug configuration, you’d see the following:

Full symbolic debug is turned on and NO optimizations. Ok, nice fluffy debug environment
to make sure we’re getting the right answers, but not good enough to meet realtime. Let’s
“kick it up a notch”…

Using Release Configuration (–o2, no –g)

10. Change the build configuration from Debug to Release.
Next, we’ll use the Release build configuration. In the project view, right-click on the project
and choose “Build Configuration” and select Release:

Check Properties  Include directory. Make sure the BSL \inc folder is specified.
Also, double-check your PLATFORM file. Make sure all code/data/stacks are in internal
memory and that your project is USING the proper platform in this NEW build configuration.
Once again, these configurations are containers of options. Even though Debug had the
proper platform file specified, Release might NOT !!

10 - 34 C6000 Embedded Design Workshop Using BIOS - C and System Optimizations

 Lab 10 – C Optimizations – Procedure

11. Rebuild and Play.

If you get errors, did you remember to set the INCLUDE path for the BSL library?
Remember, the Debug configuration is a container of options – including your path
statements and platform file. So, if you switch configs (Debug to Release), you must also add
ALL path statements and other options you want. Don’t forget to modify the RTSC settings
to point to your _student platform AGAIN!
Once built and loaded, your audio should sound fine now – that is, if you like to hear music
with no treble…
12. Benchmark cfir() – release mode.
Using the same method as before, observe the benchmark for cfir().

Release (-o2, no -g) benchmark for cfir()? __________ cycles

Meet real-time goal? Music sound better? ____________

Here’s our picture:

Ok, now we’re talkin’ – it went from 913K to 37K – just by switching to the release
configuration. So, the bottom line is TURN ON THE OPTIMIZER !!
13. Study release configuration build properties.
Here’s a picture of the build options for release:

The “biggie” is –o2 is selected.

Can we improve on this benchmark a little? Maybe…

C6000 Embedded Design Workshop Using BIOS - C and System Optimizations 10 - 35

Lab 10 – C Optimizations – Procedure

Using “Opt” Configuration

14. Create a NEW build configuration named “Opt”.
Really? Yep. And it’s easy to do. Using the Release configuration, right-click on the project
and select properties (where you’ve been many times already).
Click on Basic Options and notice they are currently set to –o2 –g. Look up a few inches and
you’ll see the “Configuration:” drop-down dialogue. Click on the down arrow and you’ll see
“Debug” and “Release”.
Click on the “Manage” button:

Click New:

(also note the Remove button – where you can delete build configurations).
Give the new configuration a name: “Opt” and choose to copy the existing configuration
from “Release”. Click Ok.

Change the Active Configuration to “Opt”

10 - 36 C6000 Embedded Design Workshop Using BIOS - C and System Optimizations

 Lab 10 – C Optimizations – Procedure

15. Change the “Opt” build properties to use –o3 and NO –g (the “blank” choice).
The only change that needs to be made is to turn UP the optimization level to –o3 vs. –o2
which was used in the Release Configuration. Also, make sure –g is turned OFF (which it
should already be).
Open the “Opt” Config Build Properties and verify it contains NO –g (blank) and
optimization level of –o3.Rebuild your code and benchmark (FYI – LED may stop
blinking…don’t worry).
Follow the same procedure as before to benchmark cfir:

Opt (-o3, no -g) benchmark for cfir()? __________ cycles

The author’s number was about 18K cycles – another pretty significant performance increase
over –o2, -g. We simply went to –o3 and killed –g and WHAM, we went from 37K to 18K.
This is why the author has stated before that the Opt settings we used in this lab SHOULD be
the RELEASE settings. But I am not king.

So, as you can see, we went from 913K to 18K in about 30 minutes. Wow. But what was the
CPU Min? About 7K? Ok…we still have some room for improvement…

Just for kicks and grins, try single stepping your code and/or adding breakpoints in the middle
of a function (like cfir). Is this a bit more difficult with –g turned OFF and –o3 applied? Yep.

With –g turned OFF, you still get symbol capability – i.e. you can enter symbol names
into the watch and memory windows. However, it is nearly impossible to single step C
code – hence the suggestion to create test vectors at function boundaries to check the
LOGICAL part of your code when you build with the Debug Configuration. When you
turn off –g, you need to look at the answers on function boundaries to make sure it is
working properly.

16. Turn on verbose and interlist – and then see what the .asm file looks like for fir.asm.
As noted in the discussion material, to “see it all”, you need to turn on three switches. Turn
them on now, then build, then peruse the fir.asm file. You will see some interesting
information about software pipelining for the loops in fir.c.
Turn on:
• RunTime Model Options → Verbose pipeline info (-mw)

• Optimizations → Interlist (-os)

• Assembler Options → Keep .ASM file (-k)

C6000 Embedded Design Workshop Using BIOS - C and System Optimizations 10 - 37

Lab 10 – C Optimizations – Procedure

Part B – Code Tuning

17. Use #pragma MUST_ITERATE in cfir().
Uncomment the #pragmas for MUST_ITERATE on the two for loops. This pragma gives
the compiler some information about the loops – and how to unroll them efficiently. As
always, the more info you can provide to the compiler, the better.
Use the “Opt” build configuration. Rebuild (use the Build button – it is an incremental build
and WAY faster when you’re making small code changes like this). Then Run.

Opt + MUST_ITERATE (-o3, no –g) cfir()? __________ cycles

The author’s results were close to the previous results – about 15K. Well, this code tuning
didn’t help THIS algo much, but it might help yours. At least you know how to apply it now.
18. Use restrict keyword on the results array.
You actually have a few options to tell the compiler there is NO ALIASING. The first
method is to tell the compiler that your entire project contains no aliasing (using the –mt
compiler option). However, it is best to narrow the scope and simply tell the compiler that the
results array has no aliasing (because the WRITES are destructive, we RESTRICT the output
array).
So, in fir.c, add the following keyword (restrict) to the results (r) parameter of the fir
algorithm as shown:

Build, then run again. Now benchmark your code again. Did it improve?

Opt + MUST_ITERATE + restrict (-o3, no –g) cfir()? __________ cycles

Here is what the author got:

Well, getting rid of ALIASING was a big help to our algo. We went from about 15K down to 7K
cycles. You could achieve the same result by using “-mt” compiler switch, but that tells the
compiler that there is NO aliasing ANYWHERE – scope is huge. Restrict is more restricted. 

10 - 38 C6000 Embedded Design Workshop Using BIOS - C and System Optimizations

 Lab 10 – C Optimizations – Procedure

19. Use _nassert() to tell optimizer about data alignment.

Because the receive buffers are set up using STRUCTURES, the compiler may or may not be
able to determine the alignment of an ELEMENT (i.e. rcvPingL.hist) inside that structure –
thus causing the optimizer to be conservative and use redundant loops. You may have seen
the benchmarks have two results the same, and one larger. Or, you may not have. It usually
happens on Thursdays….
It is possible that using _nassert() may help this situation. Again, this “fix” is only
needed in this specific case where the memory buffers were allocated using structures (see
main.h if you want a looksy).
Uncomment the two _nassert() intrinsics in fir.c inside the cfir() function and rebuild/run
and check the results.
Here is what the author got (same as before…but hey, worth a try):

20. Turn on symbolic debug with FULL optimization.

This is an important little trick that you need to know. As we have stated before, it is
impossible to single step your code when you have optimization turned on to level –o3. You
are able to place breakpoints at function entry/exit points and check your answers, but that’s
it. This is why FUNCTION LEVEL test vectors are important.
There are two ways to accomplish this. Some companies use script code to place breakpoints
at specific disassembly symbols (function entry/exit) and run test vectors through
automatically. Others simply want to manually set breakpoints in their source code and hit
RUN and see the results.
While still in the Debug perspective with your program loaded, select:
Restart

The execution pointer is at main, but do you see your main() source file? Probably not. Ok,
pop over to Edit perspective and open fir.c. Set a breakpoint at the beginning of the
function. Hit RUN. Your program will stop at that breakpoint, but in the Debug perspective,
do you see your source file associated with the disassembly? Again, probably not. Again, hit
Restart to start your program at main() again.

How do you tell the compiler to add JUST ENOUGH debug info to allow your source files to
SYNC with the disassembly but not affect optimization? There is a little known option that
allows this…

C6000 Embedded Design Workshop Using BIOS - C and System Optimizations 10 - 39

Lab 10 – C Optimizations – Procedure

Make sure you have the Opt configuration selected, right click and choose Properties. Next,
check the box below (at C6000 Compiler  Runtime Model Options) to turn on symbolic
debug with FULL Optimization (-mn):

TURN ON –g (symbolic debug). –mn only makes sense if –g is turned ON. Go back to the
basic options and select Full Symbolic Debug.

Rebuild and load your program. The execution pointer should now show up along with your
main.c file. Hit Restart again. Set a breakpoint in the middle of FIR_process() function
inside fir.c. You can’t do it. The breakpoint snaps to the beginning or end of the function,
right? Make sure the breakpoint is at the beginning of FIR_process() and hit RUN. You can
now see your source code synced with the disassembly. Very nice.
But did this affect your optimization and your benchmark? Go try it. Hit Restart again and
remove all breakpoints. Then RUN. Halt your program and check your benchmark. Is it about
the same? It should be…

10 - 40 C6000 Embedded Design Workshop Using BIOS - C and System Optimizations

 Lab 10 – C Optimizations – Procedure

Part C – Minimizing Code Size (–ms)

21. Determine current cfir benchmark and .text size.

Select the “Opt” configuration and also make sure MUST_ITERATE and restrict are used in
your code (this is the same setting as the previous lab step).
Rebuild and Run.
Write down your fastest benchmark for cfir:

Opt (-o3, NO –g, NO –ms3) cfir, ____________ cycles

.text (NO –ms) = ___________ h

Open the .map file generated by the linker. Hmmm. Where is it located? Try to find it
yourself without asking anyone else. Hint: which build config did you use when you hit
“build” ?
22. Add –ms3 to Opt Config.
Open the build properties and add –ms3 to the compiler options (under Basic Options). We
will just put the “pedal to the metal” for code size optimizations and go all the way to –ms3
first. Note here that we also have –o3 set also (which is required for the –ms option).
In this scenario, the compiler may choose to keep the “slow version” of the redundant loops
(fast or slow) due to the presence of –ms.
Rebuild and run.

Opt + -ms (-o3, NO –g, –ms3) cfir, ____________ cycles

.text (-ms3) = ___________ h

Did your benchmark get worse with –ms3? How much code size did you save? What
conclusions would you draw from this?
____________________________________________________________________
____________________________________________________________________

Keep in mind that you can also apply –ms3 (or most of the basic options) to a specific
function using #pragma FUNCTION_OPTIONS( ).
FYI – the author saved about 2.2K bytes total out of the .text section and the benchmark was
about 33K. HOWEVER, most of the .text section is LIBRARY code which is not affected by
–ms3. So, of the NON .lib code which IS affected by –ms3, using –ms3 saved 50% on code
size (original byte count was 6881 bytes and was reduced to 3453 bytes). This is pretty
significant. Yes, the benchmark ended up being 33K, but now you know the tradeoff.
Also remember that you can apply –ms3 on a FILE BY FILE basis. So, a smart way to apply
this is to use it on init routines – and keep it far away from your algos that require the best
performance.

C6000 Embedded Design Workshop Using BIOS - C and System Optimizations 10 - 41

Lab 10 – C Optimizations – Procedure

Part D – Using DSPLib

23. Download and install the appropriate DSP Library.
This, fortunately for you, has already been done for you. This directory is located at:
C:\SYSBIOSv4\Labs\dsplib64x+\lib
24. Link the appropriate library to your project.
Find the lib file in the above folder and link it to your project (non ELF version).
Also, add the include path for this library to your build properties.
25. Add #include to the fir.c file.
Add the proper #include for the header file for this library to fir.c
26. Replace the calls to the fir function in fir.c.
THIS MUST BE DONE 4 TIMES (Ping, Pong, L and R = 4). Should I say it again? There are
FOUR calls to the fir routine that need to be replaced by something new. Ok, twice should be
enough. ;-)
Replace:
cfir(rcvPongL.hist, COEFFS, xmt.PongL, ORDER, DATA_SIZE);
with
DSP_fir_gen(rcvPongL.hist, COEFFS, xmt.PongL, ORDER, DATA_SIZE);
27. Build, load, verify and BENCHMARK the new FIR routine in DSPLib.
28. What are the best-case benchmarks?

Yours (compiler/optimizer):___________ DSPLib: ___________

Wow, for what we wanted in THIS system (a fast simple FIR routine), we would have been
better off just using DSPLib. Yep. But, in the process, you’ve learned a great deal about
optimization techniques across the board that may or may not help your specific system.
Remember, your mileage may vary.

10 - 42 C6000 Embedded Design Workshop Using BIOS - C and System Optimizations

 Lab 10 – C Optimizations – Procedure

Conclusion
Hopefully this exercise gave you a feel for how to use some of the basic compiler/optimizer
switches for your own application. Everyone’s mileage may vary and there just might be a
magic switch that helps your code and dosen’t help someone else’s. That’s the beauty of trial
and error.
Conclusion? TURN ON THE OPTIMIZER ! Was that loud enough?
Here’s what the author came up with – how did your results compare?

Optimizations Benchmark
Debug Bld Config – No opt 913K
Release (-o2, -g) 37K
Opt (-o3, no –g) 18K
Opt + MUST_ITERATE 15K
Opt + MUST_ITERATE + restrict 7K
DSPLib (FIR) 7K

Regarding –ms3, use it wisely. It is more useful to add this option to functions that are large
but not time critical – like IDL functions, init code, maintenance type items.You can save
some code space (important) and lose some performance (probably a don’t care). For your
time-critical functions, do not use –ms ANYTHING. This is just a suggestion – again, your
mileage may vary.

CPU Min was 4K cycles. We got close, but didn’t quite reach it. The authors believe that it is
possible to get closer to the 4K benchmark by using intrinsics and the DDOTP instruction.

The biggest limiting factor in optimizing the cfir routine is the “sliding window”. The
processor is only allowed ONE non-aligned load each cycle. This would happen 75% of the
time. So, the compiler is already playing some games and optimizing extremely well given
the circumstances. It would require “hand-tweaking” via intrinsics and intimate knowledge of
the architecture to achieve much better.

29. Terminate the Debug session, close the project and close CCS. Power-cycle the board.

Throw something at the instructor to let him know that you’re done with the
lab. Hard, sharp objects are most welcome…

C6000 Embedded Design Workshop Using BIOS - C and System Optimizations 10 - 43

Additional Information

Additional Information

10 - 44 C6000 Embedded Design Workshop Using BIOS - C and System Optimizations

 Additional Information

IDMA0 – Programming Details

 IDMA0 operates on a block of 32 contiguous 32-bit registers (both src/dst blocks
must be aligned on a 32-word boundary). Optionally generate CPU interrupt if needed.
 User provides: Src, Dst, Count and “mask” (Reference: SPRU871)
L1D/L2 Periph Cfg
Src 0 Dst 0 Count = # of 32-register blocks to xfr (up to 16)
. . Mask = 32-bit mask determines WHICH registers
. . to transfer (“0” = xfr, “1” = NO xfr)
31 31
32-bits 32-bits

 Example Transfer using MASK (not all regs typically need to be programmed):
Source Destination
0 1 4 5 6 0 1 4 5 6
address address
8 10 12 8 10 12

22 23 22 23

27 29 31 27 29 31

Mask = 01010111001111111110101010001100

 User must write to IDMA0 registers in the following order (COUNT written – triggers transfer):
IDMA0_MASK = 0x573FEA8C; //set mask for 13 regs above
IDMA0_SOURCE = reg_ptr; //set src addr in L1D/L2
IDMA0_DEST = MMR_ADDRESS; //set dst addr to config location
IDMA0_COUNT = 0; //set mask for 1 block of 32 registers
95

C6000 Embedded Design Workshop Using BIOS - C and System Optimizations 10 - 45

Additional Information

10 - 46 C6000 Embedded Design Workshop Using BIOS - C and System Optimizations

 Cache & Internal Memory
Introduction
In this chapter the memory options of the C6000 will be considered. By far, the easiest – and
highest performance – option is to place everything in on-chip memory. In systems where this is
possible, it is the best choice. To place code and initialize data in internal RAM in a production
system, refer to the chapters on booting and DMA usage.
Most systems will have more code and data than the internal memory can hold. As such, placing
everything off-chip is another option, and can be implemented easily, but most users will find the
performance degradation to be significant. As such, the ability to enable caching to accelerate the
use of off-chip resources will be desirable.
For optimal performance, some systems may beneifit from a mix of on-chip memory and cache.
Fine tuning of code for use with the cache can also improve performance, and assure reliability in
complex systems. Each of these constructs will be considered in this chapter,

Objectives

Objectives

 Compare/contrast different uses of

memory (internal, external, cache)
 Define cache terms and definitions
 Describe C6000 cache architecture
 Demonstrate how to configure and use
cache optimally
 Lab 11 – modify an existing system to
use cache – benchmark solutions

C6000 Embedded Design Workshop Using BIOS - Cache & Internal Memory 11 - 1
Module Topics

Module Topics
Cache & Internal Memory ......................................................................................................................11-1
Module Topics........................................................................................................................................11-2
Why Cache? ...........................................................................................................................................11-3
Cache Basics – Terminology..................................................................................................................11-4
Cache Example ......................................................................................................................................11-7
L1P – Program Cache .........................................................................................................................11-10
L1D – Data Cache ...............................................................................................................................11-13
L2 – RAM or Cache ? ..........................................................................................................................11-15
Cache Coherency (or Incoherency?) ...................................................................................................11-17
Coherency Example .........................................................................................................................11-17
Coherency – Reads & Writes ..........................................................................................................11-18
Cache Functions – Summary ...........................................................................................................11-21
Coherency – Use Internal RAM ! ....................................................................................................11-22
Coherency – Summary ....................................................................................................................11-22
Cache Alignment .............................................................................................................................11-23
Turning OFF Cacheability (MAR) .......................................................................................................11-24
Additional Topics .................................................................................................................................11-26
Chapter Quiz ........................................................................................................................................11-29
Lab 11 – Using Cache..........................................................................................................................11-31
Lab Overview: .................................................................................................................................11-31
Lab 11 – Using Cache – Procedure .................................................................................................11-32
A. Run System From Internal RAM ..........................................................................................11-32
B. Run System From External DDR2 (no cache) .......................................................................11-33
C. Run System From DDR2 (cache ON) ....................................................................................11-34

11 - 2 C6000 Embedded Design Workshop Using BIOS - Cache & Internal Memory
 Why Cache?

Why Cache?

C6000 Embedded Design Workshop Using BIOS - Cache & Internal Memory 11 - 3
Cache Basics – Terminology

Cache Basics – Terminology

11 - 4 C6000 Embedded Design Workshop Using BIOS - Cache & Internal Memory
 Cache Basics – Terminology

C6000 Embedded Design Workshop Using BIOS - Cache & Internal Memory 11 - 5
Cache Basics – Terminology

11 - 6 C6000 Embedded Design Workshop Using BIOS - Cache & Internal Memory
 Cache Example

Cache Example

C6000 Embedded Design Workshop Using BIOS - Cache & Internal Memory 11 - 7
Cache Example

Direct-Mapped Cache Example

Valid Tag Index Cache
0
1
2
 000 3 LDH
 000 4 MPY
 000 5 ADD
 000 002 000 6 B ADD B
 002 7 SUB
 002 8 B
9
Address Code A
0003h L1 LDH .
...
0026h L2 ADD .
0027h
0028h [!cnt] B
SUB cnt
L1
F
33

11 - 8 C6000 Embedded Design Workshop Using BIOS - Cache & Internal Memory
 Cache Example

C6000 Embedded Design Workshop Using BIOS - Cache & Internal Memory 11 - 9
L1P – Program Cache

L1P – Program Cache

11 - 10 C6000 Embedded Design Workshop Using BIOS - Cache & Internal Memory
 L1P – Program Cache

L1P Cache Comparison

Device Scheme Size Linesize New Features

Direct 64 bytes
C62x/C67x Mapped
4K bytes
(16 instr)
N/A

Direct 32 bytes
C64x Mapped
16K bytes
(8 instr)
N/A

C64x+  Cache/RAM
Direct 32 bytes
C674x 32K bytes  Cache Freeze
C66x Mapped (8 instr)
 Memory Protection

 All L1P memories provide zero waitstate access

Next two slides discuss Cache/RAM and Freeze features.

Memory Protection is not discussed in this workshop. Cache/Ram...
42

C6000 Embedded Design Workshop Using BIOS - Cache & Internal Memory 11 - 11
L1P – Program Cache

11 - 12 C6000 Embedded Design Workshop Using BIOS - Cache & Internal Memory
 L1D – Data Cache

L1D – Data Cache

C6000 Embedded Design Workshop Using BIOS - Cache & Internal Memory 11 - 13
L1D – Data Cache

11 - 14 C6000 Embedded Design Workshop Using BIOS - Cache & Internal Memory
 L2 – RAM or Cache ?

L2 – RAM or Cache ?

C6000 Embedded Design Workshop Using BIOS - Cache & Internal Memory 11 - 15
L2 – RAM or Cache ?

11 - 16 C6000 Embedded Design Workshop Using BIOS - Cache & Internal Memory
 Cache Coherency (or Incoherency?)

Cache Coherency (or Incoherency?)

Coherency Example

C6000 Embedded Design Workshop Using BIOS - Cache & Internal Memory 11 - 17
Cache Coherency (or Incoherency?)

Coherency – Reads & Writes

11 - 18 C6000 Embedded Design Workshop Using BIOS - Cache & Internal Memory
 Cache Coherency (or Incoherency?)

C6000 Embedded Design Workshop Using BIOS - Cache & Internal Memory 11 - 19
Cache Coherency (or Incoherency?)

Coherency Solution – Write (Flush/Writeback)

DDR2
L1D L2
RcvBuf

XmtBuf XmtBuf
CPU writeback
EDMA

 When the CPU is finished with the data (and has written it to XmtBuf in L2), it can
be sent to ext. memory with a cache writeback
 A writeback is a copy operation from cache to memory, writing back the modified
(i.e. dirty) memory locations – all writebacks operate on full cache lines
 Use BIOS Cache APIs to force a writeback:
BIOS: Cache_wb (XmtBuf, BUFFSIZE, CACHE_NOWAIT);
What happens with the "next" RCV buffer? 64

11 - 20 C6000 Embedded Design Workshop Using BIOS - Cache & Internal Memory
 Cache Coherency (or Incoherency?)

Cache Functions – Summary

C6000 Embedded Design Workshop Using BIOS - Cache & Internal Memory 11 - 21
Cache Coherency (or Incoherency?)

Coherency – Use Internal RAM !

Coherency – Summary

11 - 22 C6000 Embedded Design Workshop Using BIOS - Cache & Internal Memory
 Cache Coherency (or Incoherency?)

Cache Alignment

C6000 Embedded Design Workshop Using BIOS - Cache & Internal Memory 11 - 23
Turning OFF Cacheability (MAR)

Turning OFF Cacheability (MAR)

"Turn Off" the DATA Cache (MAR)

DDR2
L1D L2 EDMA
RcvBuf

XmtBuf
CPU

 Memory Attribute Registers (MARs) enable/disable DATA caching memory ranges

 Don’t use MAR to solve basic cache coherency – performance will be too slow
 Use MAR when you have to always read the latest value of a memory location,
such as a status register in an FPGA, or switches on a board.
 MAR is like “volatile”. You must use both to always read a memory location: MAR
for cache; volatile for the compiler
Looking more closely at the MAR registers ...
72

11 - 24 C6000 Embedded Design Workshop Using BIOS - Cache & Internal Memory
 Turning OFF Cacheability (MAR)

C6000 Embedded Design Workshop Using BIOS - Cache & Internal Memory 11 - 25
Additional Topics

Additional Topics

11 - 26 C6000 Embedded Design Workshop Using BIOS - Cache & Internal Memory
 Additional Topics

C6000 Embedded Design Workshop Using BIOS - Cache & Internal Memory 11 - 27
Additional Topics

11 - 28 C6000 Embedded Design Workshop Using BIOS - Cache & Internal Memory
 Chapter Quiz

Chapter Quiz
Chapter Quiz
1. How do you turn ON the cache ?

2. Name the three types of caches & their associated memories:

3. All cache operations affect an aligned cache line. How big is a line?

4. Which bit(s) turn on/off “cacheability” and where do you set these?

5. How do you fix coherency when two bus masters access ext’l mem?

6. If a dirty (newly written) cache line needs to be evicted, how does

that dirty line get written out to external memory?

C6000 Embedded Design Workshop Using BIOS - Cache & Internal Memory 11 - 29
Chapter Quiz

*** HTTP ERROR 404 – PAGE NOT FOUND – CONTACT ADMINISTRATOR ***

11 - 30 C6000 Embedded Design Workshop Using BIOS - Cache & Internal Memory
 Lab 11 – Using Cache

Lab 11 – Using Cache

In the following lab, you will gain some experience benchmarking the use of cache in the system.
First, we’ll run the code with EVERYTHING (buffers, code, etc) off chip with NO cache. Then,
we’ll turn on the cache and compare the results. Then, we’ll move everything ON chip and
compare the cache results with using on-chip memory only.
This will provide a decent understanding of what you can expect when using cache in your own
application.

Lab Overview:
There are two goals in this lab: (1) to learn how to turn on and off cache and the effects of each
on the data buffers and program code; (2) to optimize a hi-pass FIR filter written in C. To gain
this basic knowledge you will:
A. Learn to use the platform and CFG files to setup cache memory address range (MAR bits)
and turn on L2 and L1 caches.
B. Benchmark the system performance with running code/data externally (DDR2) vs. with the
cache on vs. internal (IRAM).

C6000 Embedded Design Workshop Using BIOS - Cache & Internal Memory 11 - 31
Lab 11 – Using Cache

Lab 11 – Using Cache – Procedure

A. Run System From Internal RAM

1. Open CCS and import Lab11.

This project is actually the solution for Lab 10 (OPT) – with all optimizations in place.
Ensure the proper platform (student) and the latest XDC/BIOS versions are being used.

Note: For all benchmarks throughout this lab, use the “Opt” build configuration when you
build. Do NOT use the Debug or Release config.

2. Ensure BUFFSIZE is 256 in main.h.

In order to compare our cache lab to the OPT lab, we need to make sure the buffer sizes are
the same – which is 256.
3. Find out where code and data are mapped to in memory.
First, check Build Properties for the Opt configuration. Make sure you are using YOUR
student platform file in this configuration. Then, view the platform file and determine which
memory segments (like IRAM) contain the following sections:
Section Memory Segment
.text
.bss
.far
It’s not so simple, is it? .bss and .far sections are “data” and .text is “code”. If you didn’t
know that, you couldn’t answer the question. So, they are all allocated in IRAM – if not,
please make sure they are before moving on.
4. Which cache areas are turned on/off (circle your answer)?
L1P OFF/ON
L1D OFF/ON
L2 OFF/ON
Leave the settings as is.
5. Build, load.
BEFORE YOU RUN, open up the Raw Logs window.

Click Run and write down below the benchmarks for cfir():

Data Internal (L1P/D cache ON): __________ cycles

The benchmark from the Log_info should be around 8K cycles. We’ll compare this “internal
RAM” benchmark to “all external” and “all external with cache ON” numbers. You just
might be surprised…

11 - 32 C6000 Embedded Design Workshop Using BIOS - Cache & Internal Memory
 Lab 11 – Using Cache

B. Run System From External DDR2 (no cache)

6. Place the buffers (data) in external DDR2 memory and turn OFF the cache.
Edit your platform file and place the data external (DDR). Leave stacks and code in IRAM.
Modify the L1P/D cache sizes to ZERO (0K).
In this scenario, the audio data buffers are all external. Cache is not turned on. This is the
worst case situation.
Do you expect the audio to sound ok? ____________________

Match the settings you see below (0K for all cache sizes, Data Memory in DDR) :

7. Clean project, build, load, run – using the “Opt” Configuration.

Select Project  Clean (this will ensure your platform file is correct). Then Rebuild All and
load your code. Run your code. Listen to the audio – how does it sound? It’s DEAD – that’s
how it sounds – just air – bad air – it is the absence of noise. Plus, we can’t see anything
because the CPU is overloaded and therefore no RTA tools.
Ah, but Log_info just might save us again. Go look at the Raw Logs and see if the benchmark
is getting reported.

All Code/Data External: ___________ cycles

Did you get a cycle count? The author experienced a total loss – absolute NOTHING. I think
the system is so out of it, it crashes. In fact, CCS crashed a few times in this mode. Yikes. I
vote for calling it “the national debt” #cycles – uh, what is it now – $15 Trillion? Ok, 15
trillion cycles… ;-)

C6000 Embedded Design Workshop Using BIOS - Cache & Internal Memory 11 - 33
Lab 11 – Using Cache

C. Run System From DDR2 (cache ON)

8. Turn on the cache (L1P/D, L2) in the platform file.
Choose the following settings for the cache (L2=64K, L1P/D = 32K):

Set L1D/P to 32K and L2 to 64K – IF YOU DON’T SET L2 CACHE ON, YOU WILL
CACHE IN L1 ONLY. Watch it, though, when you reconfigure cache sizes, it wipes your
memory sections selections. Redo those properly after you set the cache sizes.
These sizes are larger than we need, but it is good enough for now. Leave code/data in DDR
and stacks in IRAM. Click Ok to rebuild the platform package.
The system we now have is identical to one of the slides in the discussion material.
9. Wait – what about the MAR bits?
In the discussion material, we talked about the MAR bits specifying which regions were
cacheable and which were not. Don’t we have to set the MAR bits for the external region of
DDR for them to get cached? Yep.
In order to modify (or even SEE) the MAR bits OR use any BIOS Cache APIs (like
invalidate or writeback), you need to add the C64p Cache Module to your .cfg file. Or, you
can simply right-click (and Use) the Cache module listed under: Available Products 
SYS/BIOS Target Specific Support  C674 Cache (as shown in the discussion material).

11 - 34 C6000 Embedded Design Workshop Using BIOS - Cache & Internal Memory
 Lab 11 – Using Cache

Save the .cfg file. This SHOULD add the module to your outline view. When it shows up in
the outline view, click on it. Do you see the MAR bits?
The MAR region we are interested in, by the way, for DDR2 is MAR 192-223. As a courtesy
to users, the platform file already turned on the proper MAR bits for us for the DDR2 region.
Check it out:

The good news is that we don’t need to worry about the MAR bits for now.
10. Build, load, run –using the Opt (duh) Configuration.
Run the program. View the CPU load graph and benchmark stat and write them down below:

All Code/Data External (cache “ON”): _________ cycles

With code/data external AND the cache ON, the benchmark should be close to 8K cycles –
the SAME as running from internal IRAM (L2). In fact, what you’re seeing is the L1D/P
numbers. Why? Because L2 is cached in L1D/P – the closest memory to the CPU. This is
what a cache does for you – especially with this architecture.
Here’s what the author got:

C6000 Embedded Design Workshop Using BIOS - Cache & Internal Memory 11 - 35
Lab 11 – Using Cache

11. What about cache coherency?

So, how does the audio sound with the buffers in DDR2 and the cache on? Shouldn’t we be
experiencing cache coherency problems with data in DDR2? Well, the audio sounds great, so
why bother? Think about this for awhile. What is your explanation as to why there are NO
cache coherency problems in this lab.
Answer: _______________________________________________________________
12. Conclusion and Summary – long read – but worth it…
It is amazing that you get the same benchmarks from all code/data in internal IRAM (L2) and
L1 cache turned on as you do with code/data external and L2/L1 cache turned on. In fact, if
you place the buffers DIRECTLY in L1D as SRAM, the benchmark is the same. How can
this be? That’s an efficient cache, eh? Just let the cache do its thing. Place your buffers in
DDR2, turn on the cache and move on to more important jobs.
Here’s another way to look at this. Cache is great for looping code (program, L1P) and
sequentially accessed data (e.g. buffers). However, cache is not as effective at random access
of variables. So, what would be a smart choice for part of L1D as SRAM? Coefficient tables,
algorithm tables, globals and statics that are accessed frequently, but randomly (not
sequential) and even frequently used ISRs (to avoid cache thrashing). The random data items
would most likely fall into the .bss compiler section. Keep that in mind as you design your
system.

Let’s look at the final results:

System benchmark
Buffers in IRAM (internal) 8K cycles
All External (DDR2), cache OFF ~4M
All External (DDR2), cache ON 8K cycles
Buffers in L1D SRAM 7K cycles
So, will you experience the same results? 150x improvement with cache on and not much
difference between internal memory only and external with cache on? Probably something
similar. The point here is that turning the cache ON is a good idea. It works well – and there
is little thinking that is required unless you have peripherals hooked to external memory
(coherency). For what it is worth, you’ve seen the benefits in action and you know the issues
and techniques that are involved. Mission accomplished.

RAISE YOUR HAND and get the instructor’s attention when

you have completed PART A of this lab. If time permits,
move on to the next OPTIONAL part…

You’re finished with this lab. If time permits, you may move on to additional
“optional” steps on the following pages if they exist.

11 - 36 C6000 Embedded Design Workshop Using BIOS - Cache & Internal Memory
 Using EDMA3
Introduction
In this chapter, you will learn the basics of the EDMA3 peripheral. This transfer engine in the
C64x+ architecture can perform a wide variety of tasks within your system from memory to
memory transfers to event synchronization with a peripheral and auto sorting data into separate
channels or buffers in memory. No programming is covered. For programming concepts, see
ACPY3/DMAN3, LLD (Low Level Driver – covered in the Appendix) or CSL (Chip Support
Library). Heck, you could even program it in assembly, but don’t call ME for help. 

Objectives
At the conclusion of this module, you should be able to:
• Understand the basic terminology related to EDMA3
• Be able to describe how a transfer starts, how it is configured and what happens after the
transfer completes
• Undersand how EDMA3 interrupts are generated
• Be able to easily read EDMA3 documentation and have a great context to work from to
program the EDMA3 in your application

C6000 Embedded Design Workshop Using BIOS - Using EDMA3 12 - 1

Module Topics

Module Topics
Using EDMA3 ...........................................................................................................................................12-1
Module Topics........................................................................................................................................12-2
Overview ................................................................................................................................................12-3
What is a “DMA” ? ...........................................................................................................................12-3
Multiple “DMAs” ..............................................................................................................................12-4
EDMA3 in C64x+ Device .................................................................................................................12-5
Terminology ...........................................................................................................................................12-6
Overview ...........................................................................................................................................12-6
Element, Frame, Block – ACNT, BCNT, CCNT ..............................................................................12-7
Simple Example.................................................................................................................................12-7
Channels and PARAM Sets ...............................................................................................................12-8
Examples ................................................................................................................................................12-9
Synchronization....................................................................................................................................12-12
Indexing ...............................................................................................................................................12-13
Events – Transfers – Actions ................................................................................................................12-15
Overview .........................................................................................................................................12-15
Triggers ...........................................................................................................................................12-16
Actions – Transfer Complete Code .................................................................................................12-16
EDMA Interrupt Generation ................................................................................................................12-17
Linking .................................................................................................................................................12-18
Chaining...............................................................................................................................................12-19
Channel Sorting ...................................................................................................................................12-21
Architecture & Optimization ................................................................................................................12-22
Programming EDMA3 – Using Low Level Driver (LLD) ....................................................................12-23
Chapter Quiz ........................................................................................................................................12-24
Additional Information.........................................................................................................................12-25
Notes ....................................................................................................................................................12-28

12 - 2 C6000 Embedded Design Workshop Using BIOS - Using EDMA3

 Overview

Overview
What is a “DMA” ?

C6000 Embedded Design Workshop Using BIOS - Using EDMA3 12 - 3

Overview

Multiple “DMAs”

Multiple DMA’s : EDMA3 and QDMA

VPSS EDMA3 C64x+ DSP
(System DMA)
L1P L1D
Master Periph DMA QDMA
(sync) (async)
L2

DMA QDMA
 Enhanced DMA (version 3)  Quick DMA
 DMA to/from peripherals  DMA between memory
 Can be sync’d to peripheral events  Async – must be started by CPU
 Handles up to 64 events  4-8 channels available

Both Share (number depends upon specific device)

 128-256 Parameter RAM sets (PARAMs)
 64 transfer complete flags
 2-4 Pending transfer queues
4

12 - 4 C6000 Embedded Design Workshop Using BIOS - Using EDMA3

 Overview

EDMA3 in C64x+ Device

M
SCR & EDMA3 S
Master Slave 32
EDMA3 SCR = Switched Central Resource L3
McASP
TC0
TC1
CC McBSP
x2 TC2 L1P
PCI

DDR2/3
C64x+ MegaModule L1P PERIPH
EMAC EMIF Mem AET
HPI Ctrl M S
PCI Cfg
D D
L2
L2 Mem IDMA CPU S
M
S
M
ARM Ctrl
L L

External L1D
S M Mem
128 Cntl Mem
Ctrl PERIPH =
M S M All peripheral’s
128
Cfg registers
L1D S
DATA 32
SCR
CFG
 EDMA3 is a master on the DATA SCR – it can initiate data transfers
 EDMA3’s configuration registers are accessed via the CFG SCR (by the CPU)
SCR
 Each TC has its own connection (and priority) to the DATA SCR. Refer to the connection matrix to determine valid connections
6

C6000 Embedded Design Workshop Using BIOS - Using EDMA3 12 - 5

Terminology

Terminology
Overview

12 - 6 C6000 Embedded Design Workshop Using BIOS - Using EDMA3

 Terminology

Element, Frame, Block – ACNT, BCNT, CCNT

How Much to Move?

Block Frame Element
Frame 1 Elem 1
Frame 2 Elem 2
“A” Count
. . (# of contig bytes)
. .
Elem N
Frame M
“B” Count
“C” Count

Transfer Configuration
Options
Source
B
Transfer CountA
Destination B Count (# Elements) A Count (Element Size)
Index 31 16 15 0
Cnt Reload Link Addr
Index Index
C Count (# Frames)
Rsvd C 31 16 15 0
Let's look at a simple example... 9

Simple Example

C6000 Embedded Design Workshop Using BIOS - Using EDMA3 12 - 7

Terminology

Channels and PARAM Sets

12 - 8 C6000 Embedded Design Workshop Using BIOS - Using EDMA3

 Examples

Examples

C6000 Embedded Design Workshop Using BIOS - Using EDMA3 12 - 9

Examples

12 - 10 C6000 Embedded Design Workshop Using BIOS - Using EDMA3

 Examples

C6000 Embedded Design Workshop Using BIOS - Using EDMA3 12 - 11

Synchronization

Synchronization

12 - 12 C6000 Embedded Design Workshop Using BIOS - Using EDMA3

 Indexing

Indexing

C6000 Embedded Design Workshop Using BIOS - Using EDMA3 12 - 13

Indexing

12 - 14 C6000 Embedded Design Workshop Using BIOS - Using EDMA3

 Events – Transfers – Actions

Events – Transfers – Actions

Overview

C6000 Embedded Design Workshop Using BIOS - Using EDMA3 12 - 15

Events – Transfers – Actions

Triggers

Actions – Transfer Complete Code

12 - 16 C6000 Embedded Design Workshop Using BIOS - Using EDMA3

 EDMA Interrupt Generation

EDMA Interrupt Generation

C6000 Embedded Design Workshop Using BIOS - Using EDMA3 12 - 17

Linking

Linking

12 - 18 C6000 Embedded Design Workshop Using BIOS - Using EDMA3

 Chaining

Chaining

C6000 Embedded Design Workshop Using BIOS - Using EDMA3 12 - 19

Chaining

12 - 20 C6000 Embedded Design Workshop Using BIOS - Using EDMA3

 Channel Sorting

Channel Sorting

C6000 Embedded Design Workshop Using BIOS - Using EDMA3 12 - 21

Architecture & Optimization

Architecture & Optimization

Periphs
E63 E1 E0
EDMA Architecture
Evt Reg (ER) Queue
PSET 0
CC TC
Evt Enable Reg Q0 PSET 1 TC0
(EER)
Q1 .. TR TC1 DATA
Evt Set Reg
(ESR) Q2
. Submit
TC2
SCR

PSET 254
Chain Evt Reg Q3 Early TC3
PSET 255 TCC
(CER)

EDMAINT Int Pending Reg – IPR Completion Normal

Int Enable Reg – IER Detection TCC

SCR = Switched Central Resource

 EDMA consists of two parts: Channel Controller (CC) and Transfer Controller (TC)
 An event (from periph-ER/EER, manual-ESR or via chaining-CER) sends the transfer
to 1 of 4 queues (Q0 is mapped to TC0, Q1-TC1, etc. Note: McBSP can use TC1 only)
 Xfr mapped to 1 of 256 PSETs and submitted to the TC (1 TR – transmit request – per ACNT
bytes or “A*B” CNT bytes – based on sync). Note: Dst FIFO allows buffering of writes while more reads occur.
 The TC performs the transfer (read/write) and then sends back a transfer completion code (TCC)
 The EDMA can then interrupt the CPU and/or trigger another transfer (chaining – Chap 6)
42

12 - 22 C6000 Embedded Design Workshop Using BIOS - Using EDMA3

 Programming EDMA3 – Using Low Level Driver (LLD)

Programming EDMA3 – Using Low Level Driver (LLD)

C6000 Embedded Design Workshop Using BIOS - Using EDMA3 12 - 23

Chapter Quiz

Chapter Quiz
Chapter Quiz
1. Name the 4 ways to trigger a transfer?

2. Compare/contrast linking and chaining

3. Fill out the following values for this channel sorting example (5 min):
PERIPH MEM • 16-bit stereo audio (interleaved)
L0 L0 • Use EDMA to auto “channel sort” to memory
R0 L1
L1 L2 ACNT: _____
R1 L3 BCNT: _____
BUFSIZE
L2 R0 CCNT: _____
R2 R1 ‘BIDX: _____
L3 R2 ‘CIDX: _____
R3 R3 Could you calculate these ?

12 - 24 C6000 Embedded Design Workshop Using BIOS - Using EDMA3

 Additional Information

Additional Information

C6000 Embedded Design Workshop Using BIOS - Using EDMA3 12 - 25

Additional Information

12 - 26 C6000 Embedded Design Workshop Using BIOS - Using EDMA3

 Additional Information

C6000 Embedded Design Workshop Using BIOS - Using EDMA3 12 - 27

Notes

Notes

12 - 28 C6000 Embedded Design Workshop Using BIOS - Using EDMA3

 "Grab Bag" Topics
“Grab Bag” Explanation
Several other topics of interest remain. However, there is not enough time to cover them all. Most
topics take over an hour to complete especially if the labs are done. Students can vote which ones
they’d like to see first, second, third in the remaining time available.
Shown below is the current list of topics. Vote for your favorite two and the instructor will tally
the results and make any final changes to the remaining agenda.
While all of these topics cannot be covered, the notes are in your student guide. So, at a
minimum, you have some reference material on the topics not covered live to take home with
you.

Topic Choices

C6000 Embedded Design Workshop Using BIOS - "Grab Bag" Topics 13 - 1

Error! No text of specified style in document.

*** insert blank page here ***

13 - 2 C6000 Embedded Design Workshop Using BIOS - "Grab Bag" Topics

 Intro to DSP/BIOS
Introduction
In this chapter an introduction to the general nature of real-time systems and the DSP/BIOS
operating system will be considered. Each of the concepts noted here will be studied in greater
depth in succeeding chapters.

Objectives

Objectives

 Grab bag chapter assumes students have

already been through Intro to SYS/BIOS
 Describe how to create a new BIOS project
 Learn how to configure BIOS using TCF files
 Lab 13a – Create and debug a simple
DSP/BIOS application

C6000 Embedded Design Workshop Using BIOS - Intro to DSP/BIOS GrabBag - 13a - 1
Module Topics

Module Topics
Intro to DSP/BIOS ...................................................................................................................................13-1
Module Topics........................................................................................................................................13-2
DSP/BIOS Overview ..............................................................................................................................13-3
Threads and Scheduling .........................................................................................................................13-4
Real-Time Analysis Tools ......................................................................................................................13-6
DSP/BIOS Configuration – Using TCF Files ........................................................................................13-7
Creating A DSP/BIOS Project ...............................................................................................................13-8
Memory Management – Using the TCF File .......................................................................................13-10
Lab 12a: Intro to DSP/BIOS ................................................................................................................13-11
Lab 12a – Procedure ........................................................................................................................13-12
Create a New Project ...................................................................................................................13-12
Add a New TCF File and Modify the Settings ............................................................................13-14
Build, Load, Play, Verify… ........................................................................................................13-16
Benchmark and Use Runtime Object Viewer (ROV) .................................................................13-19
Additional Information & Notes ..........................................................................................................13-22

GrabBag - 13a - 2 C6000 Embedded Design Workshop Using BIOS - Intro to DSP/BIOS
 DSP/BIOS Overview

DSP/BIOS Overview

C6000 Embedded Design Workshop Using BIOS - Intro to DSP/BIOS GrabBag - 13a - 3
Threads and Scheduling

Threads and Scheduling

GrabBag - 13a - 4 C6000 Embedded Design Workshop Using BIOS - Intro to DSP/BIOS
 Threads and Scheduling

C6000 Embedded Design Workshop Using BIOS - Intro to DSP/BIOS GrabBag - 13a - 5
Real-Time Analysis Tools

Real-Time Analysis Tools

GrabBag - 13a - 6 C6000 Embedded Design Workshop Using BIOS - Intro to DSP/BIOS
 DSP/BIOS Configuration – Using TCF Files

DSP/BIOS Configuration – Using TCF Files

C6000 Embedded Design Workshop Using BIOS - Intro to DSP/BIOS GrabBag - 13a - 7
Creating A DSP/BIOS Project

Creating A DSP/BIOS Project

GrabBag - 13a - 8 C6000 Embedded Design Workshop Using BIOS - Intro to DSP/BIOS
 Creating A DSP/BIOS Project

TCF Generates Key Files…

 file.tcf file generates (when saved) two very important files:
•filecfg.h: header file for all BIOS libraries (must #include in project)
•filecfg.cmd: linker.cmd file for your project (add to project)

filecfg.h

filecfg.cmd

19

C6000 Embedded Design Workshop Using BIOS - Intro to DSP/BIOS GrabBag - 13a - 9
Memory Management – Using the TCF File

Memory Management – Using the TCF File

Remember ?
Memory Segments
Sections
1180_0000 256K IRAM
.text
.bss
.far 6400_0000 4MB FLASH
.cinit
.cio
C000_0000 512MB DDR2
.stack

 How do you define the memory segments (e.g. IRAM, FLASH, DDR2) ?
 How do you place the sections into these memory segments ?

How do we accomplish this with a .tcf file ?

21

GrabBag - 13a - 10 C6000 Embedded Design Workshop Using BIOS - Intro to DSP/BIOS
 Lab 12a: Intro to DSP/BIOS

Lab 12a: Intro to DSP/BIOS

Now that you’ve been through creating projects, building and running code, we now turn the page
to learn about how DSP/BIOS-based projects work. This lab, while quite simple in nature, will
help guide you through the steps of creating (possibly) your first BIOS project in CCSv4.
This lab will be used as a “seed” for future labs.

Application: blink USER LED_1 on the EVM every second

Key Ideas: main() returns to BIOS scheduler, IDL fxn runs to blink LED
What will you learn? .tcf file mgmt, IDL fxn creation/use, creation of BIOS project,
benchmarking code, ROV
Pseudo Code:
main() – init BSL, init LED, return to BIOS scheduler

ledToggle() – IDL fxn that toggles LED_1 on EVM

C6000 Embedded Design Workshop Using BIOS - Intro to DSP/BIOS GrabBag - 13a - 11
Lab 12a: Intro to DSP/BIOS

Lab 12a – Procedure

If you can’t remember how to perform some of these steps, please refer back to the previous labs
for help. Or, if you really get stuck, ask your neighbor. If you AND your neighbor are stuck, then
ask the instructor (who is probably doing absolutely NOTHING important) for help. 

Create a New Project

1. Create a new project named “bios_led”.
Create your new project in the following directory:
C:\SYSBIOSv4\Labs\Lab12a\Project

When the following screen appears, make sure you click Next instead of Finish:

GrabBag - 13a - 12 C6000 Embedded Design Workshop Using BIOS - Intro to DSP/BIOS
 Lab 12a: Intro to DSP/BIOS

2. Choose a Project template.

This screen was brand new in CCSv4.2.2. And it is not intuitive to the casual observer that
the Next button above even exists – you see Finish, you click it. Ah, but the hidden secret is
the Next button. The CCS developers are actually trying to do us a favor IF you understand
what a BIOS template is.

As you can see, there are many choices. Empty Projects are just that – empty – just a path to
the include files for the selected processor. Go ahead and click on “Basic Exmaples” to see
what’s inside. Click on all the other + signs to see what they contain. Ok, enough playing
around. We are using BIOS 5.41.xx.xx in this workshop. So, the correct + sign to choose in
the end is the one that is highlighted above.
3. Choose the specific BIOS template for this workshop.
Next, you’ll see the following screen:

Select “Empty Example”. This will give us the paths to the BIOS include directories. The
other examples contain example code and .tcf files. NOW you can click Finish.

C6000 Embedded Design Workshop Using BIOS - Intro to DSP/BIOS GrabBag - 13a - 13
Lab 12a: Intro to DSP/BIOS

4. Add files to your project.

From the lab’s \Files directory, ADD the following files:
led.c, main.c, main.h
Open each and inspect them. They should be pretty self explanatory.
5. Link the BSL library to your project.
Right-click on the project and select “Link…” and browse to:
C:\SYSBIOSv4\Labs\DSP_BSL\bsl\lib\evmomapl138_bsl.lib

6. Add an include path for the BSL library \inc directory.

Right-click on the project and select “Build Properties”. Select C6000 Compiler, then Include
Options (you’ve done this before). Add the proper path for the BSL include dir (else you will
get errors when you build).

At this point in time, what files are we missing? There are 3 of them. Can you name them?
______________ ______________ ______________

Add a New TCF File and Modify the Settings

7. Add a new TCF file.
As discussed earlier, you have several options available to you regarding the TCF file. In this
lab, we chose to use an EMPTY BIOS example from the project templates. Therefore, no
TCF file exists.
Referring back to the material in this chapter, create a NEW TCF file (File  New 
DSP/BIOS v5.x Config File). Name it: bios_led.tcf. When prompted to pick a
platform seed tcf file, type “evm6748” into the filter filter and choose the tcf that pops up.
CCS should have placed your new TCF file in the project directory AND added it to your
project. Check to make sure both of these statements are true.
If the new TCF file did not open automatically when created, double-click on the new TCF
file (bios_led.tcf) to open it.

8. Create a HEAP in memory.

All BIOS projects need a heap. Why this doesn’t get created for you in the “seed” tcf file is a
good question. The fact that it doesn’t causes a heap full of troubles. If you ever get any
strange unexplainable errors when you build BIOS projects, check THIS first.
Open the TCF file (if it’s not already) and click on System. Right-click on MEM and select
Properties. The checkbox for “No Dynamic Heaps” is most likely not checked (because we
used an existing TCF file that had this selection as default).
UNCHECK this box (if not already done) to specify that you want a heap created. A warning
will bark at you that you haven’t defined a memory segment yet – no kidding. Just ignore the
warning and click OK. (Note: this warning probably won’t occur because we used an existing
TCF file).
Click the + next to MEM. This will display the “seed” TCF memory areas already defined.
Thank you.

GrabBag - 13a - 14 C6000 Embedded Design Workshop Using BIOS - Intro to DSP/BIOS
 Lab 12a: Intro to DSP/BIOS

Right-click IRAM and select properties.

Check the box that says “create a heap in this memory” (if not already checked) and change
and change the heap size to 4000h.
Click Ok.
Now that we HAVE a heap in IRAM (that’s another name for L2 by the way), we need to tell
the mother ship (MEM) where our heap is.
Right-click on MEM and select Properties. Click on both down arrows and select IRAM for
both (again, this is probably already done for you). Click OK. Now she’s happy…

Save the TCF file.

Note: FYI – throughout the labs, we will throw in the “top 10 or 20” tips that cause Debug
nightmares during development. Here’s your first one…

C6000 Embedded Design Workshop Using BIOS - Intro to DSP/BIOS GrabBag - 13a - 15
Lab 12a: Intro to DSP/BIOS

Hint: TIP #1 – Always create a HEAP when working with BIOS projects.

Build, Load, Play, Verify…

9. Ensure you have the proper target config file selected as Default.
10. Build your project.
Fix any errors that occur (and there will be some, just keep reading…). You didn’t make
errors, did you? Of course you did. Remember when we said that ANY BIOS project needs
the cfg.h file included in one of the source files? Yep. And it was skipped on purpose to
drive the point home.
Open main.h for editing and add the following line as the FIRST include in main.h:
#include “bios_ledcfg.h”
Rebuild and see if the errors go away. They should. If you have more, than you really DO
need to debug something. If not, move on…

Hint: TIP #2 – Always #include the cfg.h file in your application code when using BIOS as
the FIRST included header file.

11. Inspect the “generated” files resulting from our new TCF file.
In the project view, locate the following files and inspect them (actually, you’ll need to
BUILD the project before these show up):
bios_ledcfg.h
bios_ledcfg.cmd
There are other files that get generated by the existence of .tcf which we will cover in later
labs. The .cmd file is automatically added to your project as a source file. However, your
code must #include the cfg.h file or the compiler will think all the BIOS stuff is “declared
implicitly”.

GrabBag - 13a - 16 C6000 Embedded Design Workshop Using BIOS - Intro to DSP/BIOS
 Lab 12a: Intro to DSP/BIOS

12. Debug and “Play” your code.

Click the Debug “Bug” – this is equivalent to “Debug Active Project”. Remember, this code
blinks LED_1 near the bottom of the board. When you Play your code and the LED blinks,
you’re done.
When the execution arrow reaches main(), hit “Play”. Does the LED blink?
No? What is going on?
Think back to the scheduling diagram and our discussions. To turn BIOS ON, what is the
most important requirement? main() must RETURN or fall out via a brace }. Check
main.c and see if this is true. Many users still have while() loops in their code and
wonder why BIOS isn’t working. If you never return from main(), BIOS will never run.

Hint: TIP #3 – BIOS will NOT run if you don’t exit main().

Ok, so no funny tricks there - that checks out.

Next question: how is the function ledToggle() getting called? Was it called in main()?
Hmmm. Who is supposed to call ledToggle()?
When your code returns from main(), where does it go? The BIOS scheduler. And,
according to our scheduling diagram and the threads we have in the system, which THREAD
will the scheduler run when it returns from main()?

Can you explain what needs to be done? ________________________________________

C6000 Embedded Design Workshop Using BIOS - Intro to DSP/BIOS GrabBag - 13a - 17
Lab 12a: Intro to DSP/BIOS

13. Add IDL object to your TCF.

The answer is: the scheduler will run the IDL thread when nothing else exists. All other
thread types are higher priority. So, how do you make the IDL thread call ledToggle()?
Simple. Add an IDL object and point it to our function.
Open the TCF file and click on Scheduling. Right-click on IDL and select “Insert IDL”.
Name the IDL Object “IDL_ledToggle”.
Now that we have the object, we need to tell the object what to do – which fxn to run. Right-
click on IDL_ledToggle and select Properties. You’ll notice a spot to type in the function
name.
Ok, make room for another important tip. BIOS is written in ASSEMBLY. The
ledToggle() function is written in C. How does the compiler distinguish between an
assembly label or symbol and a C label? The magic underscore “_”. All C symbols and
labels (from an assembly point of view) are preceded with an underscore.

Hint: TIP #4 – When entering a fxn name into BIOS objects, precede the name with an
underscore – “_”. Otherwise you will get a symbol referencing error which is difficult to
locate.

SO, the fxn name you type in here must be preceded by an underscore:

You have now created an IDL object that is associated with a fxn. By the way, when you
create HWI, SWI and TSK objects later on, guess what? It is the SAME procedure. You’ll get
sick of this by the end of the week – right-click, insert, rename, right-click and select
Properties, type some stuff. There – that is DSP/BIOS in a nutshell. 
14. Build and Debug AGAIN.
When the execution arrow hits main(), click “Play”. You should now see the LED
blinking. If you ever HALT/PAUSE, it will probably pause inside a library fxn that has no
source associated with it. Just X that thing.
At this point, your first BIOS project is working. Do NOT “terminate all” yet. Simply click
on the C/C++ perspective and move on to a few more goodies…

GrabBag - 13a - 18 C6000 Embedded Design Workshop Using BIOS - Intro to DSP/BIOS
 Lab 12a: Intro to DSP/BIOS

Benchmark and Use Runtime Object Viewer (ROV)

15. Benchmark LED BSL call.
So, how long does it take to toggle an LED? 10, 20, 50 instruction cycles? Well, you would
be off by several orders of magnitude. So, let’s use the CLK module in BIOS to determine
how long the LED_toggle() BSL call takes.
This same procedure can be used quickly and effectively to benchmark any area in code and
then display the results either via a local variable (our first try) or via another BIOS module
called LOG (our 2nd try).
BIOS uses a hardware timer for all sorts of things which we will investigate in different labs.
The high-resolution time count can be accessed through a call to CLK_gethtime() API.
Let’s use it…
Open led.c for editing.
Allocate three new variables: start, finish and time. First, we’ll get the CLK
value just before the BSL call and then again just after. Subtract the two numbers and you
have a benchmark – called time. This will show up as a local variable when we use a
breakpoint to pause execution.
Your new code in led.c should look something like this:

Don’t type in the call to LOG_printf() just yet. We’ll do that in a few moments…

C6000 Embedded Design Workshop Using BIOS - Intro to DSP/BIOS GrabBag - 13a - 19
Lab 12a: Intro to DSP/BIOS

16. Build, Debug, Play.

When finished, build your project – it should auto-download to the EVM. Switch to the
Debug perspective and set a breakpoint as shown in the previous diagram. Click “Play”.
When the code stops at your breakpoint, select View → Local. Here’s the picture of what
that will look like:

Are you serious? 1.57M CPU cycles. Of course. This mostly has to do with going through
I2C and a PLD and waiting forever for acknowledge signals (can anyone say “BUS
HOLD”?). Also, don’t forget we’re using the “Debug” build configuration with no
optimization. More on that later. Nonetheless, we have our benchmark.
17. Open up TWO .tcf files – is this a problem?
The author has found a major “uh oh” that you need to be aware of. Open your .tcf file and
keep it open. Double-click on the project’s TCF file AGAIN. Another “instance” of this
window opens. Nuts. If you change one and save the other, what happens? Oops. So, we
recommend you NOT minimize TCF windows and then forget you already have one open
and open another. Just BEWARE…
18. Add LOG Object and LOG_printf() API to display benchmark.
Open led.c for editing and add the LOG_printf() statement as shown in a previous
diagram.
Open the TCF for editing. Under Instrumentation, add a new LOG object named “trace”.
Remember? Right-click on LOG, insert log, rename to trace, click OK.

Save the TCF.

GrabBag - 13a - 20 C6000 Embedded Design Workshop Using BIOS - Intro to DSP/BIOS
 Lab 12a: Intro to DSP/BIOS

19. Pop over to Windows Explorer and analyse the \Project folder.
Remember when we said that another folder would be created if you were using BIOS? It
was called .gconf. This is the GRAPHICAL config tool in action that is fed by the .cdb
file. When you add a .tcf file, the graphical and textual tools must both exisit and follow each
other. Go check it out. Is it there? Ok…back to the action…
20. Build, Debug, Play – use ROV.
When the code loads, remove the breakpoint in led.c. Then, click Play. PAUSE the execution
after about 5 seconds. Open the ROV tool via Tools → ROV. When ROV opens, select LOG
and one of the sequence numbers – like 2 or 3:

Notice the result of the LOG_printf() under “message”. You can choose other sequence
numbers and see what their times were.
You can also choose to see the LOG messages via Tools RTA Printf Logs. Try that now and
see what you get. If you’d like to change the behaviour of the LOGging, go back to the LOG
object and try a bigger buffer, circular (last N samples) or fixed (first N samples). Experiment
away…
When we move on to a TSK-based system, the ROV will come in very handy. This tool
actually replaced the older KOV (kernel object viewer) in the previous CCS. Also, in future
labs, we’ll use the RTA (Real-time Analysis) tools to view Printf logs directly. By then,
you’ll know two different ways to access debug info.

Note: Explain this to me – so, the tool is called ROV which stands for RUNTIME Object
Viewer. But the only way to VIEW the OBJECT is in STOP time. Hmmm. Marketing?
Illegal drug use? Ok, so it “collects” the data during runtime…but still…to the author,
this is a stretch and confuses new users. Ah, but now you know the “rest of the story”…

Terminate the Debug Session and close the project.

You’re finished with this lab. Please raise your hand and let the instructor
know you are finished with this la (maybe throw something heavy at them to
get their attention or say “CCS crashed – AGAIN !” – that will get them
running…)

C6000 Embedded Design Workshop Using BIOS - Intro to DSP/BIOS GrabBag - 13a - 21
Additional Information & Notes

Additional Information & Notes

GrabBag - 13a - 22 C6000 Embedded Design Workshop Using BIOS - Intro to DSP/BIOS
 Additional Information & Notes

C6000 Embedded Design Workshop Using BIOS - Intro to DSP/BIOS GrabBag - 13a - 23
Additional Information & Notes

*** page is NOT blank ***

GrabBag - 13a - 24 C6000 Embedded Design Workshop Using BIOS - Intro to DSP/BIOS
 Booting From Flash
Introduction
In this chapter the steps required to migrate code from being loaded and run via CCS to running
autonomously in flash will be considered. Given the AISgen and SPIWriter tools, this is a simple
process that is desired toward the end of the design cycle.

Objectives

Objectives

 Compare/contrast the startup events of

CCS (GEL) vs. booting from flash
 Describe how to use AISgen and
SPI Flash Writer utilities to create and
burn a flash boot image
 Lab 13b – Convert the keystone lab to
a bootable flash image, POR, run

C6000 Embedded Design Workshop Using BIOS - Booting From Flash GrabBag - 13b - 1
Module Topics

Module Topics
Booting From Flash ..................................................................................................................................13-1
Module Topics........................................................................................................................................13-2
Booting From Flash ...............................................................................................................................13-3
Boot Modes – Overview ....................................................................................................................13-3
System Startup ...................................................................................................................................13-4
Init Files .............................................................................................................................................13-4
AISgen Conversion............................................................................................................................13-5
Build Process .....................................................................................................................................13-5
SPIWriter Utility (Flash Programmer) ..............................................................................................13-6
ARM + DSP Boot ..............................................................................................................................13-7
Additonal Info…................................................................................................................................13-8
C6748 Boot Modes (S7, DIP_x) ........................................................................................................13-9
Lab 13b: Booting From Flash .............................................................................................................13-11
Lab13b – Booting From Flash - Procedure......................................................................................13-12
Tools Download and Setup (Students: SKIP STEPS 1-6 !!) .......................................................13-12
Build Keystone Project: [Src → .OUT File] ..............................................................................13-16
Use AISgen To Convert [.OUT → .BIN]...................................................................................13-21
Program the Flash: [.BIN → SPI1 Flash] ...................................................................................13-29
Optional – DDR Usage ...............................................................................................................13-31
Additional Information.........................................................................................................................13-32
Notes ....................................................................................................................................................13-33
More Notes… .......................................................................................................................................13-34

GrabBag - 13b - 2 C6000 Embedded Design Workshop Using BIOS - Booting From Flash
 Booting From Flash

Booting From Flash

Boot Modes – Overview

C6000 Embedded Design Workshop Using BIOS - Booting From Flash GrabBag - 13b - 3
Booting From Flash

System Startup

Init Files

GrabBag - 13b - 4 C6000 Embedded Design Workshop Using BIOS - Booting From Flash
 Booting From Flash

AISgen Conversion

Build Process

C6000 Embedded Design Workshop Using BIOS - Booting From Flash GrabBag - 13b - 5
Booting From Flash

SPIWriter Utility (Flash Programmer)

GrabBag - 13b - 6 C6000 Embedded Design Workshop Using BIOS - Booting From Flash
 Booting From Flash

ARM + DSP Boot

C6000 Embedded Design Workshop Using BIOS - Booting From Flash GrabBag - 13b - 7
Booting From Flash

Additonal Info…

GrabBag - 13b - 8 C6000 Embedded Design Workshop Using BIOS - Booting From Flash
 Booting From Flash

C6748 Boot Modes (S7, DIP_x)

Flash Pin Settings – C6748 EVM

EMU MODE SPI BOOT
8 ON BOOT[4] 8 OFF
7 BOOT[3] 7
6 BOOT[2] 6
5 ON BOOT[1] 5
4 NC 4
3 I/O (1.8/3.3) 3
2 Audio EN 2
1 LCD EN 1
SW7 Default = SPI BOOT
SW7
23

C6000 Embedded Design Workshop Using BIOS - Booting From Flash GrabBag - 13b - 9
Booting From Flash

*** this page was accidentally created by a virus – please ignore ***

GrabBag - 13b - 10 C6000 Embedded Design Workshop Using BIOS - Booting From Flash
 Lab 13b: Booting From Flash

Lab 13b: Booting From Flash

In this lab, a .out file will be loaded to the on-board flash memory so that the program may be run
when the board is powered up, with no connection to CCS.
Any lab solution would work for this lab, but again we’ll standardize on the “keystone” lab so
that we ensure a known quantity.

C6000 Embedded Design Workshop Using BIOS - Booting From Flash GrabBag - 13b - 11
Lab 13b: Booting From Flash

Lab13b – Booting From Flash - Procedure

Hint: This lab procedure will work with either the C6748 SOM or OMAP-L138 SOM. The
basic procedure is the same but a few steps are VERY different. These will be noted
clearly in this document. So, please pay attention to the HINTS and grey boxes like this
one along the way.

Tools Download and Setup (Students: SKIP STEPS 1-6 !!)

The following steps in THIS SECTION ONLY have already been performed. So, workshop
attendees can skip to the next section. These steps are provided in order to show exactly
where and how the flash/boot environment was set up (for future reference).
1. Download AISgen utility – SPRAB41c.
Download the pdf file from here:
http://focus.ti.com/dsp/docs/litabsmultiplefilelist.tsp?docCategoryId=1&familyId=1621&liter
atureNumber=sprab41c&sectionId=3&tabId=409
A screen cap of the pdf file is here:

The contents of this zip are shown here:

GrabBag - 13b - 12 C6000 Embedded Design Workshop Using BIOS - Booting From Flash
 Lab 13b: Booting From Flash

2. Create directories to hold tools and projects.

Three directories need to be created:
C:\SYSBIOSv4\Labs\Lab13b_keystone – will contain the audio project
(keystone) to build into a .OUT file.
C:\SYSBIOSv4\Labs\Lab13b_ARM_Boot – will contain the ARM
boot code required to start up the DSP after booting.
C:\SYSBIOSv4\Labs\Lab13b_SPIWriter – will contain the SPIWriter.out
file used to program the flash on the EVM.
C:\SYSBIOSv4\Labs\Lab13b_AIS – contains the AISgen.exe file (shown
above) and is where the resulting AIS script (bin) will be located after running the utility
(.OUT → .BIN)
Place the “keystone” files into the \Lab13b_keystone\Files directory. Users will
build a new project to get their .OUT file.
Place the recently downloaded AISgen.exe file into \Lab13b_AIS directory.

C6000 Embedded Design Workshop Using BIOS - Booting From Flash GrabBag - 13b - 13
Lab 13b: Booting From Flash

3. Download SPI Flash Utilities.

You can find the SPI Flash Utility here:
http://processors.wiki.ti.com/index.php/Serial_Boot_and_Flash_Loading_Utility_for_OMAP-L138
This is actually a TI wiki page:

From here, locate the following and click “here” to go to the download page:

This will take you to a SourceForge site that will contain the tools you need to download.

Click on the latest version under OMAP-L138 and download the tar.gz file. UnTAR the
contents and you’ll see this:

The path we need is \OMAP-L138. If we dive down a bit, we will find the
SPIWriter.out file that is used to program the flash with our boot image (.bin).

GrabBag - 13b - 14 C6000 Embedded Design Workshop Using BIOS - Booting From Flash
 Lab 13b: Booting From Flash

4. Copy the SPIWriter.out file to \Lab13b_SPIWriter\ directory.

Shown below is the initial contents of the Flash Utility download:

Copy the following file to the \Lab13b_SPIWriter\ directory:

SPIWriter_OMAP-L138.out

5. Install AISgen.
Find the download of the AISgen.exe file and double-click it to install. After installation,
copy a shortcut to the desktop for this program:

6. Create the keystone project.

Create a new CCSv5 SYS/BIOS project with the source files listed in
C:\SYSBIOSv4\Lab13b_keystone\Files. Create this project in the neighboring
\Project folder. Also, don’t forget to add the BSL library and BSL includes (as normal)
Make sure you use the RELEASE configuration only.

C6000 Embedded Design Workshop Using BIOS - Booting From Flash GrabBag - 13b - 15
Lab 13b: Booting From Flash

Hint: [workshop students: START HERE]

Build Keystone Project: [Src → .OUT File]

7. Import keystone audio project and make a few changes.
Import “keystone_flash” project from the following directory:
C:\SYSBIOSv4\Labs\Lab13b_keystone\Project
This project was built for emulation with CCSv5 – i.e there is a GEL file that sets up our
PLL, DDR2, etc. This is actually the SOLUTION to the clk_rta_audio lab (with the
platform file set to all data/code INTERNAL). In creating a boot image, as discussed in the
chapter, we have to perform these actions in code vs. the GEL creating this nice environment
for us.
So, we have a choice here – write code that runs in main to set up PLL0, PLL1, DDR, etc.
OR have the bootloader do it FOR US. Having the bootloader perform these actions offers
several advantages – fewer mistakes by human programmers AND, these settings are done at
bootload time vs waiting all the way until main() for the settings to take effect.

Hint: The following step is for OMAP-L138 SOM Users ONLY !!

8. Set address of reset vector for DSP

Here is one of the “tricks” that must be employed when using both the ARM and DSP. The
ARM code has to know the entry point (reset vector, c_int00) of the DSP. Well, if you just
compile and link, it could go anywhere in L2. If your class is based on SYS/BIOS, please
follow those instructions. If you’re interested in how this is done with DSP/BIOS, that
solution is also provided for your reference.

SYS/BIOS Users – must add two lines of script code to the CFG file as shown. This script
forces the reset vector address for the DSP to 0x11830000. Locate this in the given .cfg file
and UNCOMMENT these two lines of code.

DSP/BIOS Users – must create a linker.cmd file as shown below to force the address of the
reset vector. This little command file specifies EXACTLY where the .boot section should go
for a BIOS project (this is not necessary for a non-BIOS program).

GrabBag - 13b - 16 C6000 Embedded Design Workshop Using BIOS - Booting From Flash
 Lab 13b: Booting From Flash

9. Examine the platform file.

In the previous step, we told the tools to place the DSP reset vector specifically at address
0x11830000. This is the upper 64K of the 256K block of L2 RAM. One of our labs in the
workshop specified L2 cache as 64K. Guess what? If that setting is still true, L2 cache
effective starts at the same address – which means that this address is NOT available for the
reset vector. WHOOPS.
Select Build Options and determine WHICH platform file is associated with this project.
Once you have determined which platform it is, open it and examine it. Make sure L2 cache
is turned off – or ZERO – and that all code/data/stack segments are allocated in IRAM. If this
is not true, then “make it so”.
10. Build the keystone project.
Using the DEBUG build configuration, build the project. This should create the .OUT file.
Go check the \Debug directory and locate the .OUT file:
keystone_flash.out
Load the .OUT file and make sure it executes properly. We don’t want to flash something
that isn’t working. 
Do not close the Debug session yet.

C6000 Embedded Design Workshop Using BIOS - Booting From Flash GrabBag - 13b - 17
Lab 13b: Booting From Flash

11. Determine silicon rev of the device you are currently using.
AISgen will want to know which silicon rev you are using. Well, you can either attempt to
read it off the device itself (which is nearly impossible) or you can visit a convenient place in
memory to see it.
Now that you have the Debug perspective open, this should be relatively straightforward.
Open a memory view window and type in the following address:
0x11700000
Can you see it? No? Shame on you. Ok. Try changing the style view to “Character” instead.
See something different?
Like this?

That says “d800k002” which means rev2 of the silicon. That’s an older rev…but whatever
yours is…write it down below:
Silicon REV: ____________________

FYI – for OMAP-L138 (and C6748), note the following:

d800k002 = Rev 1.0 silicon (common, but old)
d800k004 = Rev 1.1 silicon (fairly common)
d800k006 = Rev 2.0 silicon (if you have a newer board, this is the latest)
There ARE some differences between Rev1 and Rev2 silicon that we’ll mention later in this
lab – very important in terms of how the ARM code is written.
You will probably NEVER need to change the memory view to “Character” ever again – so
enjoy the moment. 
Next, we need to convert this .out file and combine it with the ARM .out file and create a
single flash image for both using the AIS script via AISgen…

GrabBag - 13b - 18 C6000 Embedded Design Workshop Using BIOS - Booting From Flash
 Lab 13b: Booting From Flash

12. Use the Debug GEL script to locate the Silicon Rev.
This script can be run at any time to debug the state of your silicon and all of the important
registers and frequencies your device is running at. This file works for both OMAP-L137/8
and C6747/8 devices. It is a great script to provide feedback for your hardware engineer.
It goes kind of like this: we want a certain frequency for PLL1. We read the documentation
and determine that these registers need to be programmed to a, b and c. You write the code,
program them and then build/run. Well, is PLL1 set to the frequency you thought it should
be? Run the debug script and find out what the processor is “reporting” the setting is. Nice.
This script outputs its results to the Console window.

Let’s use the debug script to determine the silicon rev as in the previous step.
First, we need to LOAD the gel file. This file can be downloaded from the wiki shown in the
chapter. We have already done that for you and placed that GEL file in the \gel directory next
to the GEL file you’ve been using for CCS.

Select Tools  GEL Files.

Right-click in the empty area under the currently loaded GEL file and select: Load Gel.

The \gel directory should show up and the file OMAPL1x_debug.gel should be listed. If
not, browse to C:\SYSBIOSv4\Labs\DSP_BSL\gel.

Click Open.

C6000 Embedded Design Workshop Using BIOS - Booting From Flash GrabBag - 13b - 19
Lab 13b: Booting From Flash

This will load the new GEL file and place the scripts under the “Scripts” menu.
Select “Scripts”  Diagnostics  Run All:

You can choose to run only a specific script or “All” of them. Notice the output in the
Console window. Scroll up and find the silicon revision. Also make note of all of the registers
and settings this GEL file reports. Quite extensive.

Does your report show the same rev as you found in the previous step? Let’s hope so…

Write down the Si Rev again here:

Silicon Rev (again): ______________________

GrabBag - 13b - 20 C6000 Embedded Design Workshop Using BIOS - Booting From Flash
 Lab 13b: Booting From Flash

Use AISgen To Convert [.OUT → .BIN]

AISgen (Application Image Script Generator) is a free downloadable tool from TI – check
out the beginning of this lab for the links to get this tool.
13. Locate AISgen.exe (only if requiring installation…if not, see next step).
The installation file has already been downloaded for you and is sitting in the following
directory:
C:\SYSBIOSv4\Labs\Lab13b_AIS
Here, you will find the following install file:

This is the INSTALL file (fyi). You don’t need to use this if the tool is already installed on
your computer…
14. Run AISgen.
There should be an icon on your desktop that looks like this:

If not, you will need to install the tool by double-clicking on the install file, installing it and
then creating a shortcut to it on the desktop (you’ll find it in Programs → Texas Instruments
→ AISgen).
Double-click on the icon to launch AISgen and fill out the dialogue box as shown on the next
page…there are several settings you need…so be careful and go SLOWLY here…
It is usually BEST to place all of your PLL and DDR settings in the flash image and have the
bootloader set these up vs. running code on the DSP to do it. Why? Because the DSP then
comes out of reset READY to go at the top speeds vs. running “slow” until your code in
main() is run. So, that’s what we plan to do….

Note: Each dialogue has its own section below. It is quite a bit of setup…but hey, you are
enabling the bootloader to set up your entire system. This is good stuff…but it takes some
work…

Hint: When you actually use the DSP to burn the flash in a later step, the location you store
your .bin file too (name of the .bin file AND the directory path you place the .bin file in)
CANNOT have ANY SPACES IN THE PATH OR FILENAME.

C6000 Embedded Design Workshop Using BIOS - Booting From Flash GrabBag - 13b - 21
Lab 13b: Booting From Flash

Main dialogue – basic settings.

Fill out the following on this page:

Device Type (match it up with what you determined before)
For OMAP-L138 SOM (ARM + DSP), choose “ARM”. If you’re using the 6748 SOM,
choose “DSP”.
Boot Mode: SPI1 Flash. On the OMAP-L138, the SPI1 port and UART2 ports are
connected to the flash.
For now, wait on filling in the Application and Output files.

Hint: For C6748 SOM, choose “DSP” as the Device type

Hint: For OMAP-L138 SOM, choose “ARM” as the Device type

Note: you will type in these paths in a future step – do NOT do it now…

GrabBag - 13b - 22 C6000 Embedded Design Workshop Using BIOS - Booting From Flash
 Lab 13b: Booting From Flash

Configure PLL0, PLL0 Tab

On the “General” tab, check the box for “Configure PLL0” as shown:

Then click on the PLL0 tab and view these settings. You will see the defaults show up. Make
the following modifications as shown below.
Change the multiplier value from 20 to 25 and notice the values in the bottom RH corner
change.

Peripheral Tab

Next, click on the Peripheral tab. This is where you will set the SPI Clock. It is a function
(divide down) from the CPU clock. If you leave it at 1MHz, well, it will work, but the
bootload will take WAY longer. So, this is a “speed up” enhancement.
Type “20” into the SPI Clock field as shown:

Also check the “Enable Sequential Read” checkbox. Why is this important? Speed of the boot
load. If this box is unchecked, the ROM code will send out a read command (0x03) plus a 24-
bit address before every single BYTE. That is a TON of read commands.
However, if we CHECK this box, the ROM code will send out a single 24-bit address
(0x000000) and then proceed to read out the ENTIRE boot image. WAY WAY faster.

C6000 Embedded Design Workshop Using BIOS - Booting From Flash GrabBag - 13b - 23
Lab 13b: Booting From Flash

Configure PLL1
Just in case you EVER want to put code or data into the DDR, PLL1 needs to be set in the
flash image and therefore configured by the bootloader.
So, click the checkbox next to “Configure PLL1”, click on that tab, and use the following
settings:

This will clock the DDR at 300MHz. This is equivalent to what our GEL file sets the DDR
frequency to. We don’t have any code in DDR at the moment – but now we have it setup just
in case we ever do later on. Now, we need to write values to the DDR config registers…

Configure DDR

You know the drill. Click the proper checkbox on the main dialogue page and click on the
DDR tab. Fill in the following values as shown. If you want to know what each of the values
are on the right, look it up in the datasheet. 

GrabBag - 13b - 24 C6000 Embedded Design Workshop Using BIOS - Booting From Flash
 Lab 13b: Booting From Flash

Configure PSC0, PSC0 Tab

Next, we need to configure the Low Power Sleep Controller (LPSC) to allow the ARM to
write to the DSP’s L2 memory. If both the ARM and DSP code resided in L3, well, the ARM
bootloader could then easily write to L3. But, with a BIOS program, BIOS wants to live in L2
DSP memory (around 0x11800000). In order for the ARM bootloader code to write to this
address, we need to have the DSP clocks powered up. Enabling PSC0 does this for us.
On the main page, “check” the box next to “Configure PSC” and go to the PSC tab.
In the GEL file we’ve been using in the workshop, a function named
PSC_All_On_Full_EVM() runs to set all the PSC values. We could cheat and just type in
“15” as shown below:
Minimum Setting (don’t use this for the lab):

This would Enable module 15 of the PSC which says “de-assert the reset on the DSP
megamodule” and enable the clocks so that the ARM can write to the DSP memory located in
L2. However, this setting does NOT match what the GEL file did for us. So, we need to
enable MORE of the PSC modules so that we match the GEL file.

Note: When doing this for your own system, you’ll need to pick and choose the PSC modules
that are important to your specific system.

Better Setting (USE THIS ONE for the lab – or as a starting point for your own system)

The numbers scroll out of sight, so here are the values:

PSC0: 0;1;2;3;4;5;9;10;11;12;13;15
PSC1: 0;1;2;3;4;5;6;7;9;10;11;12;13;14;15;16;17;18;19;20;21;24;25;26;27;28;29;30;31

Note: Note: PSC1 is MISSING modules 8, 22-23 (see datasheet for more details on these).

C6000 Embedded Design Workshop Using BIOS - Booting From Flash GrabBag - 13b - 25
Lab 13b: Booting From Flash

Notice for SATA users:

PSC1 Module 8 (SATA) is specifically NOT being enabled. There is a note in the System
Reference Guide saying that you need to set the FORCE bit in MDCTL when enabling
SATA. That’s not an option in the GUI/bootROM so we simply cannot enable it. If you
ignore the author’s advice and enable module 8 in PSC1, you’ll find the boot ROM gets stuck
in a spin loop waiting for SATA to transition and so ultimately your boot fails as a result.
So, there are really two pieces to this puzzle if using SATA:
A. Make sure you do NOT try to enable PSC1 Module 8 through AISgen
B. If you need SATA, make sure you enable this through your application code and be sure
to set the FORCE bit in MDCTL when doing so.

FINAL CHECK - SUMMARY

So, your final main dialogue should look like this with all of these tabs showing. Please
double-check you didn’t forget something:

Save your .cfg file in the \Lab13b_AIS folder for potential use later on – you don’t want
to have to re-create all of these steps again if you can avoid it. If you look in that folder, it
already contains this .cfg file done for you. Ok, so we could have told you that earlier, but
then the learning would have been crippled.
The author named the solution’s config file:
OMAP-L138-ARM-DSP-LAB13B_TTO.cfg

Hint: C6748 Users: You will only specify ONE output file (DSP.out)
Hint: OMAP-L138 Users: You will specify TWO files (an ARM.out and a DSP.out).

GrabBag - 13b - 26 C6000 Embedded Design Workshop Using BIOS - Booting From Flash
 Lab 13b: Booting From Flash

ARM/DSP Application & Output Files

Ok, we’re almost done with the AISgen settings.

Hint: 6748 SOM Users – follow THESE directions (OMAP Users can skip this part)

For the “DSP Application File”, browse to the .OUT file that was created when you built your
keystone project: keystone_flash.out

Hint: OMAP-L138 SOM Users – follow THESE directions:

For OMAP-L138 users: you will enter the paths to both files and AISgen will combine them
intoONE image (.bin) to burn into the flash. You must FIRST specify the ARM.out file
followed by the DSP.out file – this order MATTERS.
Follow these steps in order carefully.

Click the “…” button shown above next to “ARM Application File” to browse to (use \Lab13b
instead):

Click Open.

Your screen should now look like this (except for using \Lab13b…):

This ARM code is for rev1 silicon. It should also work on Rev2 silicon – but not tested.

C6000 Embedded Design Workshop Using BIOS - Booting From Flash GrabBag - 13b - 27
Lab 13b: Booting From Flash

Next, click on the “+” sign (yours will say \Lab13b):

and browse to your keystone_flash.out file you built earlier. You should now have two
.out files listed under “ARM Application File” – first the ARM.out, then the DSP.out files
separated by a semicolon. Double-check this is the case.
The AISgen software won’t allow you to see both paths at once in that tiny box, but here is a
picture of the “middle” of the path showing the “semicolon” in the middle of the two .out files –
again, the ARM.out file needs to be first followed by the DSP.out file (use \Lab13b instead):

Hint: ALL SOM Users – Follow THIS STEP…

For the Output file, name it “flash.bin” and use the following path:
C:\SYSBIOSv4\Labs\Lab13b_AIS\flash.bin

Hint: Again, the path and filename CANNOT contain any spaces. When you run the flash
writer later on, that program will barf on the file if there are any spaces in the path or
filename.

Before you click the “Generate AIS” button, notice the other configuration options you have here.
If you wanted AIS to write the code to configure any of these options, simply check them and fill
out the info on the proper tab. This is a WAY cool interface. And, the bootloader does “system”
setup for you instead of writing code to do it – and making mistakes and debugging those
mistakes…and getting frustrated…like getting tired of reading this rambling text from the
author….

GrabBag - 13b - 28 C6000 Embedded Design Workshop Using BIOS - Booting From Flash
 Lab 13b: Booting From Flash

15. Generate AIS script (flash.bin).

Click the “Generate AIS” button. When complete, it will provide a little feedback as to how
many bytes were written. Like this:

So, what did you just do?

For OMAP-L138 (ARM+DSP) users, you just combined the ARM.out and DSP.out files into
one flash image – flash.bin. For C6748 Users, you simply converted your .out file to a flash
image.
The next step is to burn the flash with this image and then let the bootloader do its thing…

Program the Flash: [.BIN → SPI1 Flash]

16. Check target config and pin settings.
Use the standard XDS510 Target Config file that uses one GEL file (like all the other labs in
this workshop). Make sure it is the default.
Also, make sure pins 5 and 8 on the EVM (S7 – switch 7) are ON/UP – so that we are in
EMU mode – NOT flash boot mode.
17. Load SPIWriter.out into CCS.
The SPIWriter.out file should already be copied into a convenient place:
C:\SYSBIOSv4\Labs\Lab13b_SPIWriter

In CCS,
Launch a debug session (right-click on the target config file and click “launch”)
Connect to target
Select “Load program” and browse to this location:
C:\SYSBIOSv4\Labs\Lab13b_SPIWriter\SPIWriter_OMAP-L138.out

C6000 Embedded Design Workshop Using BIOS - Booting From Flash GrabBag - 13b - 29
Lab 13b: Booting From Flash

18. PLAY !
Click Play. The console window will pop up and ask you a question about whether this is a
UBL image. The answer is NO. Only if you were using a TI UBL which would then boot
Uboot, the answer is no. This assumes that Linux is running. Our ARM code has no O/S.
Type a smallcase “n” and hit [ENTER]. To respond to the next question, provide the path
name for your .BIN file (flash.bin) created in a previous step, i.e.:
C:\SYSBIOSv4\Labs\Lab13b_AIS\flash.bin

Hint: Do NOT have any spaces in this path name for SPIWriter – it NO WORK that way.

Here’s a screen capture from the author (although, you are using the \Lab13b_ais dir, not
\Lab12b) :

Let it run – shouldn’t take too long. 15-20 seconds (with an XDS510 emulator). You will see
some progress msgs and then see “success” – like this:

19. Terminate the Debug session, close CCS.

20. Ensure DIP switches are set correctly and get music playing, then power-cycle!
Make sure ALL DIP switches on S7 are DOWN [OFF]. This will place the EVM into the
SPI-1 boot mode. Get some music playing. Power cycle the board and THERE IT GOES…
No need to re-flash anything like a POST – just leave your neat little program in there for
some unsuspecting person to stumble on one day when they forget to set the DIP switches
back to EMU mode and they automagically hear audio coming out of the speakers when the
turn on the power. Freaky. You should see the LED blinking as well…great work !!

Hint: DO NOT SKIP THE FOLLOWING STEP.

21. Change the boot mode pins on the EVM back to their original state.
Please ensure DIP_5 and DIP_8 of S7 (the one on the right) are UP [ON].

RAISE YOUR HAND and get the instructor’s attention when

you have completed this lab. If time permits, move on to the
next OPTIONAL part…

GrabBag - 13b - 30 C6000 Embedded Design Workshop Using BIOS - Booting From Flash
 Lab 13b: Booting From Flash

Optional – DDR Usage

Go back to your keystone project and link the data buffers into DDR memory (just like we did in
the cache lab) via the platform file. Re-compile and generate a new .out file. Then, use AISgen to
create a new flash.bin file and flash it with SPIWriter. Then reset the board and see if it worked.
Did it?
FYI – to make things go quicker, we have a .cfg file pre-loaded for AISgen. It is located at (use
\Lab13b_AIS):

When running AISgen, you can simply load this config file and it contains ALL of the settings
from this lab. Edit, recompile, load this cfg, generate .bin, burn, reset. Quick.
Or, you can simply use the .cfg file you saved earlier in this lab…

C6000 Embedded Design Workshop Using BIOS - Booting From Flash GrabBag - 13b - 31
Additional Information

Additional Information

GrabBag - 13b - 32 C6000 Embedded Design Workshop Using BIOS - Booting From Flash
 Notes

Notes

C6000 Embedded Design Workshop Using BIOS - Booting From Flash GrabBag - 13b - 33
More Notes…

More Notes…

GrabBag - 13b - 34 C6000 Embedded Design Workshop Using BIOS - Booting From Flash
 Stream I/O and Drivers (PSP/IOM)
Introduction
In this chapter a technique to exchange buffers of data between input/output devices and
processing threads will be considered. The BIOS „stream‟ interface will be seen to provide a
universal intervace between I/O and processing threads, making coding easier and more easily
reused.

Objectives

Objectives

 Analyze BIOS streams – SIO – and

the key APIs used
 Adapt a TSK to use SIO (Stream I/O)
 Describe the benefits of multi-buffer
streams
 Learn the basics of PSP drivers
 Lab 13c – Troubleshooting CCS and
different emulators

C6000 Embedded Design Workshop Using BIOS - Stream I/O and Drivers (PSP/IOM) GrabBag - 13c - 1
Module Topics

Module Topics
Stream I/O and Drivers (PSP/IOM) .......................................................................................................13-1
Module Topics........................................................................................................................................13-2
Driver I/O - Intro ...................................................................................................................................13-3
Using Double Buffers .............................................................................................................................13-5
PSP/IOM Drivers ...................................................................................................................................13-7
Lab 11f: Emulator and CCS Troubleshooting .....................................................................................13-11
[OPTIONAL] Lab 13c – EMU and CCS Troubleshooting .............................................................13-12
PART A – Compare/Contrast Emulators ....................................................................................13-12
XDS100v1 Emulation .................................................................................................................13-12
XDS510 Emulation .....................................................................................................................13-14
XDS560v2 Emulation .................................................................................................................13-15
Conclusions .................................................................................................................................13-16
PART B – Troubleshooting CCS ................................................................................................13-17
General IDE Troubleshooting .....................................................................................................13-17
Debugging the Debugger… ........................................................................................................13-18
Additional Information.........................................................................................................................13-19
Notes ....................................................................................................................................................13-21
Notes ....................................................................................................................................................13-22

GrabBag - 13c - 2 C6000 Embedded Design Workshop Using BIOS - Stream I/O and Drivers (PSP/IOM)
 Driver I/O - Intro

Driver I/O - Intro

C6000 Embedded Design Workshop Using BIOS - Stream I/O and Drivers (PSP/IOM) GrabBag - 13c - 3
Driver I/O - Intro

GrabBag - 13c - 4 C6000 Embedded Design Workshop Using BIOS - Stream I/O and Drivers (PSP/IOM)
 Using Double Buffers

Using Double Buffers

Double Buffer Stream TSK Coding Example

//prolog – prime the process…
status = SIO_issue(&sioIn, pIn1, SIZE, NULL);
status = SIO_issue(&sioIn, pIn2, SIZE, NULL);

status = SIO_issue(&sioOut, pOut1, SIZE, NULL);

status = SIO_issue(&sioOut, pOut2, SIZE, NULL);
//while loop – iterate the process…
while (condition == TRUE){
size = SIO_reclaim(&sioIn, (Ptr *)&pInX, NULL);
size = SIO_reclaim(&sioOut, (Ptr *)&pOutX, NULL);
// DSP... to pOut
status = SIO_issue(&sioIn, pInX, SIZE, NULL);
status = SIO_issue(&sioOut, pOutX, SIZE, NULL);
}
//epilog – wind down the process…
status = SIO_flush(&sioIn); //stop input
status = SIO_idle(&sioOut); //idle output, then stop
size = SIO_reclaim(&sioIn, (Ptr *)&pIn1, NULL);
size = SIO_reclaim(&sioIn, (Ptr *)&pIn2, NULL);
size = SIO_reclaim(&sioOut, (Ptr *)&pOut1, NULL);
size = SIO_reclaim(&sioOut, (Ptr *)&pOut2, NULL);
10

C6000 Embedded Design Workshop Using BIOS - Stream I/O and Drivers (PSP/IOM) GrabBag - 13c - 5
Using Double Buffers

Double Buffer Stream TSK Coding Example

//prolog – prime the process…
status = SIO_issue(&sioIn, pIn1, SIZE, NULL);
status = SIO_issue(&sioIn, pIn2, SIZE, NULL);
size = SIO_reclaim(&sioIn, (Ptr *)&pInX, NULL);
// DSP... to pOut1
status = SIO_issue(&sioIn, pInX, SIZE, NULL);
size = SIO_reclaim(&sioIn, (Ptr *)&pInX, NULL);
// DSP... to pOut2
status = SIO_issue(&sioIn, pInX, SIZE, NULL);
status = SIO_issue(&sioOut, pOut1, SIZE, NULL);
status = SIO_issue(&sioOut, pOut2, SIZE, NULL);
//while loop – iterate the process…
while (condition == TRUE){
size = SIO_reclaim(&sioIn, (Ptr *)&pInX, NULL);
size = SIO_reclaim(&sioOut, (Ptr *)&pOutX, NULL);
// DSP... to pOut
status = SIO_issue(&sioIn, pInX, SIZE, NULL);
status = SIO_issue(&sioOut, pOutX, SIZE, NULL);
}
//epilog – wind down the process…
status = SIO_flush(&sioIn); //stop input
status = SIO_idle(&sioOut); //idle output, then stop
size = SIO_reclaim(&sioIn, (Ptr *)&pIn1, NULL);
size = SIO_reclaim(&sioIn, (Ptr *)&pIn2, NULL);
size = SIO_reclaim(&sioOut, (Ptr *)&pOut1, NULL);
size = SIO_reclaim(&sioOut, (Ptr *)&pOut2, NULL);
11

GrabBag - 13c - 6 C6000 Embedded Design Workshop Using BIOS - Stream I/O and Drivers (PSP/IOM)
 PSP/IOM Drivers

PSP/IOM Drivers

C6000 Embedded Design Workshop Using BIOS - Stream I/O and Drivers (PSP/IOM) GrabBag - 13c - 7
PSP/IOM Drivers

GrabBag - 13c - 8 C6000 Embedded Design Workshop Using BIOS - Stream I/O and Drivers (PSP/IOM)
 PSP/IOM Drivers

C6000 Embedded Design Workshop Using BIOS - Stream I/O and Drivers (PSP/IOM) GrabBag - 13c - 9
PSP/IOM Drivers

*** please call the blank-page staring hotline at 800-URR-SICK ***

GrabBag - 13c - 10 C6000 Embedded Design Workshop Using BIOS - Stream I/O and Drivers (PSP/IOM)
 Lab 13c: Emulator and CCS Troubleshooting

Lab 13c: Emulator and CCS Troubleshooting

This lab is not for the meek at heart. Most labs in this workshop are tested a re-tested by the
authors to ensure reasonable success. However, this lab is guaranteed to take you into the weeds
and offers up MANY ways to mess up. But the learning value is incredible. Most users have no
idea this web page on troubleshooting CCS even exists. So, you get to play with some of the
options in case you have similar problems down the road.
Some might say – hey, just FIX the problems and we wouldn‟t have to troubleshoot anything.
Nice try. Every piece of silicon and software has at least one bug in it – and we‟re engineers –
we‟re paid to work things out. So, here‟s your chance… ENJOY.

C6000 Embedded Design Workshop Using BIOS - Stream I/O and Drivers (PSP/IOM) GrabBag - 13c - 11
Lab 13c: Emulator and CCS Troubleshooting

[OPTIONAL] Lab 13c – EMU and CCS Troubleshooting

PART A – Compare/Contrast Emulators
In this part of the lab, you will compare and contrast the different emulator speeds, target config
files and ease of use of each. Please keep track of the specific items we ask you to so that we can
draw some good comparisons.
The author of this workshop has placed several target config files in the User Defined are which
should speed the process some vs. you creating each one. Here is a picture of what they
SHOULD look like:

However, you still might run into some problems along the way. Good luck…
As this is possibly the last lab in the workshop and part of the “Advanced” section, little help will
be provided and the explanations below won‟t hand-hold you through every minor detail. Hey,
you‟re at the END of this workshop, so, you need less help. Right? ;-)

XDS100v1 Emulation
1. Run Keystone project using XDS100v1 emulation.
The XDS100v1 emulator is actually built into the OMAP-L138 EVM. All you have to do is
connect a USB cable to it (pick the right USB port – nearest the serial port) and your PC. If
you want the CHEAPEST solution out there for getting started with CCS, then the simulator
is your best option – it is completely free. However, if you want to emulate real hardware,
after you purchase the development kit, you have a cost-free option with the XDS100v1 and
CCSv4.
But, it is also the slowest option. Well, you get what you pay for.
In CCS, import the keystone project and build it. Make sure you are using the RELEASE
build configuration.
View the target config files and pick the one you think will work. ALWAYS check to make
sure the GEL files are correct inside each configuration. Select this .ccxml file as [Default].

GrabBag - 13c - 12 C6000 Embedded Design Workshop Using BIOS - Stream I/O and Drivers (PSP/IOM)
 Lab 13c: Emulator and CCS Troubleshooting

2. BEFORE YOU DEBUG – WHAT TO BENCHMARK.

We want to capture some speed benchmarks along the way. We want to capture two
benchmarks – “launch” (including the GEL file load/run) and “reload” of the .out file. Assign
someone who is trustworthy (not you) to do the timekeeping.
3. Debug and Play.
Hit the debug “bug”. How long did it take?
XDS100v1 “Launch”: __________ seconds
If it loads successfully, run it and verify operation. If you have problems, well, this is the
“advanced” section, so GO FIGURE IT OUT ! Actually, don‟t spin your wheels too long
(maybe 3-4 minutes TOPS) before you ask the instructor to help (if they can).
4. Get ready to TIME again.
This time, you want to time how long it takes to “RELOAD” your program. With a debug
session already open, we will skip the “launch debugger” and “target connect” times. So,
effectively, we‟re timing the build + reload of the program.
5. Rebuild the code when debug session is active.
While you are still have a debug session active, hit the “Rebuild All” button. This will rebuild
the code and reload it. How long did that take?
XDS100v1 “Reload”: ____________ seconds
Imagine that you were working on a project and performed this operation 100 times in a day
– rebuild/reload. How would you rank your experience so far? Rate the speed only:

XDS100v1 SPEED Rating (circle one): A B C D F worthless priceless

Actual price of this emulator (at Slickdeals.net), today only: $$ FREE $$

Now rate your overall experience knowing you get this emulation for FREE:

XDS100v1 OVERALL Rating (circle one): A B C D F tell_a_friend

C6000 Embedded Design Workshop Using BIOS - Stream I/O and Drivers (PSP/IOM) GrabBag - 13c - 13
Lab 13c: Emulator and CCS Troubleshooting

XDS510 Emulation
6. Run keystone project using the XDS510.
Ok, so you‟ve “been here, done that” already, but it is good practice to switch emulators on
the fly and see if you run into any problems. Do the same process as before, but switch to the
XDS510 emulator (hardware and target config file). Don‟t forget to TIME the “launch” and
“rebuild”…

XDS510 “Launch”: ____________ seconds

XDS510 “Reload”: ____________ seconds

XDS510 SPEED Rating (circle one): A B C D F don’t_care I’m_hungry

The price of this emulator is $989 on Digikey.com (actually, that‟s the truth as of the time of
this writing). So, now rate your overall experience (price/performance, ease of use) for this
emulator:

XDS510 OVERALL Rating (circle one): A B C D F I_want_two_of_them

GrabBag - 13c - 14 C6000 Embedded Design Workshop Using BIOS - Stream I/O and Drivers (PSP/IOM)
 Lab 13c: Emulator and CCS Troubleshooting

XDS560v2 Emulation
Now, this guy is supposed to be “screaming fast”. Others who have purchased this guy have
been SO thoroughly impressed, they talked to ME about it. No one talks to me – so, it must
have been out of this world.
But it takes a little work to get it there. Let‟s see what you find out…
7. Hook up the Spectrum Digital XDS560v2 emulator.
Ok, so this pod has a few more wires and adaptors to hook up. And, it‟s a little bigger in size.
Make sure you have the power supply and connectors properly attached and you see LED
lights on. The connector should have a 14-pin JTAG header on the end of it. If not, ask the
instructor for help. Connect the cable to the board. Be careful, it “stacks” up kind of high –
sometimes it is easy to topple the tower.
The XDS560v2 ships with 4-5 different connector types – including the 14-pin JTAG header.
Good for flexibility – bad if you lose the one you needed. ;-)
8. Run the keystone project using this emulator.
9. Write down the pertinent stats:

XDS560v2 “Launch”: ____________ seconds

XDS560v2 “Reload”: ____________ seconds

XDS560v2 SPEED Rating (circle one): A B C D F anything_good_on_tv?

The price of this emulator is $1495 on the Spectrum Digital website. So, now rate your
overall experience (price/performance, ease of use) for this emulator:

XDS560v2 OVERALL Rating (circle one): A B C D F I’m_still_hungry

10. Conclusions

So, did the XDS560 live up to your expectations? Why/why not?

__________________________________________________________

C6000 Embedded Design Workshop Using BIOS - Stream I/O and Drivers (PSP/IOM) GrabBag - 13c - 15
Lab 13c: Emulator and CCS Troubleshooting

11. Let’s “kick it up” another notch.

We stated earlier that getting the speed up high might take a bit more work. Do you know
what speed TCK is running at? Oh, do you even know what TCK is? Do you know where the
settings are for the emulator speeds? Huh. Maybe we should investigate.

On the right, you‟ll see a list of properties:

The current speed is set at 35MHz. Sounds fast – sounds appealing - and it works pretty well.
Depending on the board (OMAP3530, OMAP-L138, etc), you may find that setting
“Adaptive without any limit at all” could significantly improve your performance. The word
on the street is that the BlackHawk XDS560v2 is screaming fast with this setting. I guess it
doesn‟t affect the SD one as much. So, your mileage may vary. But, at least you know where
the settings are.
Try the “Adaptive without any limit at all” setting and see if that works better. Also, keep in
mind that this emulator‟s system trace mode is known to be excellent (something we‟re not
investigating at all here). Did the speed improve? Did it get worse? What was your
experience? _______________________________________________________________

Conclusions
12. So, what are your final thoughts about your experiences with these different emulators?
___________________________________________________________________________
Which one is the best choice? _________________________________________________

GrabBag - 13c - 16 C6000 Embedded Design Workshop Using BIOS - Stream I/O and Drivers (PSP/IOM)
 Lab 13c: Emulator and CCS Troubleshooting

PART B – Troubleshooting CCS

This lab is based upon the “Troubleshooting CCS” wiki page:

13. Locate the wiki page.

You can find this wiki page located at:

Use a browser to find this web page or go to:

processors.wiki.ti.com
and type in “Troubleshooting CCS” into the search area.

General IDE Troubleshooting

There are two very useful sections on this wiki page and also a link to troubleshooting JTAG
problems. Hopefully, you NEVER have to utilize these great hints, but we all know an onery
dude named Murphy who gets in the way.
If you have the web page open, read the three steps in “General IDE” and try each step below
after you read them. You may not be experiencing the problems that these hints can solve right
now, but they may come in VERY handy later on. At least you‟ll be aware of each one..
14. Reset the perspective.
When there are simple “strange” things going on in the GUI, sometimes resetting the
perspective helps. This applies to both the Edit and Debug perspectives. Try:
Window  Reset Perspective
15. Use –clean option when launching CCS.
Sometimes, the IDE‟s cache can become corrupted. Using –clean will clean up the cache
each time CCS is launched. It can add a little time, but it might just be worth it.
Find the shortcut on the desktop for CCS, go to the properties page and add –clean to the
command line. Oh golly, it‟s already there. I wonder why. Maybe the author snuck that one in
for a reason. Well, at least you know about this one.
16. Clean the workspace.

C6000 Embedded Design Workshop Using BIOS - Stream I/O and Drivers (PSP/IOM) GrabBag - 13c - 17
Lab 13c: Emulator and CCS Troubleshooting

Sometimes, a fresh start helps. It works for humans and it works for CCS. ;-) CCS stores
metadata for the environment in the \metadata folder in the workspace. Sometimes, it gets
corrupted and needs to be reset.
There are several different ways to do this:
File  Switch Workspace
Delete the metadata folder from your current workspace
Try them both.

Debugging the Debugger…

In this section, you‟ll learn some very helpful tips when your stumble on “connection”
problems in CCS. Whenever you try to launch a debug session, connect to the target or load a
problem (i.e. HIT the bug button), you may run into various errors. Sometimes, it is not your
fault. Sometimes, a corrupt file is the cause – maybe Windows is having a bad hair day – or
goodness, CCS is out to lunch and communication with the processor just isn‟t working so
well.
Shown here are a few steps that have literally saved HOURS (more like DAYS) of frustration
for this author. So, pay attention and try each step. This stuff is worth its weight in gold.
17. JTAG Connectivity Problems.
As you can see, there is a link there for debugging JTAG problems. Go ahead and peruse that
wiki page and then continue on to the next step.
18. Clearing out the “launch” cache.
Have you seen this week where you set a target config file as [Default], but when you hit the
“bug” button, it uses a different “connection” ? Well, that‟s the cached launched settings
getting in your way. It can be highly frustrating. Don‟t get me started.
There are actually two ways to do this. You can delete the .launches folder from your project
(the author has had success with that one) or you can follow the step on the wiki page – going
to Target Debug and Project Debug Session – then deleting the name of your launch
configuration.
Try them both. These are VERY handy when the emulation connection gets weird.
19. Delete the .TI cache.
This is the “mother of all” cache deletes. When the tips above don‟t work, deleting the .TI
folder works wonders. It is located at:
C:\Documents and Settings\Usr\Local Settings\App Data\.TI
With CCS closed, locate this folder and kill it. Then re-launch CCS. When done, close CCS
and power-cycle the EVM.

You’re finished with this lab. If time permits, you may move on to additional
“optional” steps on the following pages if they exist.

GrabBag - 13c - 18 C6000 Embedded Design Workshop Using BIOS - Stream I/O and Drivers (PSP/IOM)
 Additional Information

Additional Information

C6000 Embedded Design Workshop Using BIOS - Stream I/O and Drivers (PSP/IOM) GrabBag - 13c - 19
Additional Information

GrabBag - 13c - 20 C6000 Embedded Design Workshop Using BIOS - Stream I/O and Drivers (PSP/IOM)
 Notes

Notes

C6000 Embedded Design Workshop Using BIOS - Stream I/O and Drivers (PSP/IOM) GrabBag - 13c - 21
Notes

Notes

*** the very very end ***

GrabBag - 13c - 22 C6000 Embedded Design Workshop Using BIOS - Stream I/O and Drivers (PSP/IOM)
 C66x Introduction
Introduction
This chapter provides a high-level overview of the architecture of the C66x devices along with a
brief overview of the MCSDK (Multicore Software Development Kit).

Objectives

Objectives

 Describe the basic architecture of the

C66x family of devices
 Provide an overview of each device
subsystem
 Describe the basic features of the
Multicore Software Development Kit
(MCSDK)

C6000 Embedded Design Workshop Using BIOS - C66x Introduction GrabBag - 13d - 1
Module Topics

Module Topics
C66x Introduction ....................................................................................................................................13-1
Module Topics........................................................................................................................................13-2
C66x Family Overview ..........................................................................................................................13-3
C6000 Roadmap ................................................................................................................................13-3
C667x Architecture Overview ...........................................................................................................13-4
C665x Low-Power Devices ..................................................................................................................13-11
MCSDK Overview ................................................................................................................................13-13
What is the MCSDK ? .....................................................................................................................13-13
Software Architecture ......................................................................................................................13-14
For More Info… ...................................................................................................................................13-16
Notes ....................................................................................................................................................13-17
Notes ....................................................................................................................................................13-18

GrabBag - 13d - 2 C6000 Embedded Design Workshop Using BIOS - C66x Introduction
 C66x Family Overview

C66x Family Overview

C6000 Roadmap

Enhanced DSP core

C66x ISA
Performance improvement

100% upward object code

compatible

4x performance improvement
for multiply operation

32 16-bit MACs

Improved support for complex

arithmetic and matrix
computation

C674x C64x+
C67x+
SPLOOP and 16-bit
C67x 2x registers
100% upward object code
compatible with C64x, C64x+,
instructions for
smaller code size
C64x
C67x and c67x+ Advanced fixed-
IEEE 754 Native Flexible level one point instructions
Instructions for memory architecture
SP & DP Enhanced
Best of fixed-point and
Four 16-bit or eight
floating-point architecture for
iDMA for rapid data 8-bit MACs
Advanced VLIW floating-point better system performance transfers between
architecture add capabilities and faster time-to-market. local memories Two-level cache

FLOATING-POINT VALUE FIXED-POINT VALUE

C6000 Embedded Design Workshop Using BIOS - C66x Introduction GrabBag - 13d - 3
C66x Family Overview

C667x Architecture Overview

CorePac
Memory Subsystem
MSM
Application-Specific
Coprocessors CorePac
64-bit
SRAM
DDR3 EMIF  1 to 8 C66x CorePac DSP Cores
MSMC
operating at up to 1.25 GHz
• Fixed/Floating-pt operations
• Code compatible with other
C66x™ C64x+ and C67x+ devices
CorePac
 L1 Memory
L1P L1D
• Partition as Cache or RAM
L2
1 to 8 Cores @ up to 1.25 GHz
• 32KB L1P/D per core
HyperLink TeraNet  Dedicated L2 Memory
Multicore Navigator • Partition as Cache or RAM
• 512 KB to 1 MB per core
 Direct connection to memory
subsystem

Common and App-specific I/O Network

Coprocessor

Memory Subsystem
Memory Subsystem Application-Specific
Coprocessors
CorePac
MSM
64-bit
DDR3 EMIF
SRAM Memory Subsystem
MSMC
 Multicore Shared Memory
(MSM SRAM)
• 2 to 4MB (Program or Data)
C66x™
CorePac • Available to all cores
L1P L1D  Multicore Shared Mem (MSMC)
L2 • Arbitrates access to shared
1 to 8 Cores @ up to 1.25 GHz memory and DDR3 EMIF
HyperLink TeraNet • Provides CorePac access to
Multicore Navigator coprocessors and I//O
• Provides address extension
to 64G (36 bits)
 DDR3 External Memory Interface
(EMIF) – 8GB
• Support for 16/32/64-bit
Network modes
Common and App-specific I/O
Coprocessor • Specified at up to 1600 MT/s

GrabBag - 13d - 4 C6000 Embedded Design Workshop Using BIOS - C66x Introduction
 C66x Family Overview

Multicore Navigator
Memory Subsystem Application-Specific
Coprocessors
CorePac
MSM
64-bit SRAM Memory Subsystem
DDR3 EMIF
MSMC Multicore Navigator
 Provides seamless inter-core
communications (msgs and
C66x™ data) between cores, IP, and
CorePac
peripherals. “Fire and forget”
L1P L1D
 Low-overhead processing and
L2
routing of packet traffic to/from
1 to 8 Cores @ up to 1.25 GHz
cores and I/O
HyperLink TeraNet
 Supports dynamic load
Multicore Navigator
Queue Packet
optimization
Manager DMA
 Consists of a Queue Manager
Subsystem (QMSS) and
multiple, dedicated Packet DMA
engines

Common and App-specific I/O Network

Coprocessor

Multicore Navigator Architecture

Queue Interrupts
Host Link RAM
(App SW)
Buffer Memory
L2 or DDR
Queue Man register I/F Descriptor RAMs
PKTDMA register I/F Accumulation Memory
Accumulator command I/F

VBUS

Hardware Block QMSS

Timer Timer
PKTDMA
PKTDMA
Rx Coh Tx Scheduling (internal)
Rx Core Tx Core
Unit Control APDSP APDSP
(Accum) (Monitor)

Config RAM
Interrupt Distributor
Rx Channel Tx Channel Tx DMA
Register I/F
Ctrl / Fifos Ctrl / Fifos Scheduler Queue Interrupts

queue pend
Rx Streaming I/F Tx Streaming I/F
Queue
Tx Scheduling I/F Config RAM
Output Input Manager
(AIF2 only) queue
(egress) (ingress) pend
Register I/F
PKTDMA Control Link RAM
(internal)

C6000 Embedded Design Workshop Using BIOS - C66x Introduction GrabBag - 13d - 5
C66x Family Overview

Network Coprocessor
Memory Subsystem Application-Specific
Coprocessors
CorePac
MSM
64-bit SRAM Memory Subsystem
DDR3 EMIF
MSMC Multicore Navigator
Network Coprocessor
 Provides H/W accelerators to
C66x™
CorePac perform L2, L3, L4 processing
and encryption (often done in
L1P L1D S/W)
L2  Packet Accelerator (PA)
1 to 8 Cores @ up to 1.25 GHz • 8K multi-in/out HW queues
HyperLink TeraNet • Single IP address option
Multicore Navigator
• UDP/TCP checksum and CRCs
• Quality of Service (QoS)
support
• Multi-cast to multiple queues
Ethernet
Switch
SA

Switch
 Security Accelerator (SA)
PA • HW encryption, decryption
and authentication
SGMII

Network
x2

Common and App-specific I/O

Coprocessor
• Supports protocols: IPsec ESP,
IPsec AH, SRTP, 3GPP

11

External Interfaces
Memory Subsystem Application-Specific
Coprocessors
CorePac
MSM
64-bit SRAM Memory Subsystem
DDR3 EMIF
MSMC Multicore Navigator
Network Coprocessor
External Interfaces
C66x™
CorePac  2x SGMII ports – support
10/100/1000 Ethernet
L1P L1D
L2  4x SRIO lanes for inter-DSP xfrs
1 to 8 Cores @ up to 1.25 GHz  SPI for boot operations
HyperLink TeraNet
 UART for development/test
Multicore Navigator
 2x PCIe at 5Gbps
 I2C for EPROM at 400 Kbps
SRIO x4
Application
Specific I/O
PCIe x2
Application
Specific I/O

 GPIO
Ethernet
UART

Switch
GPIO

SPI
I 2C

 App-specific interfaces
SGMII

Network
x2

Common and App-specific I/O

Coprocessor

12

GrabBag - 13d - 6 C6000 Embedded Design Workshop Using BIOS - C66x Introduction
 C66x Family Overview

TeraNet Switch Fabric

Memory Subsystem Application-Specific
Coprocessors
CorePac
MSM
64-bit SRAM Memory Subsystem
DDR3 EMIF
MSMC Multicore Navigator
Network Coprocessor
External Interfaces
C66x™ TeraNet Switch Fabric
CorePac
L1P L1D  Non-blocking switch fabric that
L2 enables fast and contention-free
1 to 8 Cores @ up to 1.25 GHz
data movement
HyperLink TeraNet  Can configure/manage traffic
Multicore Navigator
queues and priorities of xfrs
while minimizing core
involvement
 High-bandwidth transfers
between cores, subsystems,
peripherals and memory
Common and App-specific I/O Network
Coprocessor

13

TeraNet Data Connections

S HyperLink
256bit TeraNet

S DDR3 M
CPUCLK/2

S Shared L2 MSMC
HyperLink M
S S S S M DDR3
TPCC TC0 M
16ch QDMA TC1 M
EDMA_0
• Facilitates high-bandwidth
XMC
communication links between
DSP cores, subsystems,
SRIO
M
SS Core
L2 0-3 M
Core M peripherals, and memories.
SS Core M • Supports parallel orthogonal
M
M
Network M
Coprocessor communication links
S SRIO
TPCC TC2 M
128bit TeraNet

TPCC TC3
64ch M
TC6
TC4 M
M S TCP3e_W/R
QDMA64ch TC5TC7
M
M
CPUCLK/3

TC8 M
QDMA TC9 M
S TCP3d
EDMA_1,2 S TCP3d

TAC_FE M S TAC_BE

S RAC_FE
RAC_BE0,1
RAC_BE0,1 MM S RAC_FE

FFTC / PktDMA M
FFTC / PktDMA M
S SVCP2 (x4)
AIF / PktDMA M SVCP2
SVCP2
(x4)
VCP2(x4)
(x4)
QMSS M
PCIe M S QMSS
S PCIe
DebugSS M

C6000 Embedded Design Workshop Using BIOS - C66x Introduction GrabBag - 13d - 7
C66x Family Overview

Diagnostic Enhancements
Memory Subsystem Application-Specific
Coprocessors
CorePac
MSM
64-bit SRAM Memory Subsystem
DDR3 EMIF
MSMC Multicore Navigator
Debug & Network Coprocessor
Trace
External Interfaces
C66x™ TeraNet Switch Fabric
CorePac Diagnostic Enhancements
L1P L1D
L2  Embedded Trace Buffers (ETB)
1 to 8 Cores @ up to 1.25 GHz enhance CorePac’s diagnostic
HyperLink TeraNet capabilities
Multicore Navigator  CP Monitor provides diagnostics
on TeraNet data traffic
 Automatic statistics collection
and exporting (non-intrusive)
 Can monitor individual events
 Monitor all memory transactions
Common and App-specific I/O Network  Configure triggers to determine
Coprocessor
when data is collected

15

HyperLink Bus
Memory Subsystem Application-Specific
Coprocessors
CorePac
MSM
64-bit SRAM Memory Subsystem
DDR3 EMIF
MSMC Multicore Navigator
Network Coprocessor
External Interfaces
C66x™ TeraNet Switch Fabric
CorePac Diagnostic Enhancements
L1P L1D HyperLink Bus
L2
1 to 8 Cores @ up to 1.25 GHz
 Expands the TeraNet Bus to
external devices
HyperLink TeraNet
Multicore Navigator
 Supports 4 lanes with up to
12.5Gbaud per lane

Common and App-specific I/O Network

Coprocessor

16

GrabBag - 13d - 8 C6000 Embedded Design Workshop Using BIOS - C66x Introduction
 C66x Family Overview

Miscellaneous Elements
Memory Subsystem Application-Specific
Coprocessors
CorePac
MSM
64-bit SRAM Memory Subsystem
DDR3 EMIF
MSMC Multicore Navigator
Network Coprocessor
Boot ROM External Interfaces
HW Sem C66x™ TeraNet Switch Fabric
Power
Mgmt
CorePac Diagnostic Enhancements
PLL L1P L1D HyperLink Bus
EDMA
x3
L2 Miscellaneous
1 to 8 Cores @ up to 1.25 GHz
x3
 Boot ROM
HyperLink TeraNet
 HW Semaphore provides atomic
Multicore Navigator access to shared resources
 Power Management
 PLL1 (Corepacs), PLL2 (DDR3),
PLL3 (Packet Acceleration)
 Three EDMA Controllers
Network  Eight 64-bit Timers
Common and App-specific I/O
Coprocessor  Inter-Processor Communication
(IPC) Registers

17

App-Specific: Wireless Applications

Memory Subsystem C6670 Coprocessors CorePac
MSM
64-bit SRAM Memory Subsystem
DDR3 EMIF
MSMC RSA Multicore Navigator
VCP2 Network Coprocessor
x4
External Interfaces
C66x™ TCP3d x2 TeraNet Switch Fabric
CorePac TCP3e Diagnostic Enhancements
L1P L1D HyperLink Bus
FFTC x2
L2 Miscellaneous
BCP
1 to 8 Cores @ up to 1.25 GHz Application-Specific
HyperLink TeraNet Wireless Applications
Multicore Navigator  Wireless-specific Coprocessors
• 2x FFT Coprocessor (FFTC)
• Turbo Dec/Enc (TCP3D/3E)
AIF2 x6

• 4x Viterbi Coprocessor (VCP2)

• Bit-rate Coprocessor (BCP)
Common and App-specific I/O Network • 2x Rake Search Accel (RSA)
Coprocessor
 Wireless-specific Interfaces
• 6x Antenna Interface (AIF2)
18

C6000 Embedded Design Workshop Using BIOS - C66x Introduction GrabBag - 13d - 9
C66x Family Overview

App-Specific: General Purpose

Memory Subsystem Application-Specific
Coprocessors
CorePac
MSM
64-bit SRAM Memory Subsystem
DDR3 EMIF
MSMC Multicore Navigator
Network Coprocessor
External Interfaces
C66x™ TeraNet Switch Fabric
CorePac Diagnostic Enhancements
L1P L1D HyperLink Bus
L2 Miscellaneous
1 to 8 Cores @ up to 1.25 GHz Wireless Applications
HyperLink TeraNet General Purpose Applications
Multicore Navigator  2x Telecom Serial Port (TSIP)
 EMIF 16 (EMIF-A):
• Connects memory up to 256MB
EMIF 16

• Three modes:
TSIP x2

• Synchronized SRAM
• NAND Flash
Common and App-specific I/O Network • NOR Flash
Coprocessor

19

GrabBag - 13d - 10 C6000 Embedded Design Workshop Using BIOS - C66x Introduction
 C665x Low-Power Devices

C665x Low-Power Devices

Keystone C6655/57 – Device Features

Memory Subsystem 1MB
MSM
C6655/57 C6655/57 Low-Power Devices
32-Bit
DDR3 EMIF SRAM

MSMC  C66x CorePac

Debug & Trace • C6655 (1 core) @ 1/1.25 GHz
• C6657 (2 cores) @ 0.85, 1.0 or
Boot ROM
2nd core, C6657 only
Semaphore
1.25 GHz
Timers
C66x™
Security /
Key Manager
CorePac  Memory Subsystem
Coprocessors
Power
Management
• 1MB Local L2 per core
32KB L1 32KB L1
• MSMC , 32-bit DDR3 I/F
P-Cache D-Cache TCP3d
PLL
x2 1024KB L2 Cache

EDMA
1 or 2 Cores @ up to 1.25 GHz
VCP2 x2
 Hardware Coprocessors
HyperLink TeraNet
• TCP3d, VCP2
Multicore Navigator  Multicore Navigator
Queue Packet  Interfaces
Manager DMA
• 2x McBSP, SPI, I2C, UPP, UART
• 1x 10/100/1000 SGMII port
x2

McBSP x2

x2
x4
EMIF16

Ethernet
GPIO

• Hyperlink, 4x SRIO, 2x PCIe

UPP

UART
I2 C

MAC
SPI

SRIO
PCIe

• EMIF 16, GPIO

SGMII  Debug and Trace (ETB/STB)

22

Keystone C6654 – Power Optimized

Memory Subsystem
C6654 C6654 – Power Optimized
32-Bit
DDR3 EMIF MSMC
 C66x CorePac
Debug & Trace
• C6654 (1 core) @ 850 MHz
Boot ROM

Semaphore  Memory Subsystem

Timers
C66x™ • 1MB Local L2
Security / CorePac
• MSMC , 32-bit DDR3 I/F
Key Manager

Power
Management
32KB L1 32KB L1
PLL
P-Cache D-Cache  Multicore Navigator
x2 1024KB L2 Cache

EDMA  Interfaces
1 Core @ 850 MHz
• 2x McBSP, SPI, I2C, UPP, UART
TeraNet
Multicore Navigator
• 1x 10/100/1000 SGMII port
Queue
Manager
Packet • EMIF 16, GPIO
DMA
 Debug and Trace (ETB/STB)
x2

McBSP x2

x2
EMIF16

Ethernet
GPIO
UPP

UART
I2 C

MAC
SPI

PCIe

SGMII

23

C6000 Embedded Design Workshop Using BIOS - C66x Introduction GrabBag - 13d - 11
C665x Low-Power Devices

Keystone C665x – Comparisons

HW Feature C6654 C6655 C6657
CorePac Frequency (GHz) 0.85 1 @ 1.0, 1.25 2 @ 0.85, 1.0, 1.25

Multicore Shared Mem (MSM) No 1MB SRAM

DDR3 Maximum Data Rate 1066 1333

Serial Rapid I/O (SRIO) Lanes No 4x

HyperLink No Yes

Viterbi CoProcessor (VCP) No 2x

Turbo Decoder (TCP3d) No Yes

24

GrabBag - 13d - 12 C6000 Embedded Design Workshop Using BIOS - C66x Introduction
 MCSDK Overview

MCSDK Overview
What is the MCSDK ?

What is MCSDK?
 The Multicore Software Development Kit (MCSDK)
provides the core foundational building blocks for
customers to quickly start developing embedded
applications on TI high performance multicore DSPs.
 Uses the SYS/BIOS or Linux real-time operating system
 Accelerates customer time to market by focusing on ease
of use and performance
 Provides multicore programming methodologies

 Available for free on the TI website bundled in one

installer, all the software in the MCSDK is in source
form along with pre-built libraries

28

Software Development Ecosystem

Multicore Performance, Single-core Simplicity

Eclipse
Code Third
Composer Party
StudioTM Plug-Ins
Editor PolyCore

CodeGen ENEA
OpenMP Optima

3L
Multicore Software Development Kit
Profiler
Critical
Debugger Blue

Remote
Debug

Multicore System
Analyzer

Visualization

Host Computer Target Board

• XDS 560 V2
• XDS 560 Trace

29

C6000 Embedded Design Workshop Using BIOS - C66x Introduction GrabBag - 13d - 13
MCSDK Overview

Software Architecture

Migrating Development Platform

TI Demo Application TI Demo Customer Customer App on

on TI Evaluation Application on Application on Next Generation TI
Platform Customer Platform Customer Platform SOC Platform
Demo Application Demo Application Customer Application Customer Application

Tools EDMA, Tools EDMA, Tools EDMA, Tools EDMA,

(UIA) Etc (UIA) Etc (UIA) Etc (UIA) Etc

Network Network Network Network

Dev Kit Dev Kit Dev Kit Dev Kit

LLD IPC LLD IPC LLD IPC LLD IPC

TI Platform Customer Customer Next Gen TI
Platform Platform Platform

CSL CSL CSL CSL

No modifications required
Software may be
different, but API
May be used “as is” or customer can
implement value-add modifications remain the same
(CSL, LLD, etc.)
Needs to be modified or replaced
with customer version

32

BIOS-MCSDK Software
Demonstration Applications
Image
HUA/OOB IO Bmarks
Processing

Software Framework Components Communication Protocols

TCP/IP
Interprocessor Instrumentation
Networking
Communication (MCSA)
(NDK)

Algorithm Libraries Platform/EVM Software

Transports SYS/BIOS
DSPLIB IMGLIB MATHLIB Platform RTOS
- IPC
Library
- NDK

Low-Level Drivers (LLDs)

Resource
POST
Manager
EDMA3 PA SRIO FFTC TSIP

OSAL Bootloader
PCIe QMSS CPPI HyperLink …

Chip Support Library (CSL)

Hardware

33

GrabBag - 13d - 14 C6000 Embedded Design Workshop Using BIOS - C66x Introduction
 MCSDK Overview

Interprocessor Communication (IPC)

Device 1 Device 2
Task Device
Core to
Core 1 Core 2 Core 1 Core 2 IPC Transports to to
Core
Task Device

Process

Process

Process

Process
Process

Process

Process

Process
Shared Memory x x

2
1

1
BIOS

BIOS

BIOS

BIOS
Navigator/QMSS x x

IPC IPC IPC IPC SRIO x x x

PCIe x x x
SoC Hardware and Peripherals SoC Hardware and Peripherals
HyperLink x x x

Device 1

Core 1 Core 2 Core 3 Core N

Process

Process

Process

Process
Process

Process

Process

Process
2

2
1

1
Linux

BIOS

BIOS

BIOS
SysLink IPC IPC IPC

SoC Hardware and Peripherals

34

C6000 Embedded Design Workshop Using BIOS - C66x Introduction GrabBag - 13d - 15
For More Info…

For More Info…

Linux/BIOS MCSDK C66x Lite EVM Details

EVM Flash Contents
EEPROM NOR NAND
128 KB 16 MB 64 MB

DVD Contents POST

BIOS MCSDK
“Out of Box” Demo
Linux MCSDK
• Factory default recovery Demo
• EEPROM: POST, IBL IBL
• NOR: BIOS MCSDK Demo
• NAND: Linux MCSDK
Demo
• EEPROM/Flash writers
• CCS 5.0
• IDE
• C667x EVM GEL/XML files
• BIOS MCSDK 2.0
• Source/binary packages
• Linux MCSDK 2.0
• Source/binary packages
Online Collateral
TMS320C667x processor website
http://focus.ti.com/docs/prod/folders/print/tms320c6678.html
http://focus.ti.com/docs/prod/folders/print/tms320c6670.html

MCSDK website for updates

http://focus.ti.com/docs/toolsw/folders/print/bioslinuxmcsdk.html

CCS v5
http://processors.wiki.ti.com/index.php/Category:Code_Composer_Studio_v5

Developer’s website
Linux: http://linux-c6x.org/
BIOS: http://processors.wiki.ti.com/index.php/BIOS_MCSDK_2.0_User_Guide

For More Information

Download MCSDK software: Refer to the MCSDK User’s Guide:
http://focus.ti.com/docs/toolsw/folders/print/bioslinuxmcsdk.html http://processors.wiki.ti.com/index.php/BIOS_MCSDK_2.0_User_Guide

Download User’s
Software Guide

For questions regarding topics covered in this training, visit the following e2e support forums:
http://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639.aspx http://e2e.ti.com/support/embedded/f/355.aspx

Software
Forums

38

GrabBag - 13d - 16 C6000 Embedded Design Workshop Using BIOS - C66x Introduction
 Notes

Notes

C6000 Embedded Design Workshop Using BIOS - C66x Introduction GrabBag - 13d - 17
Notes

Notes

*** the very very end ***

GrabBag - 13d - 18 C6000 Embedded Design Workshop Using BIOS - C66x Introduction