PSAS/ CapstoneLV2bProjectReport

logo.jpg

PSAS Avionics Node Front End for LV2b Rocket

To:

Capstone Team Members:

(16-June-2006)

Table of Contents

  1. Introduction
  2. (Final) Requirements
  3. System Level Design
    1. Communications Bus
      1. Bus Requirements
      2. CAN and USB Comparison
    2. Microcontroller
      1. Requirements
      2. 32-bit Microcontrollers considered
      3. ARM Comparison
      4. Final Choice
    3. RTOS
      1. eCos
    4. System Block Diagram
      1. Block Diagram of Node
      2. Switching Power Supply (SPS) Block Diagram
      3. ARM and Glue Circuitry Block Diagram
  4. Detailed Design
    1. Schematics
      1. Eagle CAD Schematic of node
    2. Board Layout
  5. Component Specification
    1. SPS
      1. Front end Passive Block
      2. Circuit Breaker Block
      3. Overvoltage Protection
      4. Switcher
      5. Secondary Voltage Supply
      6. Power LED
      7. Bill of Materials (BOM)
    2. ARM and Glue Circuitry
      1. ARM 7 microcontroller (U280)
      2. Power decoupling (C285, 286, 287, 288, 291, 292, 293, 294)
      3. USB filtering block
      4. Power-on reset
      5. Oscillator and divider
      6. RTC crystal oscillator
      7. Debug port
      8. Power Good and Shutdown
      9. Breakout of signals to application specific area
      10. Status LEDs
      11. Test points
      12. Configuration trace-cuts or solder jumpers
      13. Bill of materials (BOM)
  6. Software
    1. Introduction
    2. Tools used
      1. Serial Terminal
      2. ISP Software
      3. Cross-Compiler
    3. Serial Port Test
    4. "Hello Blinky World!" Example
      1. Introduction
      2. License Issue
      3. Modifications From Original
      4. Source Code Review
      5. Compiling and Downloading Instructions
      6. Results
    5. eCos Port
      1. Introduction
      2. LPC2148 Port
      3. Source Code Review
      4. Compiling the eCos Demo
      5. Downloading Instructions
    6. Future Work
  7. Construction and Test Plan
    1. SPS
      1. Front end
      2. Circuit breaker (CB)
      3. Switcher
      4. Overvoltage (OV)
      5. Secondary supply
      6. Final System block testing
    2. ARM and Glue Circuitry
      1. Reset Circuitry
      2. Crystal Oscillator
      3. USB interface
      4. ARM + Glue "power up"
      5. ARM + Glue final block testing
    3. Software
      1. Node Testing
      2. Initial USB Testing
      3. USB Performance Testing
    4. Final System Testing
  8. References
    1. USB
    2. Switching Buck Regulator
  9. Appendix
    1. User Manuals

2006 Capstone Project Final Report

Introduction

Our Capstone project was sponsored by the Portland State Aerospace Society. PSAS is a Portland State University student club that focuses on amateur rocketry projects. Students and industry professionals design and build motors, airframes, avionics hardware, and write software, all with the end goal of launching an "open source" rocket. All the designs and software are freely available on the PSAS website, so any amateur group could duplicate our results.

Since the successful but finally disastrous launch of Launch Vehicle No. 2 (LV2), the PSAS Avionics Team has been redesigning the avionics system. This new system, called the "LV2b" avionics system, should avoid the limitations of the old system:

The goal of the PSAS Capstone team is to design the generic front-end that interfaces between all the nodes of the system (GPS, IMU, recovery system, etc) and the communication bus.

(Final) Requirements

There are three requirements for completion of our capstone project:

These engineering notebooks should cover the three major areas of design: the Switching Power Supply (SPS), the microcontroller and glue circuitry, and the software. The notebooks should contain a detailed discussion of how the design works and an explanation of all component choices and values. A smart, experienced engineer should be able to use this document to understand why the design is the way it is.

System Level Design

Communications Bus

Part of our capstone project was to decide what communications bus the next generation rocket should use. Numerous suggestions were thrown out (from FireWire to MIL-STD-1553) but only two communication buses were considered in depth: the Universal Serial Bus (USB) and the Controller Area Network (CAN) bus.

Bus Requirements

Avionics Team Requirements

Reliability

The bus must be capable of handling EMI, along with short and open conditions on the PHY layer. The bus must tolerate the acceleration and vibration associated with a launch. The bus should also have been used in real-time systems where a failure in the bus might result in lives being lost (such as medical equipment or automobiles). The bus must provide a way for the software to prioritize messages so that system critical messages will be sent, even at the expense of non-critical messages.

Performance

The bandwidth of the bus must be large enough to keep data flowing and nodes operational. Some nodes will require access to the bus on regular intervals, while others will be sending non-periodic data packets. The previous rocket's CAN bus provided 1Mbps, and at most 40% of that bandwidth was used. The bandwidth requirement may change, so more bandwidth would be better.

Software Team Requirements

High level software control

The Software team would like the high-level software to deal with retransmission of corrupted packets and packets that were not received by the intended recipient. System critical messages like commands for parachute deployment and manual overrides from ground support are important to retransmit if a failure occurs. Retransmission of time-based data like IMU readings is not useful and may eat up the bandwidth of the bus.

Connectivity

The bus should be able to interface to laptops during testing with minimal difficulty. The communications connectors should be easy to remove during development and testing, but must lock down during flight. It would also be ideal if the node controllers could be flashed over the bus.

Firmware and Device Drivers

The firmware for the node controllers should be maintainable. If there already exists tested bus protocol drivers, it would be advantageous to use them to minimize the development time and design complexity. Firmware and device driver development should not require proprietary software or a propriety environment (i.e. Windows).

CAN and USB Comparison

Avionics Team Requirements

Reliability

Both USB and CAN are differential buses, and are more immune to EMI than single-ended buses. CAN is used in some automobile systems, but not in any systems where failure of the bus alone would result in an accident. USB is used in some medical devices, but not in life-critical devices.

CAN and USB differ in how they prioritize messages. CAN provides a message-by-message prioritization: when the bus is idle and two nodes attempt to transmit, the node with a higher prioritization continues to transmit and the other node waits for the bus to become idle. USB allows the software to reserve bandwidth for each USB endpoint.

USB relies on a host (in our case, the flight computer) to initiate all transactions, even interrupts. This means that if the flight computer powers off, no messages will flow on the bus. With the CAN peer-to-peer model, the bus would still operate if the flight computer were offline.

Performance

CAN provides 1Mbps, and full-speed USB provides 12Mbps.

Software Team Requirements

High Level Software Control

The CAN controller handles packet retransmission automatically. The Software team is concerned about the automatic retransmission of all corrupted packets. Often we don't want an older time-dependent message (such as an IMU message) to be retransmitted if it means that we don't receive the newest message. If a high priority node starts sending lots of corrupted packets, it may flood the bus with automatic retransmissions. This is a remote possibility, but it demonstrates the inflexibility of the CAN transmission protocol.

USB provides some flexibility when it comes to message retransmission. If the transmitter uses isochronous transfers, there is no ACK of the message, and corrupted packets are not retransmitted. Isochronous transfers provide guaranteed bandwidth, and would be ideal for messages from the IMU. Control transfers provide a limited amount of guaranteed bandwidth (10% of the frame, or more if the isochronous transfers take less than 90% of the bandwidth). They are acknowledged by the receiver, and automatically retransmitted if the message was not acknowledged or if it was corrupted. Control transfers would be ideal for system critical messages, such as data from the DTMF receiver board or commands to the recovery node. Each USB endpoint could be set to a different transfer type.

Connectivity

A USB communications bus could be directly plugged into a software developer's laptop. CAN requires special conversion hardware (such as USB to CAN adapters) to interface with a laptop. USB will require a special connector, since the standard connector does not lock into place. However, CAN has no standard connector, so we will be creating our own custom connectors anyway.

Firmware and Device Drivers

The most likely candidate for an open source RTOS is eCos, and the flight computer will run Linux. PSAS members have experience writing CAN drivers, but they also have local contacts with people who write Linux USB device drivers. There are many Linux and eCos USB drivers available that could be modified, but few CAN drivers. Linux and eCos both have a hardware-independent driver framework for USB, but not for CAN.

PSAS members have written CAN drivers, and PSAS has contacts with programmers who have written USB drivers for Linux. Even if we find a device driver that meets most of our needs, there will probably be some custom "hacking" on it.

Summary

Hardware Requirements

Requirement

CAN

USB

"best" bus

EMI immunity

Differential bus

Differential bus

-

tolerance to over-voltage

built-in

none

CAN

safety critical systems usage

automobiles

some medical devices

CAN

message priority

individual node priority

bandwidth priority

?

bus topology

peer-to-peer

host initiated

?

speed

1Mbps

12Mbps (full speed)

USB

Software Requirements

Requirement

CAN

USB

"best" bus

packet retransmission

automatic

depends on message type

USB

packet size

up to 8 bytes

up to 1023 bytes

USB

connectivity

special connection disrupts debugging

plugs in directly to a laptop

USB

previous open source drivers

very few

good Linux support

USB

As the chart shows, the Avionics team wanted the CAN bus because it provided better hardware reliability and was widely used in safety critical systems. However, USB was an overall win for the Software team. In the end, the promise of higher bandwidth and better open source support won over the Avionics team.

Microcontroller

Requirements

The microcontroller for the node front-end must meet the following requirements:

Architecture

Development Tools

Packaging

Peripherals

Computational Horsepower

Power Consumption

Cost

32-bit Microcontrollers considered

There were two microcontroller architectures considered initially: ARM (Advanced RISC Machine) and PPC (Power PC). ARMs are popular microcontrollers with good open source support. On the other hand, PSAS has a grant from IBM to use Power PC microcontrollers on the rocket. A quick look at PPC manufactures revealed the microcontrollers did not meet our package size requirements; the smallest package size available was a 168 pin BGA.

ARM Comparison

The capstone team searched the websites of over 34 companies that license the ARM core. Of those companies, only five had microcontrollers with CAN or USB: Atmel, Freescale, Philips, STMicroelectronics, and Texas Instruments.

There were roughly 30 chips that met our requirements. We compared the 30 chips, looking at various characteristics, such as package size, speed, memory, and peripherals. For the full comparison chart, see the file ARMs.xls

There were 11 microcontrollers that best met our requirements: 5 had both CAN and USB, 3 had CAN only, and 3 had USB only. The microcontrollers that had both CAN and USB were all 100 pin packages from Atmel. Once we looked at drawings of pin package sizes compared to our required board size, we realized that we simply couldn't fit a 100 pin package on the board. That only left the 64-pin CAN only or USB only microcontrollers.

When the decision was made to use USB in the next generation rocket, we took a look at the USB only ARM chips. There were three top choices: an Atmel AT91SAM7S256, the Philips LPC2148, and the STM STR711FR2T6.

Comparison Chart

Characteristic

Atmel

Philips

STM

production status

production

sampling

active

SRAM (KB)

64

40

64

flash (KB)

256

512

256

frequency (MHz)

55

60

66

JTAG

Y

Y

Y

serial boot

N

Y

?

A/D bits

10

10

12

number of ADCs

8

14

4

max number of GPIO pins

32

45

30

UARTs

3

2

4

SPIs

1

2

2

I2C

1

2

2

16 bit timers

3

4

4

PWM channels

4

3

4

Watch dog reset

Y

Y

Y

brown out reset

Y

Y

?

power on reset

Y

Y

?

RTC

Y

Y

N

Miscellaneous "Warts" Found

Atmel

To use USB, the system designer is forced to under clock the microcontroller at 48MHz. It also doesn't have a real-time clock (only a real-time timer). The Atmel chip was discarded early in the selection process because of USB issues (see below).

Philips

Philips was lacking in memory, and the quoted SRAM size of 40KB is deceptive. There is 32KB of SRAM for general use, but 8KB of that is reserved for USB. That puts it on the lower limits of our memory requirements.

The Philips part exclusively uses an internal 1.8V voltage regulator, which means we can't hook up our switching power supply. This increases the power consumption of the system.

Also, the pin multiplexing may prove troublesome. When PSAS designs a self-correcting rocket, all three PWMs will be used on a node to control motor servos. The PWMs on the LPC2148 conflict with other devices we want to use, such as SPI and UART0. However, this need is far in the future and we may switch to a new microcontroller before then.

STM

The STM part also requires the microcontroller to be run at 48MHz to use USB.

Another wart was that the ADC conversion time is listed as 1ms. This was unacceptable, considering that the other two microcontrollers listed 2us conversion times. The PLL lock time also seemed to be a bit long; it was listed as 600us, while Philips listed a 100us lock time. Further, the internal oscillator takes 2.5 seconds to start up. If the microcontroller has to do a hard restart in flight, we would lose half of the apogee window to oscillator initialization.

Also, the data sheet was vague about whether the internal voltage regulator could be bypassed in Standby mode.

USB Considerations

The STM documentation for USB was severely lacking. Their datasheet did not indicate how many of each type of USB endpoint were available. The lack of documentation made this an unacceptable choice.

The Atmel part only had four USB endpoints; two endpoints could be configured to be isochronous endpoints. They also listed endpoint 0 as being able to send control, bulk, or interrupt transfers. This seemed to be an indication they were doing something out of spec with their USB controller, since the USB specification clearly states that endpoint 0 must be reserved for control transfers from the host.

The Philips chip had the best documentation of the three chips, and it had the most endpoints. The LPC2148 had 16 USB endpoints and 4 endpoints could be configured to be isochronous endpoints.

Final Choice

In the end, we decided to choose the Philips LPC2148 chip because of its great documentation and USB support.

RTOS

A program with real-time requirements will need a real-time operating system. With a standard operating system, there is no guarantee that time constraints of a program will be met. This is disastrous in an avionics system, when a delay in sensor data or recovery node commands may mean the parachute is not deployed in the 5 second apogee window.

RTOS Requirements:

There were two RTOS that fit all requirements: eCos (http://ecos.sourceware.org/) and FreeRTOS (http://www.freertos.org/). PSAS members have more experience with eCos, so eCos was chosen.

eCos

eCos stands for "embedded Configurable operating system". eCos is configurable because you can choose which features you want to compile into your embedded operating system. This allows you to tweak your options if you don't have a lot of memory in your embedded system. For example, a programmer can choose to compile GDB stubs into their program and eCos. This is great for debugging, but can inflate the code size. After the person is done coding and wants to run the program out in the field, they can recompile eCos without GDB stubs to save memory.

System Block Diagram

Here is the new avionics system design:

lv2 avionics diagram 2006-06-01 sized.png

Block Diagram of Node

The scope of this project is within the dashed line.

sys block.png

Each generic node front-end contains a switching power supply (SPS), some "glue circuitry", and an ARM microcontroller running a real-time operating system (RTOS).

Switching Power Supply (SPS) Block Diagram

SPS Block Diagram.png

Power Bus

Front end Passive Block

Circuit Breaker Block

Overvoltage Protection Block

Switcher

+3.3 V SPS

Power LED

Secondary Voltage Supply

ARM and Glue Circuitry Block Diagram

The underlying goal of the Glue subsystem is to satisfy the interconnection needs of the microcontroller, and to provide any forseen resources to the application specific area for future users.

glue block.png

System Block Diagram - Glue

ARM7 microcontroller (CPU)

Power decoupling

USB filtering block

Power-on reset

Oscillator and divider

RTC crystal oscillator

Debug port

Power Good and Shutdown

Breakout of signals to application specific area

Status LEDs

Test points

Configuration trace-cuts or solder jumpers

Detailed Design

Schematics

Eagle CAD Schematic of node

The schematics used in the design of this project appear in two forms; one for the Spice circuit simulator, and another for the Eagle CAD PCB board layout tool. This section only shows the Eagle CAD schematic. The Spice schematic was used for verification of the SPS design, and can be found in that section.

Naming convention

The name of this project according to PSAS convention is:

So the name of this board is: lv2-node4-frontend

Getting the Eagle CAD board layout tool

Go to the Eagle CAD site (http://www.eagle.de) and follow the instructions under downloads for your specific platform. For this project we used the Debian Linux distribution, and thereby were able to use Debian's package management tool called Aptitude. The following command on a Debian Linux system installs the Eagle CAD software package.

sudo apt-get install eagle

Getting the Eagle schematic files for this project

The schematic files for this project are kept in the PSAS Subversion source repository. The following Linux command checks out the CAD sub-tree from the repository which includes the node-4 files, and needed libraries. To find out more about Subversion see: <http://subversion.tigris.org/>

svn co http://svn.psas.pdx.edu/svn/psas/trunk/cad

The above command will check out the entire PSAS cad directory. The files you will actually need for this project are:

It is intended that eventually the <node4.lbr> library be merged into the <psas-eagle-library.lbr> library at a future time.

Maintaining the files

To maintain the schematics, be sure you have latest copies before starting by doing an update command. Once your changes are made, check them into the repository using the check-in command.

svn up    # get latest update
svn ci    # check-in your latest work

Board Layout

This is the preliminary board layout; it is not complete. The board dimensions are 2 in. x 3 in. with traces on only two sides. Components are also on top and bottom. The decision to use only two trace layers was driven by the desire to use the free version of Eagle CAD, which is a PSAS standard.

On the left top side of the board is the USB/Power connector. The Debug port will be placed on the left bottom side.

gnl board.png

Both top and bottom of board shown with component placemets

gnl board top.png

Top side only of board

gnl board bot.png

Bottom side only of board

Component Specification

SPS

SPS Design Schematic rev2 2.png

SPS Design Schematic rev2 2.pdf

Note: It is easier to refer to the schematic above when reading section 1.5.1 instead of the detailed Eagle schematic in section 1.4.1.1. This is because this section exclusively covers all SPS components. The part numbers are consistent with those in the Eagle schematic.

Front end Passive Block

Power Bus Input Choke (L201a, L201b)

Part Description:

Purpose:

Specifications/ Calculations:

Power Bus Fast-Acting Fuse (F200)

Part Description:

Purpose:

Specifications/ Calculations:

DC Path From SPS Node GND to Chassis GND Resistor (R215)

Part Description:

Purpose:

Specifications/ Calculations:

Power Bus Input Caps (C203, C204)

C203

Part Description:

Purpose:

Specifications/ Calculations:

C204

Part Description:

Purpose:

Specifications/ Calculations:

Power Bus Input Voltage Suppressor (TVS200)

Part Description:

Purpose:

Specifications/ Calculations:

Circuit Breaker Block

MAX5902 Circuit-Breaker Resistor Network (R250, R251)

R250

Part Description:

Purpose:

Specifications/ Calculations:

R251

Part Description:

Purpose:

Specifications/ Calculations:

Overcurrent/Circuit-Breaker Protection (U250)

Part Description:

Purpose:

Specifications/ Calculations:

MAX5902 External P-MOSFET (Q250)

Part Description:

Purpose:

Specifications/ Calculations:

MAX5902AAETT Circuit-Breaker External P-MOSFET RDS(on) Additional Series Resistor (R252)

Part Description:

Purpose:

Specifications/ Calculations:

Overvoltage Protection

Undervoltage/Overvoltage Protection (U251)

Part Description:

Purpose:

Specifications/ Calculations:

TLV3012AIDBVT Overvoltage Detection External N-MOSFET Current Limiting Resistor (R253)

Part Description:

Purpose:

Specifications/ Calculations:

TLV3012AIDBVT External Logic-Level N-MOSFET (Q251)

Part Description:

Purpose:

Specifications/ Calculations:

TLV3012AIDBVT UVLO Lockout Resistor Network (R254, R255)

R254

Part Description:

Purpose:

Specifications/ Calculations:

R255

Part Description:

Purpose:

Specifications/ Calculations:

TLV3012AIDBVT "Secondary Power Supply" Schottky Diode (CR250)

Part Description:

Purpose:

Specifications/ Calculations:

TLV3012AIDBVT "Secondary Power Supply" Cap (C250)

Part Description:

Purpose:

Specifications/ Calculations:

TLV3012AIDBVT Overvoltage Detection Cap (C251)

Part Description:

Purpose:

Specifications/ Calculations:

Switcher

Step-Down Switching Voltage Regulator (Buck Topology) (U200)

Part Description:

Purpose:

Specifications/ Calculations:

LT1767EMS8 UVLO Lockout Resistor Network: (R209, R210)

R209

Part Description:

Purpose:

Specifications/ Calculations:

R210

Part Description:

Purpose:

Specifications/ Calculations:

LT1767 UVLO Resistor Network Shunt Cap (C210)

Part Description:

Purpose:

Specifications/ Calculations:

Buck Input Cap (C201)

Part Description:

Purpose:

Specifications/ Calculations:

LT1767 Frequency Compensation Caps (C205, C206)

C205

Part Description:

Purpose:

Specifications/ Calculations:

C205 may not be needed given that the frequency compensation of R206/C206 is satisfactory.

C206

Part Description:

Purpose:

Specifications/ Calculations:

Boost Cap (C202)

Part Description:

Purpose:

Specifications/ Calculations:

Boost Rectifier Diode (CR201)

Part Description:

Purpose:

Specifications/ Calculations:

Buck (Catch) Schottky Diode (CR200)

Part Description:

Purpose:

Specifications/ Calculations:

Split Buck Inductor (L200a, L200b)

Part Description:

Purpose:

Specifications/ Calculations:

Buck Output Cap (C200)

Part Description:

Purpose:

Specifications/ Calculations:

LT1767 FB Resistor Network: (R200, R201)

R200

Part Description:

Purpose:

Specifications/ Calculations:

R201

Part Description:

Purpose:

Specifications/ Calculations:

LT1767 FB Resistor Network Shunt Caps (C208, C209)

C208

Part Description:

Purpose:

Specifications/ Calculations:

C209

Part Description:

Purpose:

Specifications/ Calculations:

SPS Output Power On LED Current Limiter Resistor (R214)

Part Description:

Purpose:

Specifications/ Calculations:

Secondary Voltage Supply

SPS Secondary Buck (Catch) Schottky Diode (CR251)

Part Description:

Purpose:

Specifications/ Calculations:

SPS Secondary Buck Output Cap (C252, C252a)

Part Description:

Purpose:

Specifications/ Calculations:

Power LED

SPS Output Power On LED (D201)

Part Description:

Purpose:

Specifications/ Calculations:

Bill of Materials (BOM)

NOTE: Component fields with a "-" mean they are TBD.

Digi-Key BOM

Qty

Digi Key SKU

Cust ID

Part

Mfgr

Description

Mfg Num

Price

Stock

Package

Order Size

5

LT1767EMS8-ND

PSAS-SPS

U200

Linear Tech

Switching Step-Down Voltage Buck Regulator

LT1767EMS8

6.00

2716

8-MSOP

1

5

PCC2401CT-ND

PSAS-SPS

C200

Pansonic-ECG

22 uF Ceramic Cap

ECJ-2FB0J226M

8.31

4740

0805

10

5

PCC2414CT-ND

PSAS-SPS

C201

Pansonic-ECG

10 uF Ceramic Cap

ECJ-3YB1E106K

5.45

7640

1206

10

5

PCC1840CT-ND

PSAS-SPS

C202

Pansonic-ECG

0.1 uF Ceramic Cap

ECJ-2YB1H104K

1.61

21520

0805

10

5

399-3782-1-ND

PSAS-SPS

C203

Kemet

22 uF Tantalum Cap

T491D226K025AT

0.65

863

7434-31

1

5

490-3327-1-ND

PSAS-SPS

C204

Murata Electronics North America

0.33 uF Ceramic Cap

GRM219R71H334KA88D

3.09

3090

0805

10

5

-

PSAS-SPS

C205

-

-

-

-

-

-

-

5

-

PSAS-SPS

C206

-

-

-

-

-

-

-

5

-

PSAS-SPS

C208

-

-

-

-

-

-

-

5

BC1256CT-ND

PSAS-SPS

C209

BC Components

10 pF Ceramic Cap

VJ0805A100JXACW1BC

0.52

80

0805

10

5

BC1298CT-ND

PSAS-SPS

C210

BC Components

0.1 uF Ceramic Cap

VJ0805Y104KXATW1BC

0.72

60

0805

10

5

399-3127-1-ND

PSAS-SPS

C250

Kemet

2.7 uF Ceramic Cap

C0805C275K8PACTU

7.02

3860

0805

10

5

478-1359-1-ND

PSAS-SPS

C251

AVX Corp

0.015 uF Ceramic Cap

08051C153KAT2A

2.64

5300

0805

10

5

-

PSAS-SPS

C252, C252a

-

-

-

-

-

-

-

15

MA2Q70500LCT-ND

PSAS-SPS

CR200,CR250,CR251

Panasonic-SSG

30V Schottky Diode

MA2Q70500L

6.24

4192

MiniPower 2P

10

5

MMBD1501TPMSCT-ND

PSAS-SPS

CR201

Micro Commercial Co.

180V Rectifier Diode

MMBD1501-TP

2.00

3000

SOT-23

10

5

L71515CT-ND

PSAS-SPS

D201

CML Innovative Technologies Inc

1.9V Orange LED

CMDA5BA7D1S

0.35

3048

0805

1

5

WK6213CT-ND

PSAS-SPS

F200

Wickman USA Inc/Littlefuse Inc

500 mA Fast Acting Fuse

FCD120500TP

0.56

4521

1206

1

5

ZXMP6A17E6CT-ND

PSAS-SPS

Q250

Zetex Inc

P-Channel MOSFET

ZXMP6A17E6TA

1.04

2755

SOT-23-6

1

5

BSS123INCT-ND

PSAS-SPS

Q251

Infineon Technologies

N-Channel Logic-Level MOSFET

BSS123E6327

0.36

4177

SOT-23

1

5

SMBJ18ADICT-ND

PSAS-SPS

TVS200

Diodes Inc

Unidirectional Voltage Suppressor

SMBJ18A-13

0.89

896

SMB

1

20

RHM10.0KCCT-ND

PSAS-SPS

R200,R210,R251,R255

Rohm

10 kohm Resistor

MCR10EZHF1002

0.38

34,300

0805

10

5

RHM17.4KCCT-ND

PSAS-SPS

R201

Rohm

17.4 kohm Resistor

MCR10EZHF1742

0.38

3370

0805

10

5

-

PSAS-SPS

R206

-

-

-

-

-

-

-

5

RHM60.4KCCT-ND

PSAS-SPS

R209

Rohm

60.4 kohm Resistor

MCR10EZHF6042

0.38

960

0805

10

5

RHM649CCT-ND

PSAS-SPS

R214

Rohm

649 ohm Resistor

MCR10EZHF6490

0.38

760

0805

10

5

RHM100KCCT-ND

PSAS-SPS

R215

Rohm

100 kohm Resistor

MCR10EZHF1003

0.38

15560

0805

10

5

RHM61.9KCCT-ND

PSAS-SPS

R250

Rohm

61.9 kohm Resistor

MCR10EZHF6192

0.38

3160

0805

10

5

P.82DCT-ND

PSAS-SPS

R252

Panasonic-ECG

0.82 ohm Resistor

ERJ-6RQFR82V

2.10

4440

0805

10

5

RHM47.0KCCT-ND

PSAS-SPS

R253

Rohm

47.0 kohm Resistor

MCR10EZHF4702

0.38

6840

0805

10

5

RHM18.2KCCT-ND

PSAS-SPS

R254

Rohm

18.2 kohm Resistor

MCR10EZHF1822

0.38

3650

0805

10

Coiltronics BOM

Qty

Coiltronics SKU

Cust ID

Part

Mfgr

Description

Mfg Num

Price

Stock

Package

Order Size

5

SD3118-470-R

PSAS-SPS

L200a,L200b

Coiltronics

47 uH Inductor

SD3118-470-R

-

-

Shielded Drum "Bobbin" (SMT)

-

5

CMS1-11-R

PSAS-SPS

L201,L202

Coiltronics

100 uH Inductor

CMS1-11-R

-

-

Torodial (SMT)

-

ARM and Glue Circuitry

ARM 7 microcontroller (U280)

Part Description:

Purpose:

Specifications/ Calculations:


Power decoupling (C285, 286, 287, 288, 291, 292, 293, 294)

C285, C286, C287, C288, C291, C292, C293, C294

Part Description:

Purpose:

Specifications/ Calculations:


USB filtering block

The following figure illustrates the USB filtering block.

gnl schem usb.png

Fig. Glue.1

Driver impedance matching resistors (R281, R282)

Part Description:

Purpose:

Specifications/ Calculations:

Edge rate control capacitor (C289, C290)

Part Description:

Purpose:

Specifications/ Calculations:

USB Full Speed Select (R291)

Part Description:

Purpose:

Specifications/ Calculations:

USB Port Transient Suppressor (U282)

Part Description:

Purpose:

Specifications/ Calculations:

sn65220 1.png Image from TI SN65220 datasheet

Fig. Glue.2

sn65220 2.png Image from TI SN65220 datasheet

Fig. Glue.3

EMI/RF Filter (L281, L282)

Part Description:

Purpose:

Specifications/ Calculations:

exccet.png Image from Panasonic EXCCET data sheet

Fig. Glue.4

IO Power and Ground

Purpose:


Power-on reset

Microcontroller Supervisory Circuit (U283)

Part Description:

Purpose:

Specifications/ Calculations:

mcp130 2 2.png Image from Microchip MCP130 datasheet

Fig. Glue.5

mcp130 1 1.png Image from Microchip MCP130 datasheet

Fig. Glue.6


Oscillator and divider

gnl schem osc.png

Fig. Glue.7

Frequency control crystal (X281)

Part Description:

Purpose:

Specifications/ Calculations:

Philips requires for 10 to 15 MHz range

Citizen crystal provides

CL (crystal load capacitance): 20 pF

18 pF

RS (max series resistance): &lt; 220 ohm

50 ohm

Frequency tolerance

50 ppm

Footprint

6.0 mm x 3.3 mm

Oscillator load capacitors (C281, C282)

C281

Part Description:

Purpose:

Specifications/ Calculations:

C282

Part Description:

Purpose:

Specifications/ Calculations:

Having the nominal capacitance of CX1, and CX2 being slightly unequal provides an increased energy efficiency in the oscillator according to Tim.

Binary ripple counter (U281)

Part Description:

Purpose:

Specifications/ Calculations:

cd4024.png Image from TI CD4024 datasheet

Fig. Glue.8


RTC crystal oscillator

Oscillator load capacitors (C283, C284)

C283
C284

Part Description:

Purpose:

Specifications/ Calculations:

Frequency control crystal (X282)

Part Description:

Purpose:

Specifications/ Calculations:

Philips requires

Citizen crystal provides

CL (crystal load capacitance): 13 pF

12.5 pF

RS (max series resistance): &lt; 100k ohm

70 k ohm

Frequency tolerance

+/- 20 ppm

Footprint

4.1 mm x 1.5 mm

Power to oscillator


Debug port

Connector (CM201)

Part Description:

Purpose:

Specifications/ Calculations:

Pull up/down resistors (R283, 284, 285, 286, 287, 288)

Part Description:

Purpose:

Specifications/ Calculations:


Power Good and Shutdown

Power Good

Purpose:

Specifications/ Calculations:

Power Shutdown

Purpose:

Specifications/ Calculations:


Breakout of signals to application specific area

Purpose:

Specifications/ Calculations:


Status LEDs

Red LED (D281)

Part Description:

Purpose:

Specifications/ Calculations:

Vf

at I

2.1V

20 mA

Green LED (D282)

Part Description:

Purpose:

Specifications/ Calculations: Connected to general purpose output pin P1.16; Called Status 1.

Vf

at I

2.1V

20 mA

Current limit resistors (R289, R290)

R289
R290

Part Description:

Purpose:

Specifications/ Calculations:


Test points

SPS Off

Pwr Good

1.5 MHz (SPS Sync)

Purpose:

Specifications/ Calculations:


Configuration trace-cuts or solder jumpers

Analog VREF

RTC Power (VBAT)

Purpose:

Specifications/ Calculations:


Bill of materials (BOM)

Following are the components needed to construct the Glue section of the board.

Qty

Digi Key SKU

Cust ID

Part

Mfgr

Description

Mfg Num

Price

Stock

Package

Order Size

Data Sheet

5

568-1765-ND

PSAS-GLUE

U280

Philips

ARM7 Microcontroller

LCP2148FBD64-S

11.88

86

64-LQFP

each

Datasheet

5

296-12760-1-ND

PSAS-GLUE

U281

TI

7-stage CMOS ripple counter

CD4024BPWR

0.50

3020

14-TSSOP

each

Datasheet

5

296-9694-1-ND

PSAS-GLUE

U282

TI

USB port transient suppressor

SN65220DBVR

0.84

-

SOT-23-6

each

Datasheet

5

MCP130T-315I/TTCT-ND

PSAS-GLUE

U283

Microchip

Microcontroller Supervisory Circuit

MCP130T

0.48

100

SOT-23-3

each

Datasheet

5

PSAS-GLUE

J281

JST

JST-08PS-JED

each

5

PSAS-GLUE

J282

JST

JST-16PS-JED

each

5

300-8089-1-ND

PSAS-GLUE

X281

Citizen

12 MHz Surface Mount Crystal - Fundamental Mode

CS10

1.65

-

CS10

each

Datasheet

* 5

300-8193-1-ND

PSAS-GLUE

X282

Citizen

32.768 kHz Surface Mount Crystal - Tuning Fork

CM415-32.768KDZFTR

2.10

1122

CM415

each

Datasheet

5

PCC390CGCT-ND

PSAS-GLUE

C281

Panasonic

Chip NP0 39 pF

0.49

-

0805

10 pack

5

PCC330CGCT-ND

PSAS-GLUE

C282

Panasonic

Chip NP0 33 pF

0.49

-

0805

10 pack

10

PCC220CNCT-ND

PSAS-GLUE

C283,284

Panasonic

Chip NP0 22 pF

0.69

-

0805

10 pack

30

PCC103BNCT-ND

PSAS-GLUE

Note(1) C285,286,287,288,291,292,293,294

Panasonic

Chip X7R 10 nF

0.54

-

0805

10 pack

10

PCC180CNCT-ND

PSAS-GLUE

C289,290

Panasonic

Chip NP0 18 pF

0.60

-

0805

10 pack

10

P9829CT-ND

PSAS-GLUE

L281,282

Panasonic

Chip EMI Filter Type EXCCET

EXC-CET471U

0.685

C type

10 pack

Datasheet

10

P33.2CCT-ND

PSAS-GLUE

R281,282

Panasonic

Chip 1% Thick film

0805

10 pack

30

P10.0KCCT-ND

PSAS-GLUE

R283,284,285,286,287,288

Panasonic

Chip 1% Thick film

0805

10 pack

* 10

P604CCT-ND

PSAS-GLUE

R289,290

Panasonic

Chip 1% Thick film

0805

10 pack

5

BSS123NCT-ND

PSAS-GLUE

Q282

Fairchild

Logic level N-channel

BSS123

0.36

0

SOT-23

each

* 5

L71516CT-ND

PSAS-GLUE

D281

LED Red

SOT-23

each

* 5

L71508CT-ND

PSAS-GLUE

D282

LED Green

SOT-23

each

* 5

P1.50KCCT-ND

PSAS-GLUE

R291

Panasonic

Chip 1% Thick film

0805

10 pack

NOTES: (1) C285, 286, 287, 288, 291, 292 should be a 100 nF cap, not 10 nF.

"*" Needs to be ordered

Software

Introduction

To paralellize the software and hardware development, software for the LPC2148 was developed on an evaluation board from Olimex. The developed software will work exactly the same on the node front-end, since it only relies on the type of ARM chip. Two software programs were developed and shown to work on the Olimex evaluation board:

The eCos port was an optional requirement for our project, and puts software development ahead of schedule.

Tools used

Our industry sponsors required all software used in this project to run under Linux. Running under Windows was optional, but software that is open-source is a big win. If the software is open-source, we can modify it when we find bugs and give the source back to the community.

Serial Terminal

The LPC2148 chip can communicate over the serial port. It will respond to special In-System Programming (ISP) commands specified in the Philips datasheet. These commands include (but are not limited to) setting the baud rate, writing to RAM, copying from RAM to flash, reading from memory, and echoing the part ID or boot code version.

The LPC2148 serial communication can easily be tested using a terminal that sends data over the serial port. In Linux, minicom is the software of choice. Minicom comes preinstalled with Debian Linux and open-source under the GNU General Public License (GPL). I used version 2.1 (compiled Nov 4 2005).

ISP Software

To download programs into flash and RAM on the LPC2148, a programmer needs to have In-System Programming (ISP) software. This software uses the ISP command specification to send program binaries over the serial port or JTAG. Typically, this means writing a chunk of program to RAM and then burning it to flash. A programmer would have to type hundreds of commands over the serial port if they wanted to do this manually.

There are several options for ISP software. Philips gives away a flash utility for LPC2xxx chips. However, they only distribute the executable, which doesn't work under Linux. http://www.semiconductors.philips.com/products/microcontrollers/support/software_download/lpc2000/index.html

Macraigor systems also distributes a flash memory programmer. It works under Linux and Windows, but requires JTAG. A JTAG connector is fairly expensive, so we wanted another alternative. http://www.macraigor.com/flash_prog.htm

The ISP software selected for use is a flash programmer that uses the serial port. It runs under Linux and in Windows (using Cygwin) and is fully open source. http://guest.engelschall.com/~martin/lpc21xx/isp/ I used version 1.31. The program is one c file that you'll need to compile. You should add the directory containing the compiled program to your path.

Cross-Compiler

In order to compile programs for the ARM chip, you need a cross-compiler. A cross-compiler builds native code (ARM programs) on non-native systems (Intel x86). GNU provides a c and c++ compiler tool chain called gcc. To build a gcc cross-compiler, follow the instructions at http://psas.pdx.edu/DebianCrossCompilerHowto. Replace any mention of "powerpc" or "ppc" with "arm". I used gcc 4.0 to build the cross-compiler.

eCos

The real-time operating system (RTOS) chosen to run on the nodes is the embedded Configurable operating system (eCos).

Building eCos

  1. Go to http://ecos.sourceware.org/getstart.html and follow the instructions under the section 'eCos'. Do not follow the 'Toolchain' instructions; those are equivalent to making the cross-compiler. I don't suggest installing eCos in /opt/ecos because it requires root to run the eCos configuration tool and update your sources.
  2. Make sure to add the configtool path to your PATH environment variable. configtool is found in $ECOS_INSTALL_DIR/ecos/ecos-2.0/tools/bin.
  3. Go to http://ecos.sourceware.org/anoncvs.html and follow the instructions for checking out the latest eCos repository.
  4. Make sure that your environment has ECOS_REPOSITORY set to the packages directory in the eCos CVS sources.
  5. Run configtool. Choose Build -> Repository... and enter the path to the eCos CVS directory.

You can check that eCos has found the repository by seeing if the GPL-GPS template is available. Go to Build->Templates.... In the first drop down menu, scroll down through the available templates. If you see the "GPS 4020" template, eCos has access to the CVS repository.

Serial Port Test

Software needed:

First, flip switch 1 on the Olimex board to up. Next, you need to set up minicom. Start minicom up with minicom -s. This brings you to the setup menu. Go to "Serial port setup" to change some settings. Type 'A' to change the serial device. I used a USB to serial adaptor in Linux, so I set up my output port to be /dev/ttyUSB0. Make sure hardware and software flow control are both set to 'No'. Type 'E' to set the Bps, parity, and stop bit. You should configure it for 8 data bits, 1 stop bit, no parity, and 38400 Bps.

Once minicom is configured, save the setup and exit to minicom. Type CTRL+A+A to add a linefeed to the data (the LPC2148 expects a carriage return followed by a linefeed at the end of every command).

Once minicom is setup and running, follow these steps:

  1. Send "?" (the synchronization character).
  2. Wait for the board to send back "Synchronized".
  3. Send "Synchronized" back.
  4. Board will send back "OK".
  5. Now the board is waiting for the frequency in kHz for the crystal oscillator on the board. "12000" is correct for the Olimex board.
  6. Board will send back "OK" if synchronization occurs. Otherwise it goes back to waiting for a synchronization character ("?").

After these steps, you can send any of the commands listed in Chapter 21 of the LPC214X User Manual. A simple test that doesn't touch memory is to make the chip echo the microcontroller part number. The command to send is "J". The LPC2148 should send back "67305253".

"Hello Blinky World!" Example

Tools needed:

Software needed:

Introduction

The source code for this demo was written by Jim Lynch. The source code and tutorial can be found on this SparkFun thread: http://www.sparkfun.com/cgi-bin/phpbb/viewtopic.php?t=1331.

License Issue

The header file LPC214x.h defines names for memory-mapped addresses. The header file was released by the USA Philips Marketing Team on the LPC2000 yahoo group. http://groups.yahoo.com/group/lpc2000/message/9444

The header file was part of a USB toolkit that Philips sold to consumers. It has a rather nasty license referenced in it, which says that you cannot use the header file in open source code or redistribute it anyone who hasn't agreed to licensing terms. The Philips Marketing Team invalidated this license by posting the header file on public forum. The header file is built on public knowledge and could be replicated by anyone with the LPC214x User Manual, which further weakens the license's copyright claims.

The LPC2000 prohibits users from posting copyrighted works in their files sections saying, "Do not upload any copyright material to the group's Files area. It will be deleted and the offender banned from the group." The file remains and Philips Marketing Team has not been banned from the group, which leads me suspect no one assumed the license was valid.

Modifications From Original

If you're a Linux user, change this line in main.c

#include lpc2141x.h

to

#include LPC2141x.h

The header file is misnamed in the top line. This bug doesn't show up for Windows users because Windows is case-insensitive.

Also, he got some bit math wrong in demo2148_blink_flash.cmd

ram_isp_low(A)  : ORIGIN = 0x40000120, LENGTH = 223

should change to

ram_isp_low(A)  : ORIGIN = 0x40000120, LENGTH = 224

This bug won't affect the blinky LED demo since it doesn't take up a lot of room in RAM.

The Makefile is created for the arm-elf tool chain, so you'll have to change the lines that start with "CC". Change the gcc compiler to "arm-linux-gnu-gcc" and the rest from "arm-elf-*" to "arm-linux-*".

Source Code Review

File usage:

Code Snippet (main.c)

...
int main (void) {
    ...
    // Initialize the system
    Initialize();

    // set io pins for led P0.10
    SCS = 0x03;             // select the "fast" version of the I/O ports
    FIO0DIR |= 0x00000400;  // pin P0.10 is an output,
                            // everything else is input after reset
    FIO0SET =  0x00000400;  // led off
    FIO0CLR =  0x00000400;  // led on

    // endless loop to toggle the red LED P0.10
    while (1) {
        for (j = 0; j < 5000000; j++ ); // wait 500 msec
        FIO0SET = 0x00000400;           // red led off
        for (j = 0; j < 5000000; j++ ); // wait 500 msec
        FIO0CLR = 0x00000400;           // red led on
    }
}
...

The snippet from main.c is fairly simple. It makes the GPIO pin P0.10 an output, and then turns the LED on and off by setting and clearing the GPIO output.

The remaining 100 lines of main.c contains interrupt routine stubs and a function to initialize the chip. The initialization function sets the main clock frequency to 60MHz (an unacceptable rate to use USB with), initializes the current controlled oscillator, sets the number of clock cycles to fetch memory out of flash, enables MAM, and sets the peripheral clock to the main clock frequency. This code, along with the start-up assembly code and memory map file, would not be necessary if the program was running under eCos.

Compiling and Downloading Instructions

Once the necessary changes are made to the makefile, you can simply type 'make' in the demo directory. This will compile the program into a main.out and a main.hex file. Now you'll need to use lpc21isp to download the main.hex file to the LPC2148.

Set switch 1 on the Olimex board to on and plug the serial cable from RS232_0 (on the Olimex board) to your computer. Power cycle the board.

Now you'll want to send the program to the Olimex flash memory. lpc21isp will write a flash block's worth of the program to RAM, then burn that to flash. To send the main.hex file to the Olimex board, run the following command:

lpc21isp -debug -hex -PHILIPSARM main.hex /dev/ttyUSB0 38400 12000

The -debug flag tells the program to print out debug statements. The -hex flag means the program should expect a hex file to send, and the -PHILIPSARM flag means we're sending to a Philips chip. main.hex is the file to send, and /dev/ttyUSB0 is the port to send it over. I was using a USB to serial adaptor, so I used the Linux specific path that pointed to that USB device. If you're using Windows or a serial port on your computer, you'll need to replace "/dev/ttyUSB0" with the OS specific path (usually "com1" for serial in Windows).

The program will write bits across the serial cable for a couple minutes. Once the program is done, you'll see "Download Finished..." followed by a message that it's launching the new code. Launching from the software doesn't work. You'll need turn switch 1 off and push the reset button. Then you should see LED1 blinking away.

Results

The program worked as intended, and the LED attached to P0.10 blinked constantly. The author intended it to blink once a second, and it blinks a little slower than that. There is no guarantee what the compiler will do with the delay loops, so a better solution would have been to use an internal timer on the chip. However, for a simple demo, this works fine.

eCos Port

Tools needed:

Software needed

Introduction

To get eCos running on a microcontroller, a programmer must first create an eCos port for the microcontroller. This includes a memory map, initialization code, a hardware abstraction layer (HAL), and more. Typically an existing port for a similar processor can be modified, but it still requires a lot of work.

LPC2148 Port

Fortunately, Pawel Wodnicki has created a port for the LPC2136/8 and LPC2146/8 microcontrollers. (http://sourceware.org/ml/ecos-patches/2005-11/msg00014.html) The patch has not been merged into the CVS truck, but it can still be used to patch the current eCos sources. Download the patch into the ecos directory (the original, not the CVS repository). Then type patch -p1 < ecos-iH1-proc_lpc_1.patch. There will be some warnings, but they should be fine.

Once you have a patched eCos, you can load Pawel's template for the LPC2148. Open configtool and go to Build -> Templates.... In the first drop down menu, choose the template called "Hobby-Robotics iH 1_proc_lpc_1 board". This was designed to work on Pawel's evaluation board, but it will work for any LPC2148 board.

LPC2148 Port Modifications

I needed to make a couple configuration changes to compile under the arm-linux toolchain. The first fix was to change CYGBLD_GLOBAL_COMMAND_PREFIX to "arm-linux-gnu".

Most of the other changes involved adding or removing compilation flags to make eCos build. The difference in flags are probably due to using a newer gcc (the eCos folks are still using gcc 3.2, whereas I compiled with gcc 4.0).

I changed CYGBLD_GLOBAL_CFLAGS from

-mcpu=arm7tdmi -mno-short-load-words -Wall -Wpointer-arith -Wstrict-prototypes -Winline -Wundef -Woverloaded-virtual -g -O2 -ffunction-sections -fdata-sections -fno-rtti -fno-exceptions -fvtable-gc -finit-priority

to

-mcpu=arm7tdmi -mno-short-load-words -Wall -Wpointer-arith -Wstrict-prototypes -Winline -Wundef -g -O2 -ffunction-sections -fdata-sections -fno-exceptions -fvtable-gc -ffreestanding -fno-use-cxa-atexit

The flag "-ffreestanding" wasn't strictly necessary, but the flag "-fno-use-cxa-atexit" solved many of the compilation errors.

There were still linker errors, so the CYGBLD_GLOBAL_LDFLAGS needed to be changed from

-mcpu=arm7tdmi -mno-short-load-words -Wl,--gc-sections -Wl,-static -g -nostdlib

to

-mcpu=arm7tdmi -Wl,--gc-sections -Wl,-static -g -nostdlib

The change of flags made some linker errors go away, but the linker was still complaining that certian sections weren't in the target.ld file. There was no references to the sections any any other code, so we suspected it was a bug in the linker. To make the linker happy, we added this changed these lines in target.ld

   .rom_vectors 0x00000000 : { __rom_vectors_vma = ABSOLUTE(.); . = .; KEEP (*(.vectors)) } > rom __rom_vectors_lma = LOADADDR(.rom_vectors);
   .text ALIGN (0x1) : { _stext = ABSOLUTE(.); PROVIDE (__stext = ABSOLUTE(.)); *(.text*) *(.gnu.warning) *(.gnu.linkonce.t.*) *(.init) *(.glue_7) *(.glue_7t) } > rom _etext = .; PROVIDE (__etext = .);

to

   .rom_vectors 0x00000000 : { __rom_vectors_vma = ABSOLUTE(.); . = .; KEEP (*(.vectors)) } > rom __rom_vectors_lma = LOADADDR(.rom_vectors);
    .got ALIGN (0x4) : { . = .; *(.got*) *(.rel*) } > rom
   .text ALIGN (0x1) : { _stext = ABSOLUTE(.); PROVIDE (__stext = ABSOLUTE(.)); *(.text*) *(.gnu.warning) *(.gnu.linkonce.t.*) *(.init) *(.glue_7) *(.glue_7t) } > rom _etext = .; PROVIDE (__etext = .);

Looking at the linker output, the added sections only took up 4 bytes.

Source Code Review

To test the eCos port, I wrote a program to turn on two LEDs. Here is "blinky.c" in its entirety:

#include "LPC214x.h"
#include <cyg/kernel/kapi.h>

void Initialize(void);
void feed(void);

void cyg_user_start(void)
{
   // Initialize the system

   // set io pins for led P0.10
   SCS = 0x03;             // select the "fast" version of the I/O ports
   FIO0DIR |= 0x00000C00;  // pin P0.10 and P0.11 are outputs
                           // bit 11 and 10 set = 0 1100 0000 0000
                           // = 0xC00
   FIO0SET = 0x00000400;   // P0.10 led off
   FIO0SET = 0x00000800;   // P0.11 led off
   FIO0CLR = 0x00000400;   // P0.10 led on
   FIO0CLR = 0x00000800;   // P0.11 led on
}

Comments

This code is much cleaner and simplier than the non-eCos code. The blinky.c code was 21 lines long, whereas the non-eCos main.c code was 168 lines of code (much of that initialization code). The eCos compiled code size is bigger than the non-eCos code size because of the linked eCos code. Here is a comparison of the code size in bytes obtained using arm-linux-gnu-size:

code type

text

data

bss

dec

non-eCos demo

788

24

28

840

eCos demo

24808

844

17044

42696

The eCos demo is 42KB. The program resides in flash memory on the LPC2148, but parts of it will be loaded into RAM at run-time. The LPC2148 has 32KB RAM and 512MB flash, so that still leaves enough room for future software development.

Compiling the eCos Demo

Once you have patched your eCos repository with Pawel's patch (see the RTOS section), you're ready to build the eCos program. First, download the tarball lpc2148 ecos.tgz. Extract it with "tar xvzf lpc2148_ecos.tgz" in whatever directory you want.

Change to the lpc2148_ecos directory and run configtool. Open lpc2148_rom.ecc by choosing File -> Open. Then create the eCos source tree by choosing Build -> Generate Build Tree. Once that has finished, choose Build -> Library. The command won't finish, due to errors from the target.ld file. Replace target.ld in /lpc2148_ecos/lpc2148_rom_install/lib/ with the target.ld file in the tarball (found in the same directory as blinky.c).

Then type

make INSTALL_DIR=$TAR_DIR/lpc2148_ecos/lpc2148_rom_install

where $TAR_DIR is the directory where you extracted the tarball.

Now you should have a blinky.hex file in the directory.

Downloading Instructions

Set switch 1 on the Olimex board to on and plug the serial cable from RS232_0 (on the Olimex board) to your computer. Power cycle the board.

Now you'll want to send the program to the Olimex flash memory. lpc21isp will write a flash block's worth of the program to RAM, then burn that to flash. To send the blinky.hex file to the Olimex board, run the following command:

lpc21isp -debug -hex -PHILIPSARM blinky.hex /dev/ttyUSB0 38400 12000

(See the "Hello Blinky World!" section for an explanation of the command.)

The program will write bits across the serial cable for a couple minutes. Once the program is done, you'll see "Download Finished..." followed by a message that it's launching the new code. Launching from the software doesn't work. You'll need turn switch 1 off and push the reset button. Then you should see both LED1 and LED2 glowing.

Future Work

The next step in software development is to write an eCos USB driver for the LPC2148. There are a few examples of other eCos USB drivers in the eCos repository, but they only use control and bulk transfers. Implementing eCos isochronous transfer support will require intensive development and extensive knowledge of eCos and USB.

Once the eCos USB driver has been implemented, a user-land Linux USB driver needs to be developed for the flight computer. This project will require both Linux and USB knowledge. Both projects are beyond the scope of this capstone project.

Construction and Test Plan

SPS

Front end

Turn on transient for passives

Circuit breaker (CB)

CB trip point (make sure fuse doesn't blow)

Quiescent current draw of U250

Switcher

Minimum discontinuous mode current

Minimum output voltage for the minimum on time of U200

Frequency compensation testing & component selection

Light/Heavy load

Hot/Cold temperature

High/Low input voltage

Overvoltage (OV)

Start up of OV (no latch-up, no oscillations)

Check adequacy of comparator power supply

Secondary supply

Estimation of secondary supply voltage and maximum current

Cross regulation of dual voltage supplies (what effects do each have on the other)

Final System block testing

Maximum system current flow

Temperature rise

Cleanliness of OV and CB trip points

Voltage(s) seen when coming out of undervoltage (UV) lockouts (both CB and the switcher)

Efficiency

ARM and Glue Circuitry

Reset Circuitry

Crystal Oscillator

USB interface

ARM + Glue "power up"

Interval

Description

Details

t4..t5

Determined by LPC2148

When Vdd goes below 2.9 V, the LPC2148 issues a brown-out interrupt. When Vdd is below 2.6 V, the LPC2148 internally asserts it's reset. See page 42

t6..t8

Determined by MCP130 and is called Trpu

Typical time is 275 ms. See MCP130 Fig. 2.3. The LPC2148 requires 10 ms; see page 38 of users manual.

t3..t7

The SPS oscillator is free-running

SPS_Sync has not yet been provided. The SPS should be running around 1.25 MHz.

ARM + Glue final block testing

Software

Node Testing

Initial USB Testing

USB Performance Testing

Final System Testing

* System specifications

References

USB

Switching Buck Regulator

Appendix

User Manuals

Page Links


Attachments: