Internet Explorer is not a supported browser for TI.com. For the best experience, please use a different browser.
Video Player is loading.
Current Time 0:00
Duration 38:27
Loaded: 0.00%
Stream Type LIVE
Remaining Time 38:27
 
1x
  • Chapters
  • descriptions off, selected
  • en (Main), selected

Hi. In this presentation, I will overview the tools and hardware required to get started developing on the UCD3138 family of power supply controllers. To program the flash based memory on the UCD3138 family, we need to install two TI proprietary tools. Both of these tools are freely available from TI.

The first tool is called Code Composer Studio. This is an Integrated Development Environment, where C-- source code-- is edited, compiled, assembled, and linked. The second tool is called a UCD device GUI. This is the tool that directly communicates with the UCD device and configures its flash based program memory. It takes the output of Code Composer Studio as an input.

The UCD's flash based program memory is configured via its PMBus interface. PMBus is short for power management bus. We will discuss this standard in more detail at a later stage. A USB to PMBus hardware adapter is required, so as the UCD device GUI can talk to the UCD device. Please note that the flash memory on the UCD 31xx series can also be programmed via a variety of other interfaces, such as SPI, I2C, UART, and JTAG. For simplicity, we will be focusing only on PMBus during these tutorials.

Now for a overview of the first tool, called Code Composer Studio. It is an Eclipse based integrated development environment. It supports all of Texas Instruments microcontroller and Embedded Processors Portfolio. It contains a C and C++ compiler, assembler, and linker, a fully integrated CodeWright editor, and an Integrated Visual Project Manager with multi-project support.

We will discuss installation of Core Composer Studio shortly and we'll show you how to get started using the tool. For more information, please navigate to www.ti.com/ccs. We strongly recommend installing CCS version 6.1 or later for the most up-to-date support and features.

The second tool we will be using is called a UCD Device GUI. It contains a subset of the functionality of the more comprehensive Fusion Digital Power Designer and is available as part of its tool set. It is mainly used to download programs to the Flash based memory on the UCD, control program execution, and access and modify memory contents using PMBus commands. An installation demo will be shown later in this presentation. For more information, navigate to the link shown.

Now for a brief overview of the Code Development Flow, from C source files to a programmed UCD device. In Code Composer Studio, the C or C++ source files are passed through a C compiler for parsing and optimization. The output of this process is a set of assembly source files.

These assembly source files are then passed through an assembler to create a set of object files. This set of object files is then passed through a linker to create an executable . out file. This output file is then passed through a tool called ARMHEX to create a .x0 file, which can be read by the UCD device GUI.

This series of steps may look complicated, but the entire process is carried out automatically when the C or C++ space project is built in Code Composer Studio. So this entire process is hidden from the user. Texas Instruments provide sample projects with the appropriate settings so as you can get started with development quickly. The output of the CCS build process, the Tektronix .x0 file, is read by the UCD device GUI when programming the UCD device via the USB to PMBus hardware adapter.

To complete these labs, some hardware is also required. An open loop test board is needed. There are three available and they differ based on the UCD device you are using and the pin count. These boards can be ordered directly from the TI website or from most distributors. Documentation and schematics are also available at TI.com.

A USB to GPIO adapter is also required to communicate with the UCD device using the GUI over to PMBus interface. Go to the link shown for ordering information. It is also worth downloading the three main programmer's manuals-- the Monitoring and Communications Programmer's Manual, the Digital Power Peripherals Programmer's Manual, and the ARM and Digital System Programmer's Manual. You may also wish to download the programmer's manuals for the derivative devices.

I will now demonstrate how to download and install Code Composer Studio. Code Composer Studio, the tool you will be using to write C source code-- that will be compiled, assembled, and eventually downloaded to your target UCD device-- is freely available from TI. To obtain the tool, navigate to www.ti.com/ccs in an internet browser. Scroll down and click on the download button to download the latest version for Windows or Linux.

If you haven't done so already, set up a myTI account. If you have myTI account, login with your login credentials. Follow the installation instructions. You will receive an email with a link to download the CCS software. Continue to follow the installation instructions.

Make sure to select UCD Digital Power Controllers when prompted to select the product family. Select the debug probes you want to install, such as Drivers for JTAG debug probes and development boards, and click Finish.

I will now demonstrate how to download and install the UCD Device GUI. In an internet browser, go to www.ti.com/tool/fusion_digital_power_designer. Select the latest version to download and follow the installation instructions. Make sure to install the UCD 3xxx UCD 9xxx device GUI when prompted to install additional tools. Click Finish.

I will no demonstrate how to get started with Code Composer Studio. Here is Code Composer Studio in the edit perspective. There are four main sections in this perspective-- the Project Explorer area-- used to manage each project that is part of the workspace-- the Source Editor-- which provides a Chrome [? accorded ?] editor space and can be configured to your liking-- the Console Window-- for raw message output from the build process-- and the Problems Window-- that offers a structured display of all errors, warnings, et cetera, from the build process.

Now for the build process. We will start by importing Lab 1 into CCS. Select Project. Import CCS Projects. Browse to the directory which contains the source code for Lab 1. Click Finish.

You should now see the Lab 1 project in the Project Explorer pane. Expand the project to see the source files. The next step is to build the project. Building the project can be done a number of ways.

Before building, let's take a look at the project configurations, which are the project settings for the build. Right-click on the project and select Properties. The source code has been created to work on any of the versions of the UCD device. To select a target UCD device to build for, click Manage Configurations. To make a particular device active, select Set Active in the status column. For example, if you want to make the UCD3138128 active, left-click and then click Set Active.

In this demo, we want to build our project to be downloaded to the UCD3138, so make the UCD3138 the active configuration. Click OK to exit the Properties window.

To build a project, right-click on the project in the Project Explorer area and select Build Project. This will build the project for UCD3138, as we have just set this to be the active configuration. Alternatively, select the down arrow next to the hammer-like icon in the toolbar to build for any of the four UCD devices.

Here is the console window that shows the raw build output. This is predominantly compiler messages related to the compilation of each file in the project. At the bottom of the console, note the linker message, as well as the ARMHEX message, indicating that the conversion of the COFF output file to Tektronix HEX output file is complete. If there are build errors or warnings, these can be navigated, too, quickly, by clicking on the up and down arrows above the console window.

Building the project in CCS is only meaningful if the output of the build process can be used on the UCD3138xxx device itself. To find the ouput file that will be loaded into the device GUI, browse to the directory containing the C source files.

When a configuration is set up for a project, CCS creates a folder with a name the same as the configuration name. For example, we built for the UCD3138 configuration. Doing this creates a folder called UCD3138 within the folder containing the C source files. Descend into this directory to see the output files.

The file used by the UCD device GUI to program the UCD device has an extension .x0. In our case, it is called Lab_1_UCD3138.x0. 3

I will now give a brief overview of the structure of a UCD project in the source code in Lab 1. This is a typical project folder structure. It is set up so as the header and linker command files for each version of the UCD can be accessed by a single project in Code Composer Studio.

The source files are in their own folder. This folder will also contain some header files for the project. We will briefly or view the main source files in a moment.

The output files generated when a project is built are placed in a folder within the folder containing the source files. There is a separate output file folder for each version of the UCD. PMBus_common contains files required for the PMBus Handler routines, which are common to all versions of the UCD.

The header and linker command files for each version of the UCD device are also placed at this level. When you select a particular configuration in CCS, the CCS build process will be configured to select the correct header and linker command files for the UCD device selected. For the most part, the contents of these header and linker command file folders should not have to be changed, so it is sufficient just to know that they exist for now. Sample header and linker command fires for each UCD device are provided by TI.

Now, for an overview of the main source files. Open the Lab 1 project in CCS. main.c contains the main program function. Generally, some initialization functions are called in main.c. For example, in this init_PMBus is called to initialize the PMBus peripherals in the UCD device and to set up variables for the PMBus handler routine. This function, clear_integrity_word, clears a program flash checksum, and it is key to whether the device boots up in ROM or flash mode. I will explain this function in more detail later, as well as the difference between ROM and flash mode.

Here is the main loop. As you can see, it is an infinite loop. In the main loop, we generally place housekeeping routines. That is, routines that are not particularly time critical or time sensitive.

For example, the PMBus Handler routines are always placed here. These routines are generally implemented as state machines using static or global variables, so as they can be interrupted by the fast and standard interrupt service routines and can continue executing seamlessly once the interrupt service routines are finished executing.

Interrupts.c contains the fast and standard interrupt service routines. The interrupt service routines are currently empty. We will be adding code to them as we progress through the labs. Global variables for the peripherals are defined in cyclone_global_variable_defs.c. For example, the ADC registers are defined here.

We will now run through some of the include files and linker command files. First, a brief look at the linker command files. We will look at the linker command files for the UCD3138. Each device in the UCD3138 family has its own set of linker command files. For now, it is sufficient to know that these files exist. You should not need to modify them.

Cyclone_headers.cmd is a linker command file which maps the peripheral structures of the UCD device into memory. For example, the LOOP_MUX, the UART peripherals, and the ADC. The overall memory map for the UCD device is defined in cyclone.cmd. For example, we define D-Flash, or Data Flash, to start at address HEX 18800 and have a length of 800 bytes in HEX.

Load_UCD3138.asm contains custom system and variable initialization for the UCD3138 device. Each device in the UCD3138 family has its own load.asm file. Load.asm also contains the interrupt and reset vectors. The appropriate load.asm file is included, depending on which you CD device you build for in Code Composer Studio.

For example, if you build the code for the UCD3138064 device, the load_UCD3138064.asm will be included in the project. This code needs to have a low overhead and so is written in assembly language. You should not need to modify this code and so there is no need to study it in more detail for now.

Now, for a brief look at the header files. We will look at the header files for the UCD3138. Each device in the UCD3138 family has its own set of header files. For now, it is sufficient to know that these files exist. You should not need to modify them.

These files in the UCD3138a64_headerfiles folder contain the header files for the UCD3138a64 device. These particular files contain the peripheral's structure files. Cyclone_device.h is a header file which just includes all of the other peripheral header files. We will demonstrate the use of these structures in more detail later.

Briefly, they allow us to set or clear a single bit in a register using a read-modify-write operation. They are relatively inefficient, in terms of time and code space, compared to just a single register write with a constant. Best practice is to use these structures for development, then switch to constants if code needs to be optimized later.

Now for a brief look at the code in lab 1. It is very simple. It just sets a string variable to "Hello World." In lab 1, we created a string variable called a_string, which is defined in variables.h. If we go back to main.c, we set the value of a_string to "Hello World." When we download this program onto the UCD program Flash with the UCD GUI, we will be able to read the contents of a_string using the UCD GUI and verify that its contents are indeed "Hello World."

I will now demonstrate how to download firmware and access memory variables on a UCD device with the UCD device GUI. Before opening the GUI, plug the USB end on the USB adapter cable into the USB port on your computer and the other GPIO end into the PMBus header on the open loop evaluation board. You should see an LED illuminated on the bottom left of the board. This indicates that the board has powered off the USB to PMBus adapter.

If the LED is not illuminated, you will need to insert a jumper on the top right of the board, near the PMBus header. See the documentation for the evaluation boards to find out which jumper needs to be inserted. They should be inserted by default when you receive the board.

There may be up to three icons placed on the desktop as part of the GUI installation. Double click the UCD3xxx and UCD9xxx device icon to launch the GUI. In the main device GUI window, you'll see three panes-- the Status pane, which shows status of the device connected to the USB to PMBus adapter, the Tools pane, which contains links to tools we will use to program and debug the device, and the Log pane, which logs the PMBus commands as they are sent to and received from the UCD device.

We will now look for devices connected to the PMBus adapter. Click Scan for Device in ROM mode. This sends a command over the PMBus interface.

If a valid device is connected to the PMBus, and the device is in ROM mode, the UCD device will respond to the PMBus command and the response will be detected and interpreted by the GUI to tell the user which type of UCD device is connected. For example, a UCD3138 or a UCD3138064. I will discuss ROM and flash mode in more detail later.

If the device has not yet been programmed, it should be in ROM mode and you will see the following messages in the status pane of the GUI. You will see the target device, the ROM information, and the package ID. In the log pane, you will see the PMBus commands and should see a command highlighted in green, indicating a UCD device has been found successfully in ROM mode.

To program firmware into the device, select Flash Tab in the Tools pane and click on the firmware download link. The firmware download window will open. To select the firmware to download to the UCD device. Click on the Select File button and browse to the directory containing the .x0 file for lab 1.

In our case, it is called Lab_1_UCD_3138.x0. Click open. It is very important, for the moment, to select the Radio button. Do not write program checksum. Stay in ROM. I will explain why this is important in more detail later, but for now, it is sufficient to know that programming the UCD device with this option selected makes ongoing debug of these labs easier. Click Download. A pop-up message will appear.

Select Don't show this message again and Yes. The download will begin. Monitor the progress bar and see the PMBus log window for more details of the download. In the Log pane, you should see a message-- Download completed without errors-- highlighted in green, indicating a successful download. You can now close the firmware download window.

We will now use the memory debugger to access and modify memory, such as RAM variables, on the UCD device we just programmed. Before invoking the memory debugger, check if "Command ROM to execute program" is grayed out. If not, click on this link.

This link sends a PMBus command to the UCD device, which is interpreted by the ROM code in the UCD device to instruct the processor to start executing the code you have just downloaded to program memory. If this is grayed out, the code we've just downloaded to program Flash is already executing, which is what we want. If it is not grayed out, click on the link to start executing the code and program Flash. Also, check the device ID link. If it is grayed out, you need to click on it.

This sends a PMBus command to the running firmware and checks for an appropriate response from the UCD device. It lets the GUI know if the firmware that was downloaded to program Flash is executing the PMBus handler routines, which we will discuss in more detail later. These routines are required for the GUI to continue communicating with the device when the code in program Flash is executing. In the tools window, select a debug tab. Click on the memory debugger link to open the memory debugger.

The first time you use this tool, you will be prompted for a password. Type f-o-r-e-s-t-l-n, all lowercase, into the pop-up window. You will not be prompted to enter this password again. Click OK.

To load the memory map for the variables used in your program, select File, Change Map, in the memory debugger. When the change map dialog box appears, select the folder containing the map and PP files for your project. This is the same folder containing the Tektronix.x0 file we navigated to when downloading the firmware. Click OK.

Loading the appropriate map files allows the memory debugger to display variables, registers, and associated fields for debug. For Lab 1, we have set a character array called a_string to "Hello World" in the C code. Select the Refresh button in the refresh column to update the variable. Click on the plus in the name column to expand the variable and you can see the elements of the variable array.

Hello World is displayed in sequential, byte by byte fashion in HEX. 48 is the HEX representation for a capital H, 65 is the HEX representation for capital E, and so on.

I will now give a brief overview of the Boot ROM program on the UCD3138 and the placement of checksums when writing to program Flash. These checksums provide a way for the Boot ROM to check the integrity of the program Flash before allowing the ARM core to execute the code in program Flash.

Here is an illustration of the 32 kilobytes of program Flash in the UCD3138. A boot program can be placed in the first two kilobytes of program flash. If the first two kilobytes of program flash is used for a boot program, the last four bytes of this two-kilobytes block are reserved for a four-byte checksum.

This checksum is calculated by adding the contents of each byte of program flash over the first two kilobytes of program flash. If a boot program is not required, the last 4 bytes of program flash are reserved for another four-byte checksum, which is calculated by adding the contents of each byte of program flash over the entire 32-kilobyte range. After a power on, or reset, the boot run routine validates these checksums at the two locations and, based on the results, will decide whether or not to stay in ROM mode or to start executing the code in program flash. This is what we call flash mode. The checksums provide a way to check the integrity of the contents of program flash before the code in program flash is executed.

From a user perspective, we either include or exclude these checksums when writing to program flash. Excluding them will force the device to stay in ROM mode after a POR. Including them will force the device to run in flash mode after a power on reset, provided the program flash has not been corrupted, of course.

I will now present a simplified program flow for the Boot ROM program on the UCD3138. Please note that the Boot ROM routines are slightly different on the other members of the UCD's 3138 family. Please refer to the different programmer's manuals for exact details, but essentially, the principles I will discuss are relevant for the entire UCD3138 family.

After a power on, or a reset, the Boot ROM program initializes some peripherals. It then calculates the checksum of the first two kilobytes of program flash, which can be used to store a boot program, and compares the freshly calculated checksum against the value stored in the last four bytes of this two-kilobyte program flash block. If the checksum values match, the boot ROM routine forces the ARM core to start executing the code in program flash, so it transitions from ROM mode to flash mode. If the checksum values don't match, the boot ROM program calculates the checksum of the entire 32 kilobytes of program flash. It then compares this freshly calculated checksum against the value stored in the last four bytes of the 32 kilobytes of program flash.

If the checksum values match, it starts executing the code in the program flash, so it transitions from ROM mode to flash mode. If the checksum values don't match, it jumps to a PMBus Handler routine. This routine constantly pulls for valid PMBus commands coming from the master, such as the UCD device GUI, over the PMBus interface. These PMBus commands can be used to read, write, and erase program and data flash.

There is also a command to execute the code in program flash. Using this command, we can execute the code in program flash when we are in ROM mode without writing to either checksum when we are programming the device. We recommend not writing either checksum and using this command during code development, as it ensures that the flash does not become locked.

Now I will illustrate how the flash can become locked, which means it can no longer be erased and reprogrammed. This is a simple illustration of the code in main. This code is to be written to program flash. Assume, at this point, that one or both of the checksums has been programmed, so that the Boot ROM routine will instruct the ARM core to execute the code in flash after a power on, or reset.

Generally, we have initialization functions at the beginning of main and then the main loop. Inside the main loop, we always call the PMBus Handler routine so that we can erase and reprogram flash over the PMBus interface. All going well, the PMBus handler routine is called every pass through the main loop. But what if there's a bug in the program that prevents the main loop from ever being reached?

This means that the PMBus handler routine will never be called, thus preventing us from accessing erasing, and reprogramming the flash. So the program flash becomes locked and the part can never be reprogrammed. Thus, we recommend placing a backdoor at the start of main to circumvent this issue. clear_integrity_word clears the program flash checksums.

You should make the call of clear_integrity_word contingent on the state of a spare input pin. Placing it right at the start of main minimizes the chances of a bug preventing clear_integrity_word being executed if it is required to be executed. So if there is a bug that prevents the PMBus handler routines in the main loop from ever being executed, you can change the state of the input pin, reset the device, and upon execution of the code in program flash, clear_integrity_word will be called, which will clear the checksums.

Then, upon reset, the Boot ROM code will not jump to program flash, as the checksum tests at startup will fail, but instead, will stay in ROM mode and execute the PMBus Handler routines there. From this point, you can erase and rewrite the program flash. The function clear_integrity_word clears the program flash checksums, so it clears the contents of 4 or 8 bytes of program flash. Erasing or writing flash requires that the device is in a privileged mode.

To place the device in a privileged mode, we use a software interrupt mechanism. A software interrupt is not an interrupt in the regular sense. A software interrupt is initiated by the sequential execution of the software and by calling a specific function.

The call to a software interrupt function looks identical to a call to any other standard function. Making a function software interrupt based forces the ARM to operate in a privileged mode. In this privileged mode, the software can enable or disable interrupts, manipulate program and data flash content, and more. None of this functionality is permitted when the ARM is in user mode. You can read more about the software interrupt mechanism in the UCD3138 Digital System Programmer's Manual.

This video is part of a series