Honours Report

All Electric City Vehicle Report

2009

THE UNIVERSITY OF ADELAIDE SCHOOL OF ELECTRICAL & ELECTRONIC ENGINEERING ADELAIDE, SOUTH AUSTRALIA  5005.

B.E. in Electrical and Electronic Engineering B.E. in Computer Systems Engineering B.E. in Information Technology and Telecommunications

ELEC ENG 4039 A/B HONOURS PROJECT

All Electric City Vehicle Project Prepared by Steven Dang 1147175

Each student at Level IV of the course in Electrical and Electronic Engineering, Computer Systems Engineering and Information Technology and Telecommunications is required to complete this course. The course involves approximately 240 hours of project work over the whole academic year. Students are assessed on their performance in the project, a written proposal, this written report, a technical paper, and two seminar presentations.

Date submitted: Oct 30th 2009 Supervisor: Assoc Prof Nesimi Ertugrul Signature of Supervisor: 1

All Electric City Vehicle Report

2009

School of Electrical and Electronic Engineering

Assessment Cover Sheet Student Name

Steven Dang

Student ID

1147175

Assessment Title

Final Project Report

Course/Program

B.E in Computer Systems Engineering

Lecturer/Tutor

Mr Charlie Green

Date Submitted

30/10/2009

OFFICE USE ONLY Date Received

KEEP A COPY Please be sure to make a copy of your work. If you have submitted assessment work electronically make sure you have a backup copy.

PLAGIARISM AND COLLUSION Plagiarism: the use of another person’s ideas, designs, words or works without appropriate acknowledgement. Collusion: assistance in the production of an assessment submission without the express requirement, or consent or knowledge of the assessor.

CONSEQUENCES OF PLAGIARISM AND COLLUSION The penalties associated with plagiarism and collusion are designed to impose sanctions on offenders that reflect the seriousness of the University’s commitment to academic integrity. Penalties may include: the requirement to revise and resubmit assessment work, a result of zero for the assessment work; failing the course, expulsion and/or a financial penalty. I declare that all material in this assessment is my own work except where there is clear acknowledgement or reference to the work of others. I have read the University Statement and Definition of Plagiarism and Related Forms of Cheating (http://www.adelaide.edu.au/policies/?230). I give permission for my assessment work to be submitted for electronic checking of plagiarism.

Signed………………………………………………. Date ……………………………………………

PLEASE SIGN HERE

2

All Electric City Vehicle Report

2009

Acknowledgements My profound thanks go to Associate Professor Nesimi Ertugrul for establishing this project, allowing me to be a part of it, and providing his own time, knowledge and assistance throughout the year. My thanks also go to Ian Linke and Brad Pullen of the workshop, who offered us great assistance on the project and provided us with their ideas and technical knowledge. In addition, I’d like to express gratitude to Jaison Jacob from Semikron Pty Ltd and Prachi from Texas Instruments who both provided assistance from their separate fields in problems encountered by the project group in the development of the electric vehicle. I’d like to thank our sponsors Redarc, who provided the financing for the purchase of 32 lithiumion batteries, with which the car would not be able to be powered and driven. Finally, thanks must go to Michael Dawes and Brett McKinnon, my two project members who worked on the electric car with me throughout the year.

3

All Electric City Vehicle Report

2009

Executive Summary The aim of this project is to produce an electric vehicle by converting an existing internal combustion engine driven vehicle to a vehicle that can be powered exclusively by electricity. The vehicle will be designed to specifications derived from regular city commuting. Electric vehicles represent the most environmentally friendly car fuel because it produces little or no carbon dioxide emissions and in almost all cases, will produce fewer emissions than that of the standard internal combustion engine car. With the increase of prices in oil, combined with a growing awareness of the disastrous effects of global warming, the electric vehicle is a welcome solution to an alternative type of transportation that is environmentally friendly. The purpose of this report is to document the work spent on this project. This report includes two main sections; the technical content and the project management content. The technical content entails research, design, implementations, experiments and results whilst the project management content covers the work breakdown, timelines, milestones, group management, risks and the budget. A brief overview is also given as an introduction into this electric car project, providing details of its background, significance and requirements. Producing an all-electric vehicle that can be driven on Australian roads holds great significance in today’s society. It will demonstrate the current technologies involved in electric vehicles and become a platform and inspiration for which everyday people who want to convert their internal combustion cars into an all-electric car can look to. The main concerns involved with the successful completion of this project will be the programming of the motor control, the charging system for the batteries, obtaining the motor angle for calculations in the motor control programming, and overall testing to ensure the car meets all Australian Design Rules and Regulations.

4

All Electric City Vehicle Report

2009

Page of Contents Acknowledgements........................................................................................................................3 Executive Summary.......................................................................................................................4 1. Introduction.............................................................................................................................8 1.1.

Aim................................................................................................................................................................8

1.2.

Background...................................................................................................................................................8

1.3.

Project Scope.................................................................................................................................................9

1.4.

Key Requirements.......................................................................................................................................10

1.5.

Hardware Requirements..............................................................................................................................10

1.5.1.

Donor Vehicle.........................................................................................................................................11

1.5.2.

Motor.......................................................................................................................................................11

1.5.3.

Lithium-Ion Phosphate Batteries............................................................................................................11

1.5.4.

Inverter....................................................................................................................................................11

1.5.5.

Sensors & Signal Conditioning...............................................................................................................11

1.5.6.

Safety Circuitry.......................................................................................................................................12

1.6.

Software Requirements...............................................................................................................................12

1.6.1.

DSP Programming..................................................................................................................................12

1.6.2.

Ni-Can Monitoring..................................................................................................................................12

2. System Overview...................................................................................................................13 2.1.

3 Phase Permanent Magnet Synchronous AC Motor..................................................................................13

2.2.

Thundersky TS-LFP90AHA Batteries........................................................................................................14

2.3.

Semikron SKAI 3001 GD12-1452W Inverter............................................................................................14

2.4.

Resolver..................................................................................................................................................15

2.5.

R/D Converter.........................................................................................................................................15

2.6.

Throttle Potentionmetre...............................................................................................................................15

3.

Motor Control..............................................................................................................................................16

3.1.

Field Orientated Control of PMSM.............................................................................................................17

3.2.

Communication between DSP and host computer......................................................................................18

3.3.

Project Build Initiation Files.......................................................................................................................21

3.4.

Motor Control Modules...............................................................................................................................23

3.4.1.

Resolver Sensor......................................................................................................................................23

3.4.2.

Current Sensors...........................................................................................................................................26

3.4.3.

Clarke Transform........................................................................................................................................27 5

All Electric City Vehicle Report

2009

3.4.4.

Park Transform............................................................................................................................................28

3.4.5.

Space Vector Modulation............................................................................................................................28

4. Analysis of Software..............................................................................................................34 4.1.

Resolver Input Testing................................................................................................................................34

4.2.

Delay Methods............................................................................................................................................35

4.3.

Running from FLASH.................................................................................................................................36

4.4.

Clock...........................................................................................................................................................36

4.5.

Resolver Output...........................................................................................................................................37

4.6.

Space Vector Testing..................................................................................................................................38

5. Running the Motor................................................................................................................40 5.1.

8 State Switching Pattern............................................................................................................................40

5.2.

Programming the Control Scheme..............................................................................................................40

5.3.

Syncronising with the Rotor Angle.............................................................................................................42

5.4.

Setup............................................................................................................................................................43

5.5.

Running the Program..................................................................................................................................43

6. Project Management.............................................................................................................45 6.1.

Division of Work.........................................................................................................................................45

6.1.1.

Project Research..........................................................................................................................................46

6.1.2.

Signal Conditioning.....................................................................................................................................46

6.1.3.

Battery Monitoring System.........................................................................................................................46

6.1.4.

Safety Circuitry...........................................................................................................................................46

6.1.5.

Motor Position Sensor Testing....................................................................................................................47

6.1.6.

DSP Programming.......................................................................................................................................47

6.1.7.

Testing and Monitoring of Motor................................................................................................................47

6.1.8.

Install Battery Box......................................................................................................................................47

6.1.9.

Integration and Testing of Battery Monitoring System..............................................................................48

6.1.10. Integration and Testing of Safety Circuitry.................................................................................................48 6.1.11. Vehicle Roadworthy Test............................................................................................................................48 6.1.12. First Test Drive............................................................................................................................................48 6.2.

Scheduling...................................................................................................................................................49

6.3.

Communication...........................................................................................................................................51

6.4.

Budget.........................................................................................................................................................52

6.5.

Risk Analysis...............................................................................................................................................53

7. Conclusion..............................................................................................................................55 8. References..............................................................................................................................56 Appendix A...................................................................................................................................57 6

All Electric City Vehicle Report

2009

Appendix B...................................................................................................................................58 Appendix C...................................................................................................................................59 Appendix C

List of Figures Figure 1: System Schematic..........................................................................................................13 Figure 2 : System Implementation of Motor Control....................................................................16 Figure 3 : Overall block diagram of FOC of the PMSM...............................................................17 Figure 4: Spectrum Digital Configuration Utility.........................................................................19 Figure 5: Setup for connection between DSP and host.................................................................20 Figure 6: Port A Data and Direction Control Register..................................................................25 Figure 7: Maximum Conversion Channels Register MAXCONV................................................27 Figure 8: Mathematical Clarke Transform....................................................................................28 Figure 9: Mathematical Park Transform........................................................................................28 Figure 10 : Schematic of 3 phase inverter.....................................................................................29 Figure 11: Switching pattern of 3 phase inverter...........................................................................30 Figure 12: Space Vector switching patterns..................................................................................30 Figure 13: Compare Control Register A........................................................................................31 Figure 14: T1 and T2 Control Register..........................................................................................32 Figure 15: Channel 1-R/D, Channel 2-SCSB................................................................................34 Figure 16: On Chip Flash Programmer.........................................................................................36 Figure 17: Channel 2-Clock...........................................................................................................37 Figure 18: Watch Window for resolver angle...............................................................................38 Figure 19: 3 ph power supply........................................................................................................39 Figure 20: Switching Pattern.........................................................................................................40 Figure 21: Transistor Bit Representations.....................................................................................41 Figure 22: Setup Diagram..............................................................................................................43 Figure 23: Gantt Chart...................................................................................................................49 Figure 24: Project Budget..............................................................................................................52 Figure 24: Project Budget

List of Tables Table 1: Interface Connector Pin Assignment AMPSeal 14 pin...................................................23 Table 2: I/O MUX Control Register A Configuration...................................................................24 Table 3: Project Risks....................................................................................................................50 Table 4: People Risks....................................................................................................................50

7

All Electric City Vehicle Report

2009

Table 4: People Risks

1.

Introduction

1.1.

Aim

The aim of this project is to produce an electric vehicle by converting an existing internal combustion engine driven vehicle to a vehicle that can be powered exclusively by electricity. The electric vehicle is intended to be road legal in order for it to be driven in the city. The existing vehicle used for this project was a red 1993 Mazda MX5, which provided a sleek, light and well balanced body for the electric vehicle.

1.2.

Background

Global warming threatens massive changes around the world in the near future, with scientists confirming that global average temperatures have increased by 1.3oF over the last century and average sea levels increased by approximately 6.7 inches worldwide. Worldwide spring events such as bird migration are occurring earlier in the year and the annual extent of the Arctic sea ice has decreased by 2.7% per decade since 1978. It has come to a scientific consensus that human activities are the source of global warming over the last half century. A primary culprit in global warming, air pollution and climate change is the emissions of carbon dioxide (CO2), with a staggering 33% of these carbon dioxide emissions coming directly from transportation in the US. An increasing recognition of the effects of global warming combined with high oil prices has seen research and development into alternative fuel-type transportation being conducted. This has become a top priority both in Australia and around the world. One solution is the electric car. An electric car is a type of alternative fuel car that utilises electric motors and motor controllers instead of an internal combustion engine. Electric cars represent an environmentally friendly and cost-effective form of transportation. Because electric 8

All Electric City Vehicle Report

2009

motors are more efficient that internal combustion engines, vehicles that use electricity almost always produce less carbon dioxide emissions than gasoline vehicles. The concept of an electric car is by no means a new one, with electricity being one of the oldest energy sources to provide a fuel source for vehicles. The first electric car was developed as early as 1884 and was the preferred choice of cars. However, the introduction of the internal combustion engine in 1920, with allowed vehicle to travel greater distances, be cheaper to purchase and more affordable to run, brought about the demise of the electric car. Technological limitations didn’t help the electric vehicle either, with a top speed of approximately 32km/ph achievable and battery technology was not advanced enough to allow for enough power to travel greater distances. Due to increasingly higher oil prices and a public awareness of global warming relating to carbon dioxide emissions, the electric car is coming back into today’s society. Benefitting the concept of an electric car is the development in the underlying technologies associated with electric vehicles. This includes improvements in lithium-ion battery technology and the introduction of the hybrid car, which combines an internal combustion engine with supplementary electric motors to run the car at idle and low speeds. Technological limitations that hindered the growth of the electric car in the past have now been overcome. With today’s technology at disposal, the electric car can be developed to match performances of an internal combustion engine whilst producing almost no carbon dioxide emissions.

1.3.

Project Scope

The scope of the project was to research, design and develop the essential parts allowing for the car to be driven and powered exclusively by electricity. The system was broken down into three main parts; motor control using the onboard DSP located inside the inverter, a resolver board to determine the angle of the motor, and applications and measurements that could be made available through the CAN bus.

9

All Electric City Vehicle Report

2009

The scope of the project also includes integration of all main and secondary sub-systems, purchasing cables to run through the car, testing, designing safety circuitry, and finding sponsorship.

1.4.

Key Requirements

This project has the following key requirements, with justifications provided for each; •

The lithium-ion batteries, in total, will be required to provide a driving distance of approximately 50km. It has been estimated that in a regular day of city commuting, a driving distance of 50km will be sufficient for travel and thus provides the justification for the requirement.

•

A viable and simple charging system. The car will need to be charged regularly and a simple charging system is deemed to be necessary. It is aimed for the batteries to be charged via a low-cost and green electrical power source, but for the time being, it is required that the batteries can be charged via a standard power point.

•

The electric car must comply with all Australian Design Rules and regulations. As the car is intended to be driven in the city, it must me registrable, road legal, and complies with the ADRs.

•

Public appeal. For the electric vehicle to become a main form of transportation, it must appeal to the public, in terms of not only ergonomics, but also in performance and safety.

•

External sponsorship. Gaining external sponsorship is one of the aims of this project. Sponsorship not only provides the project team with financial help, it also helps in advertising the project to the public.

1.1.

Hardware Requirements

The hardware in the vehicle, including the motor, inverter, cables, batteries and the vehicle itself, must meet several requirements detailed below;

10

All Electric City Vehicle Report

2009

1.1.1. Donor Vehicle The donor Mazda MX-5 must meet several government regulations in order to be registered. The vehicle must comply with size and mass restrictions described by the Department of Motor Vehicles. Safety requirements such as maintaining normal steering and braking must also be met.

1.1.2. Motor The original internal combustion engine located within the Mazda MX-5 needs to be replaced with the supplied 3-Phase Brushless Permanent Magnet Synchronous AC motor. This motor was used in the Toyota Prius, 3rd generation.

1.1.3.

Lithium-Ion Phosphate Batteries

32 Thundersky 90 Ahr LiION batteries have already been supplied. The batteries will need to be installed into the designed battery boxes for the vehicle, and required to provide enough energy between charges for the vehicle to travel at least 50km. A battery charging system and a battery monitoring system must be designed and installed to effectively charge and monitor the batteries. The batteries must be charged via a standard household 240V AC power supply.

1.1.4. Inverter The Semikron SKAI 3001GD12-1452W inverter is used to convert the direct current (from the batteries) to alternating current (supplied to the motor). It will be required to control the motor, via a built in programmable Digital Signals Processing (DSP) chip, manufactured by Texas Instruments. The requirements of this will be further discussed in the software section.

1.1.5. Sensors & Signal Conditioning In order to control the motor, the rotor position from the sensor in the motor must be conditioned and fed back into the inverter. The raw signal for the rotor position information is provided in the form of an analogue signal, and must be converted into a digital signal.

11

All Electric City Vehicle Report

2009

1.1.6. Safety Circuitry Safety circuitry for the vehicle must be designed and installed in order to ensure the user or users are properly protected from the high voltages running through the vehicle at all times. An emergency shutdown must also be installed to shutdown the vehicle immediately in the case of an emergency. This emergency shutdown button must be accessible to the driver, but must not be located in a position that enables it to be accidently pressed.

1.2.

Software Requirements

The software requirements of this project will consist of two main sections; 1.2.1. DSP Programming Ability to program the inverter has been given by Texas Instruments through the use of the TMS320LF2407A DSP programmable chip located on board the inverter. A connection is required from the DSP to the computer and achieved through a 14pin JTAG emulator which connects to the PC via a parallel port to load the programs onto the inverter. Programming of the DSP will be completed using the TI Code Composer Studio IDE, which supports both C and Assembly language programming. The main focus of the DSP programming is to control the inverter, which effectively becomes the brains of the motor. Requirements for the DSP will be design, development and testing of code programmed for motor and torque control.

1.2.2. Ni-Can Monitoring Ability to monitor inverter operations has also been given, this time by National Instruments. Monitoring of the inverter will be achieved via the Ni-CAN data logging interface software, NiCAN for Windows. A connection is required from the CAN port of the inverter to the PC through USB.

12

All Electric City Vehicle Report

2.

2009

System Overview

The system design was broken down into subparts as shown in the figure below;

Figure 1: System Schematic

2.1.

3 Phase Permanent Magnet Synchronous AC Motor

The synchronous AC motor was used as it provided more efficiency compared to the DC motor. It was originally used in the 3rd generation Toyota Prius and generates a maximum of 50 kW @ 1200 rpm and 400 Nm @ 0 rpm of torque. The main drawback of this type of motor was that it required rotor position feedback and is thus harder to control. The synchronous motor has two primary parts; the stator (stationary) and the rotor (rotating). In order for the motor to rotate, two fluxes are needed from the stator and rotor respectively. The use of surface mounted permanent magnets is used to generate the fluxes. The motor will be driven by a sin-wave voltage coupled with the given rotator position. The generated stator flux combined with the rotor flux defines the torque and speed.

13

All Electric City Vehicle Report

2009

The motor has been modified for it to be attached to the existing drive train of the Mazda MX5 body and it estimated to be three times more efficient than a standard internal combustion engine.

2.2.

Thundersky TS-LFP90AHA Batteries

The Thundersky TS-LFP90AHA batteries provide a nominal capacity of 90 Ah and have an operating voltage between 2.5 – 4.25V. Each battery weighs approximately 3.2kg and has dimensions 145 x 220 x 61 mm. The batteries will need to be operated in an operating temperature between -25°C and 75°C. The Thundersky batteries are lithium-iron phosphate (LiFeYPO4) rechargeable batteries, where the lithium ion moves from the negative electrode to the positive electrode during discharge and from the positive electrode to the negative electrode during charge. The lithium-ion phosphate batteries are a relatively new technology. The advantages of lithium-iron phosphate batteries is that it’ll induce a slow loss of charge when not in use, has no memory effects, and has one of the best energy-to-weight ratios. However, the batteries can be easily damaged due to overcharging or discharging.

2.3.

Semikron SKAI 3001 GD12-1452W Inverter

The Semikron Inverter is required to convert the DC voltage from the batteries to 3 phase AC to power the permanent magnet synchronous AC motor. This particular inverter has been developed for electric vehicle applications and incorporates a heat sink, integrated current sensors, integrated temperature sensors, gate drivers and a controller board. There are six Insulated Gate Bipolar Transistors (IGBT) located within the inverter that are used to control the motor. This is further discussed in section 3 of this report. The controller board located within the Semikron Inverter provides the interface circuitry for the gate drives, voltage, current and temperature measurements. It also includes a Digital Signals Processing (DSP) chip that is programmable and used to control the motor. 14

All Electric City Vehicle Report

2.4.

2009

Resolver

The Tamagawa Singslyn Variable Reluctance Resolver is a position sensor that measures the instantaneous angular position of the rotating shaft. It is attached to the synchronous AC motor and operates by resolving the mechanical angle of the rotor into its Cartesian (X-Y) components. The relationship between the rotor angle and the X-Y components is a right angle triangle. Each angle has a unique combination of sine and cosine values, which mean the resolver can provide the rotor position angle in one revolution (360 degrees) of the motor.

2.5.

R/D Converter

The resolver outputs an analogue signal that must first be converted into a serial digital signal before it can be fed into the inverter. This is achieved through the use of the Resolver to Digital PCB circuit. To convert the analogue signal, the R/D converter does two things; demodulates the signal and then determines the angle to provide a digital representation of the rotor angle through trigonometric identities. The R/D converter outputs the required digital angle to be used by the inverter.

2.6.

Throttle Potentionmetre

The throttle potentionmetre is similar to the Curtis PB-6 Pot Box that has been modified to provide a 0 – 3V analog signal to the Semikron Inverter. It is powered by a 5V power supply and uses the existing accelerator pedal and accelerator cable.

15

All Electric City Vehicle Report

3.

2009

Motor Control

Motor control is required to convert the DC source to AC power to drive the motor. There are two inputs into the inverter that come in the form of motor control sensors; the resolver and the throttle potentionmetre. Control of the motor is provided by the Semikron inverter, which contains the on-board programmable Texas Instruments DSP TMS320LF2407Achip. Motor control is based on the sensored Field Orientated Control (FOC) of the permanent magnet synchronous AC motor using a resolver sensor. The overall system for control implementation of the 3 phase permanent magnet synchronous motor is shown in figure 2 below.

Figure 2 : System Implementation of Motor Control

16

All Electric City Vehicle Report

2009

The 3 phase permanent magnet synchronous motor is powered by the SKAI inverter. The TMS320LF2407A DSP chip will be programmed to generate six pulse width modulations (PWM) by means of space vector modulation techniques for six power switching devices in the inverter. There are three inputs; the throttle potentionmetre, the three currents measured from the inverter (after several calculations) and a digital signal coming from the resolver.

3.1.

Field Orientated Control of PMSM

Using a field orientated control technique theoretically allows for the motor torque to be controlled. The overall block diagram of field orientated control of the permanent magnet synchronous motor using a resolver sensor is shown in figure 3 below.

Figure 3 : Overall block diagram of FOC of the PMSM

17

All Electric City Vehicle Report

2009

Field orientated control consists of controlling the stator currents that will be represented by a vector. The control is based on projections that transform the three phase time and speed dependant system into a two co-ordinate time invariant system. The approach to implement field orientated control was to split up the overall system design into separate, smaller modules that were to be programmed and tested individually. Once all modules were completed, integration of all separate modules would be possible along with further testing of the whole system.

3.2.

Communication between DSP and host computer

Communication between the target TMS320LF2407A DSP and the host computer are provided by a Spectrum Digital XDS510 PP PLUS JTAG Emulator. The Spectrum Digital XDS510PP PLUS JTAG Emulator requires an external 5V power supply and connects to the computer through a parallel cable. It is compatible with the TMS320LF2407A DSP and is essentially the umbilical cord between PC software tools and the target DSP. Initially, there were quite a few problems in establishing communication between the target DSP and the host computer. From consulting with both Spectrum Digital (Manufacturers of the XDS510 PP JTAG Emulator) and Semikron, the following steps are required to be followed in order to establish a connection;  Turn off power to both the host computer and the target DSP  Ensure that the drivers for the JTAG Emulator have been installed on the host computer  Connect the JTAG Emulator to the host computer via the parallel cable  Plug in the 5V power supply into the JTAG Emulator 

Plug in the 12V power supply into the 14pin connector located on the Semikron Inverter

 Connect the JTAG Emulator to the DSP via the 2x7 JTAG connection  Apply power to the JTAG Emulator, DSP and host computer

18

All Electric City Vehicle Report

2009

Once these steps have been followed correctly, a Spectrum Digital Config utility is available (this utility program will be installed with the JTAG Emulator drivers) that communicates directly with the JTAG Emulator to test both the emulator and the software communication layers that communicate with the emulator. The utility allows the determination of whether there exists a problem and if it’s the emulator side or the software side. After opening the SDConfig utility (default location will be where the drivers are installed), highlight address 378 (default I/O address for XDS510PP PLUS JTAG Emulator), and from the toolbar, select Configuration, Ports Available, Printer and the available ports will be shown in the console window. From the toolbar again, select Emulator, Test. This checks the connection all the way to the target DSP and the emulator target scan chain length will be shown in the console window if the connection is successful. This is shown in figure 4 below.

19

All Electric City Vehicle Report

2009

Figure 4: Spectrum Digital Configuration Utility

Figure 5 below is a diagram to setup a connection between the target DSP and the host computer.

20

All Electric City Vehicle Report

2009

Figure 5: Setup for connection between DSP and host

The 2x7 JTAG connectors from the Semikron Inverter and the JTAG Emulator were originally both female connectors. After consulting with the workshop, a bridge connector was acquired that converted one of the female connectors into a male connector. This allowed the JTAG connections to be established. It is important that all power is turned off initially before any components are connected. It is very common for the connection to not be established if this is not the case. It is also important that the target DSP receives the 12V power otherwise the connection cannot be setup. The Spectrum Digital JTAG Emulator provided the vital link between the DSP and the host computer. It provided the team with a development and debugging tool that could be used to access the state of the DSP’s memory in real time and allowed for uploading of developed code to control the motor.

1.1.1.

Code Composer Studio v3.3 21

All Electric City Vehicle Report

2009

Code Composer Studio is an integrated development environment for TI’s DSPs and microcontrollers. It includes compilers, source code editor, project build environment, real-time mode, and debugger. Also included in the development environment are output windows that allow for monitoring of the DSP memory and registers. The output window was a major feature in Code Composer that realistically allowed the group to monitor the DSP memory, system registers and user defined variables. It was decided that programming of the DSP would be done in the C programming language (Code Composer offers C and Assembly language). C provided us with a higher level language that allowed for a larger command set, more functions to use, and easier to develop code than assembly language. Code Composer Studio needs to be setup when run the first time to establish the correct target boards. From the setup menu, F2407A XDS510PP Emulator needs to be selected. This corresponds to the TMS320LF2407A DSP connected to a XDS510PP Emulator connection that we have. Note that the emulator should be configured for I/O port 0x378. Once Code Composer has been setup correctly, the main screen will be accessible. From the top toolbar, select Debug, Connect. This will connect Code Composer with the DSP and allows for loading/testing of developed code. There is an external LED on the JTAG Emulator that will turn on once Code Composer has connected. Note that before this step is taken, SDConfig should be used to test the connection.

1.2.

Project Build Initiation Files

Initial files are required inside the project build folder other than the main source file in order for the project to be built correctly and be loadable onto the target DSP. These files are a 2407A general extension language file, a linker command file, a header file, a vector asm file and the source file. The general extension language is an interpretive language that is similar to the C programming language and allows for the creation of functions in Cod e Composer. The 2407A GEL file is 22

All Electric City Vehicle Report

2009

unique to the TMS320LF2407A DSP and is used to initialise the DSP’s functions, memory addresses and automate project build options. This GEL file was automatically loaded the first time the DSP was connected to Code Composer and has since been copied and moved into the project build folder. The linker command file was required to be developed by the project team as it did not come with the DSP. The linker file was needed to configure the system memory by allocating memory spaces specifically for their specified features. For example, memory spaces needed to be defined for where the developed code would reside in memory, where interrupts would reside and where inputs or outputs were mapped to. The system memory was programmed into the linker command file similar to what was described from the memory map detailed in the DSP’s datasheet. This linker command file initially caused various problems as if it was not programmed correctly, the DSP would throw an error relating to the linker file and would not let anything be loaded onto its memory. With discussion with Texas Instruments as well as viewing example linker files, it was eventually noted that the origin of the memory map started at memory address 0x0020 instead of 0x0000 and a separate page needed to be defined to include all memory sections. The source file is named main.c and contains the developed code to control the motor using a Field Orientated Control technique. The vector asm file includes all imitations for the system interrupts. The 2407A header file contains all the DSP register definitions. Defined in the file are the names of each system register, which is mapped to its corresponding memory address. This allowed for calling of the system register by simply its name in the main file instead of referring to the memory address of where the system register resided inside memory. All these files are inside the project build folder and are also included in the appendix of this report.

1.3.

Motor Control Modules 23

All Electric City Vehicle Report

2009

Programming of the DSP to achieve field orientated control of the 3 phase permanent magnet synchronous AC motor was done by splitting it up into separate software modules.

1.3.1. Resolver Sensor The resolver is a sensor device that is used to find the angular position of the motor rotor. The resolver outputs two analog signals in the form of a cosine and sine wave. A resolver to digital (R/D) was designed and built in order to convert the analog signal into a digital signal that can be sent as an input into the inverter. The Semikron Inverter controller board has an AMPSeal 14pin water tight locking connector for interface connections. Table 1 below shows the pins and signals for the interface connector.

Table 1: Interface Connector Pin Assignment AMPSeal 14 pin

The output coming from the R/D circuit was connected into pin 6, which is one of three digital inputs that connect directly into the TMS320LF2407A DSP. Though the pins have been buffered especially for encoders, they can still be used as digital inputs. 24

All Electric City Vehicle Report

2009

The three encoder inputs, ENC1, ENC2, and ENC3 from the 14pin interface connector correspond to IOPA3, IOPA4, and IOPA5. The three digital inputs can be accessed through the digital I/O ports of the DSP. In order to read in the inputs, two registers are needed to be configured. Note that there are two types of registers located in the digital I/O ports module; I/O MUX Control Registers (MCRx) and Data and Direction Control Registers (PxDATADIR). The I/O MUX Control Registers are used to control the multiplexor selection that chooses between the primary function of a pin or the general purpose I/O function. For this purpose, the control register needs to select the general purpose I/O function in order for the input from the resolver to be read in by the DSP. There are three control registers located on the DSP; MCRA, MCRB and MCRC. MCRA selects the I/O ports ranging from I/O PA0 to IO PB7. Since the three encoder inputs IOPA3, IOPA4, and IOPA5 fall in this range, MCRA was configured to select the general purpose I/O functions instead of the primary function of the pin.

Table 2: I/O MUX Control Register A Configuration

Table 2 above shows the configuration of MCRA. Notice that in order to get digital inputs/outputs into the DSP, all 15bits in MCRA need to be set high.

25

All Electric City Vehicle Report

2009

The other type, Data and Direction Control Registers, are used to control the data and data direction of bidirectional I/O pins. There are six data and direction control registers; PADATADIR, PBDATADIR, PCDATADIR, PDDATADIR, PEDATADIR, and PFDATADIR. PADATADIR contained the input required to obtain the signal coming in from the R/D converter. Figure 6 below is a mapping of the 16bits associated with the data and direction control register.

Figure 6: Port A Data and Direction Control Register

Bits 15-8 set the corresponding pin to either an input or output. This means that bits 14, 13, and 12 were required to be set as low to ensure pins 6, 7, and 8 (which are bits 6, 5 and 4) would be set as digital inputs. The challenging issue was that the R/D converter would be sending signals into the DSP over a serial data transmission. Serial data transmission refers to the process of sending one bit at a time over a single data line, compared to parallel data transmission, which is the process of sending many bits over of data over many data lines at a single time. The problem was that there aren’t enough inputs in the DSP to accommodate parallel data transmission. The R/D converter would send an angle that would be represented by 16 bits. The first 12 bits would represent the number (therefore a maximum number of 212), the following bit is a parity check bit, and the three remaining bits are always low. This meant that each block of 16 bits coming in as an input would refer to one angle. The ensure that DSP would read in each block of 16 bits correctly and not mix up any bits was to use the serial clock register, SCSB, which signalled to the DSP when each block of 16 bits was completed and a new block would start. 26

All Electric City Vehicle Report

2009

The number represented by the first 12 bits then needs to be subtracted by 4095 and divided by 11.375 to obtain the rotor angle that would be in the range of 0° to 360°. This module was tested to give the correct results. Simply by moving the rotor by hand, monitoring of the register (user defined variable of ‘angle1’) showed the expected angle given by the resolver signals. The resolver module works by first obtaining each of the 12 bits representing the entire angle, which is stored as a binary number of 12 bits. This is then converted into a decimal number to perform the necessary calculations to obtain the rotor angle.

1.3.2. Current Sensors There are integrated magneto resistive current sensors inside the inverter that provide current magnitude measurements and over current indication. The current sensors are inputs that come through the Analog to Digital Converter located on the DSP and are stored inside three result registers associated with the ADC. The ADC located onboard the DSP has 16 analog inputs located at registers ADCIN0-ADCIN15, and 16 individually addressable result registers, RESULT0-RESULT15, that store the results of the analog to digital conversion. Due to the fact that the TMS320LF2407A is a fixed-point DSP, the results stored in these registers need to be scaled in order to obtain the result in useful units. In order to use the ADC, it must first be set up. There are two control registers, ADCTRL1 and ADCTRL2 need to be initialised that resets all the register bits are set to their initial states. This means bit 14 of each control register needs to be set high. There exists a maximum conversion channels register which defines the maximum number of conversions executed. The MAXCONV register has the following format;

27

All Electric City Vehicle Report

2009

Figure 7: Maximum Conversion Channels Register MAXCONV

Bits 15-8 are noted as reserved as should thus be set as low. In this project case, there will be four conversions, one coming from the throttle potentionmetre and three from the current sensors. This means the last four bits need to be set as 0100 to in order 4 conversions. Unfortunately, scaling of the current sensors did not produce the expected outputs. All results in the three result registers related to the current sensor inputs could not be scaled in such a way to achieve the actual current that was measured. The inverter was set up with an input voltage applied, a resister set up between each pair of the bottom leg transistors, and a current clamp measuring current across the output. In software, switching of the transistors was performed. In each case, an upper leg and bottom leg transistor were switched on, with all other transistors off to measure the current.

1.3.3. Clarke Transform Clarke Transformation uses the three phase currents obtained from the current sensors, ia, ib, and ic to calculate currents in the two phase orthogonal stator axis. There currents thus get transformed into currents iα and iβ. The two transformed currents represent the current components in the fixed co-ordinate stator frame. A mathematical Clarke transformation formula was programmed into the main code to transform the three phase system into a two phase orthogonal system.

28

All Electric City Vehicle Report

2009

Figure 8: Mathematical Clarke Transform

Note that io is the homopolar component of the system and is not needed in the application of motor control.

1.3.4. Park Transform A Park transform is then applied to relate the current components from the stationary stator frame (transformed currents iα and iβ) to the rotating reference frame of the rotor. The two currents iα and iβ and transformed into isd, the real current, and isq, the imaginary current. A mathematical Park transformation formula was also programmed into the main code to relate the currents from the stationary axis to a rotating reference frame of the rotor.

Figure 9: Mathematical Park Transform

Note that the angle θ in the above mathematical formula corresponds to the rotor angle obtained from the resolver module.

1.3.5. Space Vector Modulation Space Vector Pulse Width Modulation (SVPWM) refers to a special scheme of the six IGB transistors located in the three phase Semikron Inverter to generate pulse width modulations. It provides a more efficient use of supply voltage in comparison with the sinusoidal method. 29

All Electric City Vehicle Report

2009

Figure 9 displays the structure of the three phase inverter with six IGB transistors and Va, Vb, and Vc are the voltages applied to the motor windings. SVPWM states that if an upper transistor is switched on (DTPHa, DTPHb, and DTPHc), the corresponding transistor on the lower leg must be switched off (either DTPHa_, DTPHb_, and DTPHc_). For example, if DTPHa is switched on, this means DTPHa_ needs to be switched off.

Figure 10 : Schematic of 3 phase inverter

When an upper transistor is switched on, the voltage applied to by the leg to the corresponding motor winding is equal to the voltage supply. When the transistor is switched off the voltage applied to the motor winding is zero. The on and off switching of the upper transistors thus has a possible eight different combinations, which are shown in figure 10 below. Note that Udc is in terms of the motor supply voltage.

30

All Electric City Vehicle Report

2009

Figure 11: Switching pattern of 3 phase inverter

These phase voltages corresponding to the eight combinations can be mapped onto a two coordinate axis using the Clarke and Park transforms.

Figure 12: Space Vector switching patterns

From figure 11 above, after phase voltages are mapped onto the d-q plane, they form six nonzero vectors and two zero vectors. Each vector state (combination of three binary digits) represents the states of the upper transistors (ie, 001 refers to upper transistors DTPHa, DTPHb are off and upper transistor DTPHc is on). Between each adjacent vector is an angle of 60°, with a total of 360°.

31

All Electric City Vehicle Report

2009

Depending on what angle is read in by the resolver sensor, it can be mapped out to the corresponding quadrant to determine the variables T0, T1, T2, and thus find the projected motor voltage vector, Uout. T1 and T2 are the time durations for how long the specific upper transistors are on for. T0 is half the period of the total PWM carrier period. The projected motor voltage vector is given by Uout = T1 Ux + T2Ux_60 + T0. SVPWM is generated with the TMS320LF2407A using the Event Manager, which has hardware to greatly simply the generation of SVPWM waveforms. The Event Manager module provides a broad range of functions and features that are particularly useful in motion control and motor control applications. The TMS320LF2407A has two Event Manager modules, EVA and EVB. For our purposes, only EVA will be used. The first step in setting up Event Manager A to generate SVPWM is to configure the ACTRA register to define the polarity of the compare output pins. This means setting bits 14-0 initially high, with bit 15 also set high because we want to be moving in a counter clockwise direction. The ACTRA register is a compare control register for EVA. COMCONA represents the control register for EVA and controls the operation of the compare units.

Figure 13: Compare Control Register A 32

All Electric City Vehicle Report

2009

Bits 7-0 of this register are reserved and thus remain low. Bits 15 and 12 need to be set high to enable both the compare operation and SVPWM mode. Bits 11-10 and set as low-high for underflow condition, which is specified as a pre-requisite for SVPWM generation. The GP1 timer (General Purpose) also needs to be set up to allow for continuous up/down counting mode that starts the operation. The voltages Ux and Ux_60 can be thus determined using figure 10 above and knowing what quadrant the angle is situated at. The switching patterns for Ux determined by the quadrants then need to be written into the ACTRA register, in bits 14-11. For example, if the angle was in the 1st quadrant, we need the switching pattern of 001 into ACTRA bits 14-11. The parameters T1 and T2 can then be identified using the following derived formula; The final step is to then store these parameters T1 and T2 in the registers CMPR1 and CMPR2. 1/2T1 needs to be stored in CMPR1 and (½*T1 and ½*T2) needs to be stored in CMPR2. Also worth mentioning is that the register MCRA first needs to be set to 0FC0 at the start of the space vector module, which ensures that we are able to select PWM1-6, instead of the PA and PB data registers. As noted in table 2 of the MCRA register; bits 6 to 11 need to be set high in order to select the PWM1-6 functions.

Figure 14: T1 and T2 Control Register

The timer control registers T1CON and T2CON are set to allow for continuous up/down counting mode by setting them to the value 0942. In addition to this, Timer 1 period needs to be

33

All Electric City Vehicle Report

2009

set, which is the same period as that total PWM. The transistors are then switched on/off depending on the switching pattern relating to the quadrant.

34

All Electric City Vehicle Report

2.

2009

Analysis of Software

It was noted that last year’s project group also purchased the above inverter, which was decided to be tested considering the scaling with the original inverter’s current sensors. Luckily enough, this Semikron Inverter had installed inside its controller board a TI TMS320LF2406A DSP, which was almost the same as the TMS320LF2407A DSP. This essentially meant that the original program developed was able to be loaded onto this new DSP with a few minor modifications. The current sensors in this inverter were slightly better, but still did not output the desired result. Instead, it was noted that the current sensors, when scaled, gave outputs that reflect 1V to 2.5A. The problem existed that the program would not be able to differentiate between very close numbers, such as 3A and 4A would be read in as the same number in the software.

2.1.

Resolver Input Testing

The resolver board was connected up to both the rotor connections and the DSP controller board connections. It was verified that the signals produced through the R/D converter were correct and also inputting correctly into the DSP.

35

All Electric City Vehicle Report

2009

Delay required here

Figure 15: Channel 1-R/D, Channel 2-SCSB

Figure 14 shows the output signal of the R/D converter. Notice that where the blue vertical axes have been placed represent each block of 16 bits required calculating the angle of the rotor. Also note that the last 3 bits are always low. Channel 1 represents the output, and channel 2 represents the SCSB signal. In an earlier section, it was documented that in order for the software to be able to distinguish between each block of 16 bits was to use the SCSB signal. Once it turns on, and then low, it is followed by a block of 16 bits, after which it repeats the process and turns high momentarily before switching low again, allowing for the next 16 bits. The software currently uses a loop that waits for the condition in which SCSB turns high, in which it will start to read in an angle for use in the other software modules. It is also noted that between each SCSB high, there is a delay of approximately 1.35ms. The way that the program has been set up, it is required for it to read in the angle and perform all the software modules required to control the motor and finish in 1.35ms.

2.2.

Delay Methods

Delay methods were created outside the main program loop to try and control the speed at which the program was running. A simple delay method was created using a for loop that counted down until it reached zero. Starting, from say, an arbitrary number of 50 and counting down in the 36

All Electric City Vehicle Report

2009

loop, a delay of approximately 0.02ms could be achieved. This delay method was tested using the oscilloscope to measure the frequency. A simple program that turned an output signal from the controller board (5V OUTX1, pin 10 of the 14-pin interface connector) high, delay method, then switch the output signal low was used to test this delay method and to measure the delay it would produce. It would be simply a matter of changing the arbitrary number to achieve different delay results. However, it was not possible to measure the outcome once the number was changed to be less than 13. At this case, the output switching from high to low was so quick that it couldn’t be seen on the oscilloscope, and thus could not be measured. A delay was needed between the time SCSB went low and the first of the 12 bits started. This can be seen in the above figure 15 where the delay required is marked.

2.3.

Running from FLASH

It was possible to run the program through FLASH memory located in the TMS320LF2406A. This was achieved through code composer studio. On the top toolbar, select Tools and proceed to select On Chip Flash Programmer. A separate window box will appear, select the 2406A DSP, and hit execute. Make sure the CPU is reset before the program is run.

37

All Electric City Vehicle Report

2009

Figure 16: On Chip Flash Programmer

2.4.

Clock

A clock was also generated through software to use with the R/D converter. Again, by using a simple for loop to first, set the output signal high, delay for some time, set the output signal low, delay for the same period of time, a clock signal was able to be generated and applied to the R/D converter. Different delay values were experimented with until a clock frequency of approximately 2MHz could be achieved. The clock generated achieves a clock frequency of 1.4MHZ. The software module developed to generate this clock is found in the ‘delayout’ method in the program.

38

All Electric City Vehicle Report

2009

Figure 17: Channel 2-Clock

2.5.

Resolver Output

The resolver signals coming into the DSP were tested and provided the correct angle representation inside the software. The variable angle1 represents the angle, in this case, 44.21°. The array elements in the bitword array represent the 12 bits coming into the DSP. Starting at index 11 of the array, the bits are received and transferred into this array.

39

All Electric City Vehicle Report

2009

Figure 18: Watch Window for resolver angle

2.6.

Space Vector Testing

To test that Space Vector Modulation was generating the pulse width modulations, an infinite loop in the main code was created so that the code would simply continue to run. The first test involved setting up resistances between the transistors and applying 3 phase voltage to power the inverter. Theoretically, the space vector module should have been able to switch the transistors according to the stated switching pattern derived from the angle. Unfortunately, the initial test saw that either no current was drawn or a short circuit was created. The short circuit could only come from the fact that both the upper leg transistor as well as the corresponding lower leg transistor were both switched on. It took several adjustments that were noted in the earlier space vector module section to fix this. Timers had to be setup, including the periods, in order for the compare functions to work. It was also noted that the transistor switching patterns were being overwritten in our code in certain cases, which would correspond to the short circuiting. 40

All Electric City Vehicle Report

2009

After getting the combination right and setting up the event manager A correctly to produce space vector pulse width modulation, we were able to draw current from the 3 phase voltage.

Figure 19: 3 ph power supply

Figure 17 above shows the measurements of the 3 phase power supply when it was connected up to the inverter and the program was running. On the right hand side, it can be seen that the inverter is drawing current. This current would be in the range of 0 to around 8A, and would change according to when the rotor was rotated. This test confirmed that the Space Vector module was switching the transistors and able to draw current from the power supply. The next test needed was to capture the waveform of the current. However, before this could be done, the program started behaving strangely after a few minor modifications. Even though the program was changed back to what it was originally, current could not be drawn anymore from the power supply, as each time the program was run a short circuit would occur. All set up imitations of the event manager were double checked and changed if needed to ensure they were set correctly according to the manual, but this still did not solve the problem.

41

All Electric City Vehicle Report

3.

Running the Motor

3.1.

8 State Switching Pattern

2009

After considerable trouble and problems involved with controlling the motor using the Field Orientated Control approach, it was decided to attempt control of the motor using a much more basic control scheme. This control scheme was based on the operation of the three switches be co-ordinated so that one switch would operate at each period of 60 degrees. This would create an output waveform that would have six steps.

Figure 20: Switching Pattern

The above figure shoes the six step switching pattern for the voltage between terminals A and C. The switching pattern would be the same six step switching pattern as seen here but would be 120 degrees out of phase with each other.

3.2.

Programming the Control Scheme

Programming this basic motor control scheme for the three phase inverter was done in the method ‘newManual()’ located in the program source code. Essentially, this six step switching pattern was programmed in, and by doing so, it would also be setting the switching patterns for the other two terminals as well (VA-B and VB-C). Switching was done depending on what angle the rotor was in. 42

All Electric City Vehicle Report

2009

The newManual method calls six other methods, first(), second(), third(), fourth(), firth() and sixth(). These methods were programmed to set the switching of the six transistors depending on what angle quadrant the rotor was in. For example, first() corresponded to the switching states of the transistors when the rotor was in between angle 0-60, second() corresponded to the switching states of the transistors when the rotor was in between angle 60-120, and sixth() corresponded to the switching states of the transistors when the rotor was in between angle 300-360. The six methods used to switch the states of the inverter are all coded in a similar fashion. Bits 6 and 7 of the PADATDIR register represents the 1st top transistor and the 1st bottom transistor respectively. Bits 0 and 1 of the PBDATDIR register represents the middle column on transistors. Bits 2 and 3 of the PBDATDIR register represents the last column of transistors. Note that, to program the states in, you will need to but either a 0 or 1 for each of the six bits above according to what switching pattern is needed. It is important that the bits are also actually opposites when you program them in; meaning that if you wanted a transistor to switch high, this would be the same as setting that bit representing the transistor to 0, and vice versa. Figure 21 below is a diagram of the PA and PB Data Register Mappings to each of the transistors inside the inverter.

Figure 21: Transistor Bit Representations

There is a delay method, delayTRANS(), which changes the switching states. What happens is that inside these six methods, the patterns are switched on, then off, then on, then off, etc to simulate the switching speeds. To set the switching speed, simply change the value of the

43

All Electric City Vehicle Report

2009

counter inside the loop, this will result in how many times the transistors are switched up and down in this period. The newManual() method is built on using the six programmed states, with the switching pattern starting at a different position depending on the angle of the rotor. These switching patterns allow the motor to move. Note that the motor angle has been converted from mechanical angle to electrical angle by multiplying by the number of pole pairs.

3.3.

Syncronising with the Rotor Angle

This was achieved by one person rotating one of the wheels whiles the other person measured this compared with the 12th bit of the R/D Converter board whiles it was rotating as a generator. This allowed determining that they were slightly off by approximately 4.5 degrees. This difference was compensated for in the program when determining the angle of the rotor. In all the angle condition methods (first – sixth), you will notice that the actual angle sector we’re determining has been added by 4.5 degrees, but in radians. It was also seen whiles running these tests that the C and B phases are actually switched. So the terminal B at the motor would need to be connected to terminal C of the inverter, and similarly, terminal C at the motor would need to be connected to terminal B of the inverter. This completed all necessary steps to synchronise with the rotor angle and allowed for running of the motor.

3.4.

Setup

The figure below depicts a diagram of the setup required to run the motor.

44

All Electric City Vehicle Report

2009

Figure 22: Setup Diagram

3.5.

Running the Program

Before running the program, ensure that the target DSP and the host computer are connected correctly, as explained in an earlier section. All program files are located in this directory; C:\\CCSStudio_v3.3\Myprojects. There are two project folders that are to be used, f2407a or f2406a, depending on the DSP. With CCS open, right click the project folder and select open project. The project files are in the form .pjt and are located within the project folders. Once the project is opened, it must be compiled and built. This is done by accessing Project in the top toolbar, and selecting rebuild all. Once built with no errors, the program can be loaded onto the DSP by going to File, load program. It can also be loaded into the FLASH memory using the on chip flash programmer. With the program loaded, the CPU first needs to be reset, go to Debug and reset CPU, before it can be run, using Debug-run.

45

All Electric City Vehicle Report

2009

Registers can be seen in the watch window by going to the GEL menu in top toolbar and selecting the required system register. User defined variables can be also watched in the watch window by right clicking the variable (in the source editor) and selecting add to watch window. Once you have selected Debug and Run, the program should start running and you will see that wheels will start to rotate. The program can be halted using Debug and Halt. Note that when you want to restart the program again, you must reset the CPU before you select Run. A copy of all the files have been put onto a CD. The latest revision of the source code in the CD is located under the MyProjects folder, inside the 2407A folder, and named main.c.

46

All Electric City Vehicle Report

4.

2009

Project Management

Project management details the organisation aspects of this project. It documents communication procedures within the project team, division of work, milestones, scheduling, project budget, risk management and group management.

4.1.

Division of Work

To complete a project with such a large scope as the All Electric City Vehicle, the work needs to be divided amongst the group members equally and reasonable deadlines must be set. A timeline detailing the main tasks and milestones has been constructed by the group and can be seen in Figure 5 below. Due to the small amount of experience the group has had in scheduling and maintaining a timeline for such a large scale project, the timeline has been designed such that the expected completion time of the project is approximately two weeks prior to the project exhibition. This should allow enough time to deal with any unexpected problems that arise throughout the course of the year, without running past the final deadline. Most of the main tasks of the project were divided amongst the group members, while a few tasks will be needed to be completed by the workshop team. The TAFE will also be responsible for one of the project tasks, that being the painting of the vehicle. Along with all of the tasks directly related to the designing and customising of the vehicle for the purpose of our project, group members also need to work on writing reports such as the critical design review and individual final reports, as well as creating presentations for seminars. The main tasks can be split into three categories: • Research and design tasks • Implementation and testing • Other non-technical tasks

47

All Electric City Vehicle Report

2009

In the following sections the individual tasks are described that were originally thought up by the project team at the research stage of the project. 4.1.1. Project Research Date Started/Completed: 02/03/09 – 22/03/09 To Be Completed By: All group members Dependencies: None Task Description: Research the background of the project to give the group an opportunity to properly understand the overall goals and requirements of the project. Research previous year’s progress and background information regarding components to be used during the project.

4.1.2. Signal Conditioning Date Started/Completed: 27/04/09 – 17/05/09 To Be Completed By: Michael Dependencies: None Task Description: Design a way to condition signals coming from the motor in such a way that they will be useful to the DSP and CAN.

4.1.3. Battery Monitoring System Date Started/Completed: 27/07/09 – 16/08/09 To Be Completed By: Brett Dependencies: None Task Description: Design a system to monitor the batteries used in the vehicle and display relevant information to the user.

4.1.4. Safety Circuitry Date Started/Completed: 31/08/09 – 20/09/09 To Be Completed By: Steven Dependencies: None Task Description: Design circuitry to be implemented in the vehicle to ensure the safety of the user in the event of an accident. 48

All Electric City Vehicle Report

2009

4.1.5. Motor Position Sensor Testing Date Started/Completed: 06/04/09 – 03/05/09 To Be Completed By: Michael Dependencies: This task can only be started after the motor has been installed. Task Description: Initial testing to what outputs are available from the Prius motor.

4.1.6. DSP Programming Date Started/Completed: 18/05/09 – 14/06/09 To Be Completed By: Brett & Steven Dependencies: None Task Description: Program the DSP to ensure correct operation of the motor when the car is running.

4.1.7. Testing and Monitoring of Motor Date Started/Completed: 08/06/09 – 26/07/09 To Be Completed By: Michael Dependencies: Motor sensor testing must be completed prior to this task, and the accelerator potentiometer must also be installed. Task Description: Begin testing the motor and monitoring its outputs to ensure correct operation.

4.1.8. Install Battery Box Date Started/Completed: 11/05/09 – 31/05/09 To Be Completed By: Workshop Dependencies: This task may only be completed after the battery box has been designed. Task Description: Install the battery box into the vehicle to house the batteries.

49

All Electric City Vehicle Report

2009

4.1.9. Integration and Testing of Battery Monitoring System Date Started/Completed: 17/08/09 – 06/09/09 To Be Completed By: All group members Dependencies: The design of the BCS and BMS must be completed prior to this task. Task Description: Install the battery monitoring and charging systems previously designed, and then test them to ensure correct operation.

4.1.10. Integration and Testing of Safety Circuitry Date Started/Completed: 21/09/09 – 04/10/09 To Be Completed By: All group members Dependencies: The design of the safety circuitry must be completed prior to this task. Task Description: Install the safety circuitry previously designed, and then test it to ensure correct operation.

4.1.11. Vehicle Roadworthy Test Date Started/Completed: 12/10/09 – 18/10/09 To Be Completed By: All group members Dependencies: All technical tasks to be completed prior to this task Task Description: Get the vehicle inspected by a government representative so the car can be registered.

4.1.12. First Test Drive Date Started/Completed: 05/10/09 – 11/10/09 To Be Completed By: All group members Dependencies: All other design, integration and testing tasks. Task Description: Take the vehicle out for the first test drive to ensure all individual components are correctly integrated and the car operates as expected.

4.2.

Scheduling 50

All Electric City Vehicle Report

2009

The Gantt chart featured in figure 13 below shows the timeline originally designed by the group. It includes all associated tasks of the project on the left hand side and serves as a schedule for task completion for all project members.

Figure 23: Gantt Chart

This initial schedule was prepared by the group were rough approximations by the group, and unfortunately, was not upheld as strictly as it should have been. Perhaps the main reason that this schedule became unfeasible to follow was the underestimation of the time needed to complete tasks. Other reasons included several tasks that needed to be completed that weren’t in the project timeline. Most of the tasks that the group envisioned at the initial stages of the project were correct, with the major tasks of the project being very nearly completed. Programming of the DSP to provide motor control proved to be a more difficult task than first expected, and could not have been completed in the time-frame of one month that was originally estimated. The group was led to believe that there existed readily available motor control software available from TI that could be uploaded and tested. This was not the case however, as

51

All Electric City Vehicle Report

2009

the available software packages from TI were not designed for the project’s DSP and were incredibly complex to learn or understand. Instead, the program would need to be developed from scratch, and this involved a tremendous amount of research, development, debugging and consultation with TI and Spectrum Digital to actually set up and program the initial starting files to allow a program to be loaded onto the DSP. A steep learning curve had to be overcome to understand how the DSP worked and learning how to program the DSP through the use of its many system registers. This task is near completion and only requires testing of the space vector modulation module, optimisation to include interrupts and a module to handle input from the throttle potentionmetre. Found in the appendixes are the separate program files developed for the control of the motor. An R/D converter was designed and created to allow for the determination of the motor position and was successfully read in and as input by the DSP to use with the motor control program. Power cables, power inlet, conduits, and other small components were required to be researched, analysed and purchased that was not originally noted as a task in the timeline. An emergency disconnect switched was also purchased that will disconnect the batteries from the motor in the case of an emergency, and provides the essential solution for safety circuitry originally described in the timeline. Battery Monitoring System was made easier as this unit had already been purchased with the bulk of the lithium-iron phosphate batteries. A charger has been researched and purchased from the batteries after they were all individually tested to ensure they were within the acceptable range. Unfortunately, the individual components of the car have not been connected up nor has the motor control software been entirely completed to allow for a first test drive. A vehicle inspection by a government representative has also not been arranged due to the components not being integrated.

4.3.

Communication

52

All Electric City Vehicle Report

2009

Communication was a vital part in this project. Initially, two weekly meetings were set up for the group, a formal meeting including the project supervisor, and an informal meeting with just the group members. These weekly group meetings provided a lot of mentoring, advice, and guidance with respect to the project and were fundamental in ensuring each group member understood the direction the project was going. They provided an opportunity to alert the group of any new updates or advancements as well as asking questions. After the initial project stages, the second informal meeting between the group members was decided to not be required. Instead, it was easier to simply approach group members during spare times or in the project lab whenever an issue had arisen. Occasionally, additional meetings would be set up in order to prepare for upcoming project deliverables, such as the proposal seminar and the final seminar. Outside of these regular meetings, the project group mainly communicated through the use of email. E-mail provided an easy approach to communicate with each other and was the main form of communication used by the group outside of actual face-to-face contact of group meetings. Mobile phone numbers were also exchanged between the group members in cases where members needed to be alerted immediately of an issue. Communication was also required to manufacturers of the separate components already purchased and to be used in the project. This communication was required as the group regularly sought technical assistance from these companies, which mainly included Semikron, Texas Instruments and Spectrum Digital. Most of these communications were achieved through the use of e-mail, which provided an easy form of communication, but not necessarily the fastest one. No actual technical support contact from Texas Instruments was located in Australia, and as such, phoning them was considered too expensive an option for a form of communication. However, phone as a form of communication was possible to be used with Semikron when it was deemed that it took too long to achieve a response from them via e-mail.

4.4.

Budget

53

All Electric City Vehicle Report

2009

Figure 14 below displays a rough estimation of the budget for this year’s project that was drawn up by the group in the initial stages of the project. It is split up into five main sections; overall vehicle, motor, batteries, electrical accessories and inspection costs.

Figure 24: Project Budget

The budget for this year’s project involves mainly add-on accessories as all the main hardware components have already been purchased from last year and are available to the group. The project group came well within the estimated project budget, mainly because the battery management system listed on the initial project budget was no longer required to be purchased (had previously already obtained one). It is also worth mentioning that the group was able to secure a $1000 sponsorship provided by GHD through a personal contact.

4.5.

Risk Analysis

54

All Electric City Vehicle Report

2009

A list of risks was established again in the early stages of the project to mitigate any for-seen problems that could hinder the success of the project. Mitigation strategies were also included to reduce the likelihood of these potential risks from occurring. Frequency rating 0- 10 where 0 = very rare, and 10=often Severity 0-10 where 0 = incidental, and 10 = catastrophic Probability 0-10 where 0=unlikely, and 10 = highly probable Risk % where 0=acceptable, and 100 = mitigation action required

Risk

Freq

Severity

Prob

Risk

Damaging the inverter

2

9

3

33

Damage the batteries

1

9

4

40

Unable to register MX5

1

5

5

30

Faulty MX5 mechanical component

3

5

5

40

Unable to achieve required motor power

5

6

6

66

Check all theoretical calculations, diagnose any faults, perform additional simulations with different setups

Purchase additional hardware, optimise equipment available

Unable to interface motor to driveline

2

8

2

20

Provide workshop with required information and ensure they are progressing

Research alternative solutions

Unable to purchase required part

5

5

5

50

When choosing specific part, make sure there are equivalent parts

Look to purchase equivalent part or adjust design for different part

Damaging the Prius motor

1

9

3

30

Mitigation

Extensive testing on the bench, work to known safe voltage / current levels Extensive testing on the bench, work to known safe voltage / current levels, observe all warning signals. Ensure correct charging levels, check for any leakage, pre-mature damage Follow all procedures, obtain documentations of approval Ensure mechanic parts are in working condition

Resolution

Rebuild, replace faulty components or repurchase Send back to manufacturer for replacement or repurchase Seek replacement or repurchase at a cost Resolve issues, modify to comply with standards set, seek exceptions Seek to replace

55

All Electric City Vehicle Report Unable to interface with inverter

10

2

6

72

Check interface signals, check inputs to inverter

2009

Look to different hardware, extend research.

Table 3: Project Risks

Risk

Freq

Severity 8

Risk 5

Mitigation

Resolution

Ensure plan and progress documented

Arrange with supervisor to downsize project Provide training

Losing a team member

1

Project team members lack skills Member getting electrocuted Member injured by vehicle

2

7

20

Keep watch on progress

1

9

90

Instigate safety precautions

None

2

8

80

Instigate safety precautions

None

Team Conflict

2

5

20

Ensure good communication

Leader negotiates resolution

Table 4: People Risks

A lot of these risks documented early on in the project did not actually occur. However, other risks more associated with the technical aspects of the project occurred in large quantities that weren’t documented. These risks included; •

Not being able to get the DSP to communicate with the host computer.

•

Setting illegal values into the DSP’s memory

•

Not having the correct or entire documentation/manual for the Semikron inverter and TI DSP

•

Unable to test outputs from the inverter or receive in inputs to the inverter

•

Long time frame to get answers for questions lodged with manufacturers

•

Taking more time than initially set out to debug problems

56

All Electric City Vehicle Report

1.

2009

Conclusion

57

All Electric City Vehicle Report

2.

2009

References

58

All Electric City Vehicle Report

2009

•

Appendix A Appendix A details the linker command file. /* MEMORY { PAGE 0: PROG: origin = 0x0020 length = 0xFEE0 VECS: origin = 0x0000 length = 0x0020 PAGE 1: DATA: origin = 0x0300 length = 0xFD00 } SECTIONS { .text: PAGE = 0 .data: PAGE = 0 .cinit: PAGE = 0 // For –c and –cr .bss: PAGE = 1 vectors: > VECS PAGE 0 } */ MEMORY { PAGE 0 : /* program memory */ VECS: origin = 00000h, length = 00040h PASSWD: origin = 00040h, length = 00004h FLASH: origin = 00044h, length = 07FBCh PAGE 1 : /* data memory */ DARAN_B2: origin = 00060h, length = 00020h DARAM_B0: origin = 00200h, length = 00100h DARAM_B1: origin = 00300h, length = 00100h SARAM: origin = 00800h, length = 00800h Ext_Ram : origin = 08000h, length = 07E00h } SECTIONS { /* Sections generated by the C-compiler */ .text: > FLASH PAGE 0 /* initialized */ .cinit:> FLASH PAGE 0 /* initialized */ .const: > DARAM_B1 PAGE 1 /* initialized */ .switch: > FLASH PAGE 0 /* initialized */ .bss: > SARAM PAGE 1 /* uninitialized */ .stack: > SARAM PAGE 1 /* uninitialized */ .sysmem: > FLASH PAGE 0 /* uninitialized */ /* Sections declared by the user */ 59

All Electric City Vehicle Report

2009

vectors: > VECS PAGE 0 /* initialized */ }

Appendix B Appendix B details the vector.asm file. .ref _c_int0 .sect

"vectors"

rset: B _c_int0 int1: B int1 ;02h INT1 int2: B int2 ;04h INT2 int3: B int3 ;06h INT3 int4: B int4 ;08h INT4 int5: B int5 ;0Ah INT5 int6: B int6 ;0Ch INT6 int7: B int7 ;0Eh reserved int8: B int8 ;10h INT8 (software) int9: B int9 ;12h INT9 (software) int10: B int10 ;14h INT10 (software) int11: B int11 ;16h INT11 (software) int12: B int12 ;18h INT12 (software) int13: B int13 ;1Ah INT13 (software) int14: B int14 ;1Ch INT14 (software) int15: B int15 ;1Eh INT15 (software) int16: B int16 ;20h INT16 (software) int17: B int17 ;22h TRAP int18: B int18 ;24h NMI int19: B int19 ;26h reserved int20: B int20 ;28h INT20 (software) int21: B int21 ;2Ah INT21 (software) int22: B int22 ;2Ch INT22 (software) int23: B int23 ;2Eh INT23 (software) int24: B int24 ;30h INT24 (software) int25: B int25 ;32h INT25 (software) int26: B int26 ;34h INT26 (software) int27: B int27 ;36h INT27 (software) int28: B int28 ;38h INT28 (software) int29: B int29 ;3Ah INT29 (software) int30: B int30 ;3Ch INT30 (software) int31: B int31 ;3Eh INT31 (software)

60

All Electric City Vehicle Report

2009

Appendix C Appendix C details the main source file. #include "C:\CCStudio_v3.3\MyProjects\2407A\f2407_c.h" #include <math.h> int MCRA3=1; //variable for the bits required. int count; //variable use for counting purposes. int sum; //variable use for sum of 16 bits. double angle; double angle1; //variable for angle of resolver. int totalAngle=4096; //variable to hold 4096 int twoPi=360; //variable to hold full circle. int adres; // our A/D result unsigned int t; int loop = 1; double ia, ib, ic; //currents measured. unsigned int ia_temp, ib_temp, ic_temp, V_REF; //temporary until scaling takes effect. double Vref; //scaled version of Vref. unsigned int r, kdummy,SCSB, bit,kdummy2 ; unsigned int SCSB1; // variables for resolver angle unsigned int bitword[12]; double i_alpha, i_beta, i_sd, i_sq; double T,T0,T1,T2; //Tcalc. double Ux, Uy; //svm. void init() { /*** Configure the System Control and Status registers ***/ *SCSR1 = 0x00FD; /* bit bit bit bit bit bit bit bit bit bit

15 0: reserved 14 0: CLKOUT = CPUCLK 13-12 00: IDLE1 selected for low-power mode 11-9 000: PLL x4 mode 8 0: reserved 7 1: 1 = enable ADC module clock 6 1: 1 = enable SCI module clock 5 1: 1 = enable SPI module clock 4 1: 1 = enable CAN module clock 3 1: 1 = enable EVB module clock 61

All Electric City Vehicle Report

2009

bit 2 1: 1 = enable EVA module clock bit 1 0: reserved bit 0 1: clear the ILLADR bit */ *SCSR2 = (*SCSR2 | 0x000B) & 0x000F; /* bit 15-6 0's: reserved bit 5 0: do NOT clear the WD OVERRIDE bit bit 4 0: XMIF_HI-Z, 0=normal mode, 1=Hi-Z'd bit 3 1: disable the boot ROM, enable the FLASH bit 2 no change MP/MC* bit re>cts state of MP/MC* pin bit 1-0 11: 11 = SARAM mapped to prog and data */ /*** Disable the watchdog timer ***/ *WDCR = 0x00E8; /* bits 15-8 0's: reserved bit 7 1: clear WD :g bit 6 1: disable the dog bit 5-3 101: must be written as 101 bit 2-0 000: WDCLK divider = 1 */ /*** Setup external memory interface for LF2407 EVM ***/ WSGR = 0x0040; /* bit 15-11 0's: reserved bit 10-9 00: bus visibility off bit 8-6 001: 1 wait-state for I/O space bit 5-3 000: 0 wait-state for data space bit 2-0 000: 0 wait state for program space */ /*** Setup shared I/O pins ***/ *MCRA = 0x0000; /* group A pins */ /* bit 15 0: 0=IOPB7, 1=TCLKINA bit 14 0: 0=IOPB6, 1=TDIRA bit 13 0: 0=IOPB5, 1=T2PWM/T2CMP bit 12 0: 0=IOPB4, 1=T1PWM/T1CMP bit 11 0: 0=IOPB3, 1=PWM6 bit 10 0: 0=IOPB2, 1=PWM5 bit 9 0: 0=IOPB1, 1=PWM4 bit 8 0: 0=IOPB0, 1=PWM3 bit 7 0: 0=IOPA7, 1=PWM2 bit 6 0: 0=IOPA6, 1=PWM1 bit 5 0: 0=IOPA5, 1=CAP3 bit 4 0: 0=IOPA4, 1=CAP2/QEP2 bit 3 0: 0=IOPA3, 1=CAP1/QEP1 bit 2 0: 0=IOPA2, 1=XINT1 bit 1 0: 0=IOPA1, 1=SCIRXD bit 0 0: 0=IOPA0, 1=SCITXD 62

All Electric City Vehicle Report

2009

*/ *MCRB = 0xFE03; /* group B pins */ /* bit 15 1: 0=reserved, 1=TMS2 (always write as 1) bit 14 1: 0=reserved, 1=TMS (always write as 1) bit 13 1: 0=reserved, 1=TD0 (always write as 1) bit 12 1: 0=reserved, 1=TDI (always write as 1) bit 11 1: 0=reserved, 1=TCK (always write as 1) bit 10 1: 0=reserved, 1=EMU1 (always write as 1) bit 9 1: 0=reserved, 1=EMU0 (always write as 1) bit 8 0: 0=IOPD0, 1=XINT2/ADCSOC bit 7 0: 0=IOPC7, 1=CANRX bit 6 0: 0=IOPC6, 1=CANTX bit 5 0: 0=IOPC5, 1=SPISTE bit 4 0: 0=IOPC4, 1=SPICLK bit 3 0: 0=IOPC3, 1=SPISOMI bit 2 0: 0=IOPC2, 1=SPISIMO bit 1 0: 0=IOPC1, 1=BIO* bit 0 0: 0=IOPC0, 1=W/R* */ *MCRC = 0x0000; /* group C pins */ /* bit 15 0: reserved bit 14 0: 0=IOPF6, 1=IOPF6 bit 13 0: 0=IOPF5, 1=TCLKINB bit 12 0: 0=IOPF4, 1=TDIRB bit 11 0: 0=IOPF3, 1=T4PWM/T4CMP bit 10 0: 0=IOPF2, 1=T3PWM/T3CMP bit 9 0: 0=IOPF1, 1=CAP6 bit 8 0: 0=IOPF0, 1=CAP5/QEP4 bit 7 0: 0=IOPE7, 1=CAP4/QEP3 bit 6 0: 0=IOPE6, 1=PWM12 bit 5 0: 0=IOPE5, 1=PWM11 bit 4 0: 0=IOPE4, 1=PWM10 bit 3 0: 0=IOPE3, 1=PWM9 bit 2 0: 0=IOPE2, 1=PWM8 bit 1 0: 0=IOPE1, 1=PWM7 bit 0 0: 0=IOPE0, 1=CLKOUT */ /*** Setup CAN Mailbox I/O pins ***/ /**MSGID2H = 0x0000; /* MSG ID High pins */ /* bit 15 0: 0=Std, 1=Ext bit 14 0: 0=Acc Mask Disabled, 1=Acc Mask Enabled (Only relevant for receive) bit 13 0: 0=AAM Disabled, 1=AAM Enabled (Only relevant for transmit) bits 12-0 0: Upper 13 bits of Ext ID (12-2 store 11 bit ID for Std ID) */ /**MSGID2L = 0x0000; /* MSG ID Low pins */ /* bits 15-0 0: Lower part of Ext ID 63

All Electric City Vehicle Report

2009

*/ *MSGCTRL2 = 0x0001; /* MSG Control pins */ /* bits 15-5 0: reserved bit 4 0: 0=Data Frame, 1=Remote Frame bits 3-0 0: bytes used for transmission */ *MBX2A = 0x0000; /* Mailbox A pins */ /* bits 15-0 0: MSG */ *MBX2B = 0x0000; /* Mailbox B pins */ /* bits 15-0 0: MSG */ *MBX2C = 0x0000; /* Mailbox C pins */ /* bits 15-0 0: MSG */ *MBX2D = 0x0000; /* Mailbox D pins */ /* bits 15-0 0: MSG */ *MDER = 0x0000; /* Mailbox Direction & Enable pins */ /* bits 15-8 0: reserved bits 7-6 0: 0=Transmit, 1=Receive bits 5-0 0: 0=Mbx Disabled, 1=Mbx Enabled */ *TCR = 0x0000; /* Transmission Control pins */ /* bits 15-12 0: Set by internal logic on succesful transmission bits 11-8 0: Set by internal logic on aborted transmission bits 7-4 0: 0=No trans request, 1=Trans request set bits 3-0 0: Reset trans request (controlled by internal logic) */ *MCR = 0x1403; /* Master Control pins */ /* bits 15-14 0: reserved bit 13 0: 0=Soft mode, 1=Free mode bit 12 1: 0=No write request, 1=Write request to BCR1&2 bit 11 0: 0=Normal operation, 1=Power down request bit 10 1: 0=Data sent/received 3,2,1,0,7,6,5,4, 1=Data sent/received 0,1,2,3,4,5,6,7 bit 9 0: 0=Stay in PD mode until PDR=0, 1=Leave PD mode on bus activity bit 8 0: 0=Normal operation, 1=Request write access to data field of mbx in MBNR bit 7 0: 0=Auto bus on is off, 1=Auto bus on bit 6 0: 0=Normal mode, 1=Self test mode bits 5-2 0: reserved bits 1-0 1: Mailbox number for bit assertation (only 10 or 11) 64

All Electric City Vehicle Report

2009

*/ *BCR2 = 0x0000; /* Transmission Control pins */ /* bits 15-8 0: reserved bits 7-0 0: Baud rate prescalar (BRP=0 then 1TQ=1CPU clock cycle) */ *BCR1 = 0x0000; /* Transmission Control pins */ /* bits 15-11 0: reserved bit 10 0: CAN resynchronizes on falling edge only, 1=Reserved bits 9-8 0: Synch jump width bit 7 0: CAN samples only once, 1=CAN samples 3 times and makes majority decision bits 6-3 0: Timing seg1 bits 2-0 0: Timing seg2 */ //resetting the fault signals and the switches. *PADATDIR = 0xC0C0; //4 *PBDATDIR = 0x0F0F; //E *PEDATDIR = 0xFEFF; SIGNALS *PFDATDIR = 0x0808;

//

THESE ARE USED FOR RESETING ERROR

} void ad_init() { //*ADCTRL1 = 0xA10E; //*ADCTRL2 = 0x4000;

//

calibrate ADC with 1.65V ref voltage

//bitdelay(); // Setup the fIrst A/D control register *ADCTRL1=0xA180; // A/D ctl reg // Setup the second A/D control register *ADCTRL2= 0x4000; /* group C pins */ *MAX_CONV= 0x0003; // max_conv=max_conv+1...we're doing four channel *CHSELSEQ1=0x6666; // we are using A/D channel 0 only , channel 1 is not connected (v_i2) //*CHSELSEQ2 = 0x2104; } void gt_AD_smp() { // Reset the second control register to get a new sample *ADCTRL2= 0x2000; /* group C pins */ 65

All Electric City Vehicle Report

2009

} void delayout() // just a simple 24 us delay routine to produce 20kHZ clock freqency { // half period of 24us for 21.09kHZ clock frequency unsigned int i; // for our counter for(i = 500; i > 0; i--) { //asm("NOP"); // do a NOP a bunch of times } } void bitdelay() { unsigned int i; // for our counter for(i = 950; i > 0; i--) { //asm("NOP"); // do a NOP a bunch of times } } double sumangle() { angle = (bitword[0]*1)+(bitword[1]*2)+(bitword[2]*4)+(bitword[3]*8)+ (bitword[4]*16)+(bitword[5]*32)+(bitword[6]*64)+(bitword[7]*128)+ (bitword[8]*256)+(bitword[9]*512)+(bitword[10]*1024)+ (bitword[11]*2048); angle = 4095 - angle; angle = angle/11.375; return angle; } void delayuntilbit12() { unsigned int i; // for our counter for(i = 1436; i > 0; i--) { //asm("NOP"); // do a NOP a bunch of times } } void T1OUT() { *GPTCONA = 0x000A; // T1 AND T2 PIN ACTIVE HIGH 66

All Electric City Vehicle Report

*T1CNT = 0x0000; *T1PR = 750; *DBTCONA = 0x0000; *CMPR1 = 563; *ACTRA = 0x0000; *COMCONA = 0x8200; *T1CON = 0x0840; }

2009

//CLEAR TIMER COUNTER // ????? // NO DEADBAND TIME // ?????

void clarke() { i_alpha = (2/3)*ia - (1/3)*(ib-ic); i_beta = 1.1547*(ib-ic); } void park() { i_sd = i_alpha * cos(angle1) + i_beta*sin(angle1); i_sq = -i_alpha*sin(angle1) + i_beta*cos(angle1); } void { ia = ib = ic =

inv_clarke() i_alpha; (-1/2)*i_alpha + ((0.86603)*i_beta); (-1/2)*i_alpha - ((0.86603)*i_beta);

} void inv_park() { i_alpha = i_sd*cos(angle1) - i_sq*sin(angle1); i_beta = i_sd*sin(angle1) + i_sq*cos(angle1); } void spaceVector() { *COMCONA = 0x9200; //enable compare operation, space vector mode, reload underflow. *T1CON = 0x4942; //continuous up/down counting mode. *DBTCONA = 0x0BF8; //deadtime. *ACTRA = 0xF999; //active high->active low T0=(1/2)*T; //T0 = 50% period of total. if (angle1 < 60) { 67

All Electric City Vehicle Report

2009

*ACTRA = 0x9999; //state 001. //V1=Vc=2/3. V2=Vbc=0 T2 = (T*(2/3) - T0*(2/3) - Vref*T)/(2/3); T1 = T - T0 - T2; //store into CMPR1 and CMR2. } else if (angle1 > 60 && angle1 < 120) { *ACTRA = 0xB999; //state 011. //V1=Vbc=0. V2=Vb=2/3. T2 = (-1*Vref)*T/(-(2/3)); T1 = T - T0 - T2; } else if (angle1 > 120 && angle1 < 180) { *ACTRA = 0xA999; //state 010. //V1=Vb=1/3. V2=Vab=0. T2 = (T*(1/3) - T0*(1/3) - Vref*T)/(1/3); T1 = T - T0 - T2; } else if (angle1 > 180 && angle1 < 240) { *ACTRA = 0xE999; //state 110. //V1=Vab=0. V2=Va=2/3. T2 = (-1*Vref)*T/(-(2/3)); T1 = T - T0 - T2; } else if (angle1 > 240 && angle1 < 300) { *ACTRA = 0xC999; //state 100. //V1=Va=2/3. V2=Vac=0. T2 = (T*(2/3) - T0*(2/3) - Vref*T)/(2/3); T1 = T - T0 - T2; } else //if (angle1 > 300 && angle1 <=360) { *ACTRA = 0xD999; //state 101. //V1=Vac=0. V2=Vc=2/3 T2 = (-1*Vref)*T/(-(2/3)); T1 = T - T0 - T2; } } 68

All Electric City Vehicle Report

2009

// This must be an interupt void resolver() { int j =11; int count =1; // for use with enc1 (PIN 6) PA4 for SCSB and Serial data is on Enc3 (pin 8) PA5 // Using a serial clk of 20.88 kHZ // 3 bit low time = 288us while(loop == 1) { kdummy =*PADATDIR; SCSB1 =*PADATDIR; SCSB1 <<= 11; SCSB1 >>= 15; count = count +1; if(SCSB1 ==0) { delayuntilbit12(); while(j >-1) { kdummy2 = *PADATDIR; bit = *PADATDIR; bit <<= 10; bit >>= 15; bitword[j] = bit; bitdelay(); j = j-1; } j=11; } angle1 = sumangle(); } } void can_trans() { *MSGID2H = 0x0004; *MSGID2L = 0x0000; 69

All Electric City Vehicle Report

2009

*MSGCTRL2 = 0x0008; *MBX2A = 0xB38F; *MDER = 0x000C; *TCR = 0x003F; } void combo() { *PADATDIR = 0xC0C0; *PBDATDIR = 0x0F06; delayout(); *PBDATDIR = 0x0F0F; delayout(); }

void main() {

*ADCTRL1 = //*T1CON = init(); // ad_init(); //

0x4000; // resets adc 0x0000; //DISABLE TIMER 1 call initialization routine // call the A/D initialization routine

*PADATDIR = 0xC08F;

//c08f

//*encoderInput = 0x7090; //points to memory address 7090h this is I/O mux control register A. //register at this memory address contains 16 bits. Only want the 3rd bit. //this requires shifting to only obtain the 3rd bit. //register format = bits 15,14,.....2,1,0. // MCRA3 = *encoderInput; // MCRA3 <<= 12; //shifting 12 bits left. // MCRA3 >>= 15; //shifting 13 bits right to obtain the bit 3 () we need from register. *PADATDIR = 0xC040; //4 *PBDATDIR = 0x0F0E; //E // *PEDATDIR = 0xFEFF; SIGNALS // *PFDATDIR = 0x0808;

//

THESE ARE USED FOR RESETING ERROR

70

All Electric City Vehicle Report

2009

/* ******** setting up interrupts ********* */

*IMR = 0x0000; *IFR = 0x003F; /* ******* *EVAIFRA = *EVAIFRB = *EVAIFRC =

//clearing IMR register //clearing any pending requests with 1's, not 0s.

event manager interrupts 0xFFFF; /* clear all EVA 0xFFFF; /* clear all EVA 0xFFFF; /* clear all EVA

******* group A group B group C

*/ interrupts */ interrupts */ interrupts */

do { // // // //

adres = *RESULT0; // read A/D port 0 ia = *RESULT1; //phase current sensors ib = *RESULT2; ic = *RESULT3; *PADATDIR = 0xC0C0; //4 *PBDATDIR = 0x0F06; //E

//

combo();

//

resolver();

rate

gt_AD_smp(); // get a new A/D converter sample delayuntilbit12(); // delay a bit. this delay will set the sample ia_temp = *RESULT0; ia_temp = *RESULT0; ib_temp = *RESULT1; ic_temp = *RESULT2; V_REF = *RESULT3; ia_temp ib_temp ic_temp V_REF

>>= >>= >>= >>=

6; 6; 6; 6;

// //

*PADATDIR = 0xC0C0; //4 *PBDATDIR = 0x0F0F; //E

//

can_trans(); 71

All Electric City Vehicle Report

2009

//printf(t); // //

delayuntilbit12(); *PBDATDIR = 0x3000; delayuntilbit12(); *ADCTRL2 = 0x4000;

} while(loop ==1); }

72