GUI BUILDING IN NETBEANS

Introduction to GUI Building

Contributed by Saleem Gul and Tomas Pavek

This beginner tutorial teaches you how to create a simple graphical user interface and add simple back-end functionality. In particular we will show how to code the behavior of buttons and fields in a Swing form.

We will work through the layout and design of a GUI and add a few buttons and text field. The text fields will be used for receiving user input and also for displaying the program output. The button will initiate the functionality built into the front end. The application we create will be a simple but functional calculator.

For a more comprehensive guide to the GUI Builder’s design features, including video demonstrations of the various design features, see Designing a Swing GUI in NetBeans IDE.

Expected duration: 15 minutes

Contents

 

To complete this tutorial, you need the following software and resources.

Software or Resource

Version Required

NetBeans IDE with Java SE version 6.9, 6.8, or 6.7
Java Development Kit (JDK) version 6

Exercise 1: Creating a Project

The first step is to create an IDE project for the application that we are going to develop. We will name our project NumberAddition.

  1. Choose File > New Project. Alternatively, you can click the New Project icon in the IDE toolbar.
  2. In the Categories pane, select the Java node. In the Projects pane, choose Java Application. Click Next.
  3. Type NumberAddition in the Project Name field and specify a path e.g. in your home directory as the project location.
  4. (Optional) Select the Use Dedicated Folder for Storing Libraries checkbox and specify the location for the libraries folder. SeeSharing Project Libraries for more information on this option.
  5. Ensure that the Set as Main Project checkbox is selected.
  6. Deselect the Create Main Class checkbox if it is selected.
  7. Click Finish.

Exercise 2: Building the Front End

To proceed with building our interface, we need to create a Java container within which we will place the other required GUI components. In this step we’ll create a container using the JFrame component. We will place the container in a new package, which will appear within the Source Packages node.

Create a JFrame container

  1. In the Projects window, right-click the NumberAddition node and choose New > Other.
  2. In the New File dialog box, choose the Swing GUI Forms category and the JFrame Form file type. Click Next.
  3. Enter NumberAdditionUI as the class name.
  4. Enter my.numberaddition as the package.
  5. Click Finish.

The IDE creates the NumberAdditionUI form and the NumberAdditionUI class within the NumberAddition application, and opens the NumberAdditionUI form in the GUI Builder. The my.NumberAddition package replaces the default package.

Adding Components: Making the Front End

Next we will use the Palette to populate our application’s front end with a JPanel. Then we will add three JLabels, three JTextFields, and three JButtons. If you have not used the GUI Builder before, you might find information in the Designing a Swing GUI in NetBeans IDE tutorial on positioning components useful.

Once you are done dragging and positioning the aforementioned components, the JFrame should look something like the following screenshot.

 

If you do not see the Palette window in the upper right corner of the IDE, choose Windows > Palette.

  1. Start by selecting a JPanel from the Palette and drop it onto the JFrame.
  2. While the JPanel is highlighted, go to the Properties window and click the ellipsis (…) button next to Border to choose a border style.
  3. In the Border dialog, select TitledBorder from the list, and type in Number Addition in the Title field. Click OK to save the changes and exit the dialog.
  4. You should now see an empty titled JFrame that says Number Addition like in the screenshot. Look at the screenshot and add three JLabels, three JTextFields and three JButtons as you see above.

Renaming the Components

In this step we are going to rename the display text of the components that were just added to the JFrame.

  1. Double-click jLabel1 and change the text property to First Number
  2. Double-click jLabel2 and change the text to Second Number
  3. Double-click jLabel3 and change the text to Result
  4. Delete the sample text from jTextField1. You can make the display text editable by right-clicking the text field and choosing Edit Text from the popup menu. You may have to resize the jTextField1 to its original size. Repeat this step for jTextField2 and jTextField3.
  5. Rename the display text of jButton1 to Clear. (You can edit a button’s text by right-clicking the button and choosing Edit Text. Or you can click the button, pause, and then click again.)
  6. Rename the display text of jButton2 to Add.
  7. Rename the display text of jButton3 to Exit.

Your Finished GUI should now look like the following screenshot:

 

Exercise 3: Adding Functionality

In this exercise we are going to give functionality to the Add, Clear, and Exit buttons. The jTextField1 and jTextField2 boxes will be used for user input and jTextField3 for program output – what we are creating is a very simple calculator. Let’s begin.

Making the Exit Button Work

In order to give function to the buttons, we have to assign an event handler to each to respond to events. In our case we want to know when the button is pressed, either by mouse click or via keyboard. So we will use ActionListener responding to ActionEvent.

  1. Right click the Exit button. From the pop-up menu choose Events > Action > ActionPerformed. Note that the menu contains many more events you can respond to! When you select the actionPerformed event, the IDE will automatically add an ActionListener to the Exit button and generate a handler method for handling the listener’s actionPerformed method.
  2. The IDE will open up the Source Code window and scroll to where you implement the action you want the button to do when the button is pressed (either by mouse click or via keyboard). Your Source Code window should contain the following lines:
  3. We are now going to add code for what we want the Exit Button to do. You will have to type System.exit(0); to the above code, replacing the TODO line. Your finished Exit button code should look like this:
  4. Click the Design tab at the top of your work area to go back to the Form Design
  5. Right click the Clear button (jButton1). From the pop-up menu select Events > Action > actionPerformed.
  6. We are going to have the Clear button erase all text from the jTextFields. To do this, you will add some code like above. Your finished source code should look like this:
3.           private void jButton3ActionPerformed(java.awt.event.ActionEvent evt) {
4.               //TODO: Add your handling code here:
                }
6.           private void jButton3ActionPerformed(java.awt.event.ActionEvent evt) {
7.               System.exit(0);
                }

Making the Clear Button Work

private void jButton1ActionPerformed(java.awt.event.ActionEvent evt){
    jTextField1.setText("");
    jTextField2.setText("");
    jTextField3.setText("");
                }

The above code changes the text in all three of our JTextFields to nothing, in essence it is overwriting the existing Text with a blank.

Making the Add Button Work

The Add button will perform three actions.

  1. It is going to accept user input from jTextField1 and jTextField2 and convert the input from a type String to a float.
  2. It will then perform addition of the two numbers and finally,
  3. it will convert the sum to a type String and place it in jTextField3.

Lets get started!

  1. Click the Design tab at the top of your work area to go back to the Form Design.
  2. Right-click the Add button (jButton2). From the pop-up menu, select Events > Action > actionPerformed
  3. We are going to add some code to have our Add button work. The finished source code shall look like this:
4.           private void jButton2ActionPerformed(java.awt.event.ActionEvent evt){
5.               // First we define float variables.
6.               float num1, num2, result;
7.               // We have to parse the text to a type float.
8.               num1 = Float.parseFloat(jTextField1.getText());
9.               num2 = Float.parseFloat(jTextField2.getText());
10.           // Now we can perform the addition.
11.           result = num1+num2;
12.           // We will now pass the value of result to jTextField3.
13.           // At the same time, we are going to
14.           // change the value of result from a float to a string.
15.           jTextField3.setText(String.valueOf(result));
                    }

Our program is now complete we can now build and run it to see it in action.

Exercise 4: Running the Program

To run the program in the IDE:

  1. Choose Run > Run Main Project
  2. If you get a window informing you that Project NumberAddition does not have a main class set, then you should select my.NumberAddition.NumberAdditionUI as the main class in the same window and click the OK button.

To run the program outside of the IDE:

  1. Choose Run > Clean and Build Main Project (Shift-F11) to build the application JAR file.
  2. Using your system’s file explorer or file manager, navigate to the NumberAddition/dist directory.
  3. Double-click the NumberAddition.jar file.

After a few seconds, the application should start.

Note: If double-clicking the JAR file does not launch the application, see this article for information on setting JAR file associations in your operating system.

You can also launch the application from the command line.

To launch the application from the command line:

  1. On your system, open up a command prompt or terminal window.
  2. In the command prompt, change directories to the NumberAddition/dist directory.
  3. At the command line, type the following statement:
java -jar  NumberAddition.jar

How Event Handling Works

This tutorial has showed how to respond to a simple button event. There are many more events you can have your application respond to. The IDE can help you find the list of available events your GUI components can handle:

  1. Go back to the file NumberAdditionUI.java in the Editor. Click the Design tab to see the GUI’s layout in the GUI Builder.
  2. Right-click any GUI component, and select Events from the pop-up menu. For now, just browse the menu to see what’s there, you don’t need to select anything.
  3. Alternatively, you can select Properties from the Window menu. In the Properties window, click the Events tab. In the Events tab, you can view and edit events handlers associated with the currently active GUI component.
  4. You can have your application respond to key presses, single, double and triple mouse clicks, mouse motion, window size and focus changes. You can generate event handlers for all of them from the Events menu. The most common event you will use is an Action event. (Learn best practices for Event handling from Sun’s Java Events Tutorial.)

How does event handling work? Everytime you select an event from the Event menu, the IDE automatically creates a so-called event listener for you, and hooks it up to your component. Go through the following steps to see how event handling works.

  1. Go back to the file NumberAdditionUI.java in the Editor. Click the Source tab to see the GUI’s source.
  2. Scroll down and note the methods jButton1ActionPerformed()jButton2ActionPerformed(), andjButton3ActionPerformed() that you just implemented. These methods are called event handlers.
  3. Now scroll to a method called initComponents(). If you do not see this method, look for a line that says Generated Code; click the + sign next to it to expand the collapsed initComponents() method.
  4. First, note the blue block around the initComponents() method. This code was auto-generated by the IDE and you cannot edit it.
  5. Now, browse through the initComponents() method. Among other things, it contains the code that initializes and places your GUI components on the form. This code is generated and updated automatically while you place and edit components in the Design view.
  6. In initComponents(), scroll down to where it says
7.           jButton3.setText("Exit");
8.           jButton3.addActionListener(new java.awt.event.ActionListener() {
9.               public void actionPerformed(java.awt.event.ActionEvent evt) {
10.                  jButton3ActionPerformed(evt);
11.           }
            });

This is the spot where an event listener object is added to the GUI component; in this case, you register an ActionListener to the jButton3. The ActionListener interface has an actionPerformed method taking ActionEvent object which is implemented simply by calling your jButton3ActionPerformed event handler. The button is now listening to action events. Everytime it is pressed an ActionEvent is generated and passed to the listener’s actionPerformed method which in turn executes code that you provided in the event handler for this event.

Generally speaking, to be able to respond, each interactive GUI component needs to register to an event listener and needs to implement an event handler. As you can see, NetBeans IDE handles hooking up the event listener for you, so you can concentrate on implementing the actual business logic that should be triggered by the event.

 

PROTECTION OF MODERN MICROCONTROLLERS

INTRODUCTION

A lot of microcontrollers are used in modern equipment and electronic devices. Some of them are used by amateurs to build small devices for fun, others are used by small companies in control, measurement or other equipment, others are used for serious applications by the military, security services, banks, medical services etc. Each microcontroller executes the algorithm or program uploaded into its memory. Usually this algorithm is written in Assembler (even if you write the program in C it will be translated into Assembler during compilation); rarely the algorithm is written in Basic or Java.

If you write a program for a microcontroller you are interested in your work being protected against unauthorized access or copying, so you want to control distribution of your devices. For this purpose microcontroller manufacturers developed special features which if selected allows software authors to prevent people downloading their program from their microcontroller if activated. This is Copy protection or Lock feature. Each microcontroller should be programmed before using. There are different techniques to do it depend on manufacturer and type of microcontroller. For evaluation purposes there are reprogrammable versions of microcontrollers, for production in small quantities there are one-time programmable (OTP) versions which is cheaper than reprogrammable one, and for large amount there are factory programmed versions which are very cheap but you have to purchase at least 1000 items. After the program for microcontroller is written and successfully compiled it should be uploaded into correspondent microcontroller integrated circuit. For this purpose you have to use special hardware device called programmer unit. For most microcontrollers this device could be very simple, cheap and consist of a power supply adapter, a few transistors, several resistors and a connector to RS232 or Parallel port. For other microcontrollers you have to use special programmer units distributed only by manufacturers, but these microcontrollers are not popular. Of course, if you want your device to be working properly for years (especially for OTP versions of microcontrollers) it would be better to use industrial programmer units which are approved by the most of manufacturers. You can find all necessary information about this devices on manufacturers’ web-sites in the Internet.

Attack Technologies

1. Introduction

An increasing number of large and important systems, from pay-TV through GSM mobile phones and prepayment gas meters to smartcard electronic wallets, rely to a greater or lesser extent on the tamper resistance properties of microcontrollers, smartcards and other special security processors.

This tamper resistance is not absolute: an opponent with access to semiconductor test equipment can retrieve key material from a chip by direct observation and manipulation of the chip’s components. It is generally believed that, given sufficient investment, any chip-sized tamper resistant device can be penetrated in this way.

So the level of tamper resistance offered by any particular product can be measured by the time and cost penalty that the protective mechanisms impose on the attacker. Estimating these penalties is clearly an important problem, but is one to which security researches, evaluators and engineers have paid less attention than perhaps it deserves.

We can distinguish four major attack categories:

Microprobing techniques can be used to access the chip surface directly, thus we can observe, manipulate, and interfere with integrated circuit
Software attack use normal communication interface of the processor and exploit security vulnerabilities found in the protocols, cryptographic algorithms, or their implementation
Eavesdropping techniques monitor, with high time resolution, the analog characteristics of all supply and interface connections and any other electromagnetic radiation by the processor during normal operation
Fault generation techniques use abnormal environmental conditions to generate malfunctions in the processor that provide additional access
All microprobing techniques are invasive attacks. They require hours or weeks in specialized laboratory and in the process they destroy the packaging. The other three are non-invasive attacks. The attacked card is not physically harmed during these attacks and the equipment used in the attack can usually be disguised as a normal smartcard reader.

Non-invasive attacks are particularly dangerous in some applications for two reasons. Firstly, the owner of the compromised card might not notice that the secret keys have been stolen, therefore it is unlikely that the validity of the compromised keys will be revoked before they are abused. Secondly, non-invasive attacks often scale well, as the necessary equipment can usually be reproduced and updated at low cost.

The design of most non-invasive attacks requires detailed knowledge of both the processor and software. On the other hand, invasive microprobing attacks require very little initial knowledge and usually work with a similar set of techniques on a wide range of products. Attacks therefore often start with invasive reverse engineering, the result of which then help to develop cheaper and faster non-invasive attacks.

2. Non-Invasive attacks

The most widely used non-invasive attacks include playing around supply voltage and clock signal. Under-voltage and over-voltage attacks could be used to disable protection circuit or force processor to do wrong operation. For these reasons, some security processors have voltage detection circuit, but as a rule this circuit does not react to transients. So fast signals of various kinds may reset the protection without destroying the protected information.

Power and clock transients can also be used in some processors to affect the decoding and execution of individual instructions. Every transistor and its connection paths act like an RC element with a characteristic time delay; the maximum usable clock frequency of a processor is determined by the maximum delay among its elements. Similarly, every flip-flop has a characteristic time window (of a few picoseconds) during which it samples its input voltage and changes its output accordingly. This window can be anywhere inside the specified setup cycle of the flip-flop, but is quite fixed for an individual device at a given voltage and temperature. So if we apply a clock glitch (a clock pulse much shorter than normal) or a power glitch (a rapid transient in supply voltage), this will affect only some transistors in the chip. By varying the parameters, the CPU can be made to execute a number of completely different wrong instructions, sometimes including instructions that are not even supported by the microcode. Although we do not know in advance which glitch will cause which wrong instruction in which chip, it can be fairly simple to conduct a systematic search.

Another possible way of attack is current analysis. Using 10 – 15 ohm resistor in the power supply, we can measure with an analog/digital converter the fluctuations in the current consumed by the card. Preferably, the recording should be made with at least 12-bit resolution and the sampling frequency should be an integer multiple of the card clock frequency.

Drivers on the address and data bus often consist of up to a dozen parallel inverters per bit, each driving a large capacitive load. They cause a significant power-supply short circuit during any transition. Changing a single bus line from 0 to 1 or vice versa can contribute in the order of 0.5 – 1 mA to the total current at the right time after the clock edge, such that a 12-bit ADC is sufficient to estimate the number of bus bits that change at a time. SRAM write operations often generate the strongest signals. By averaging the current measurements of many repeated identical transactions, we can even identify smaller signals that are not transmitted over the bus. Signals such as carry bit states are of special interest, because many cryptographic key scheduling algorithms use shift operations that single out individual key bits in the carry flag. Even if the status-bit changes cannot be measured directly, they often cause changes in the instruction sequencer or microcode execution, which then cause a clear change in the power consumption.

The various instructions cause different levels of activity in the instruction decoder and arithmetic units and can often be quite clearly distinguished, such that parts of algorithms can be reconstructed. Various units of the processor have their switching transients at different times relative to the clock edges and can be separated in high-frequency measurements.

Other possible threat to secure devices is data remanence. This is the capability of volatile memory to retain information stored in it for some period of time after power was disconnected. Static RAM contained the same key for a long period of time could reveal it on next power on. Other possible way is to ‘freeze’ state of the memory cell by applying low temperature to the device. In this case static RAM could retain information for several minutes at -20ºC or even hours at lower temperature.

3. Invasive attacks

Despite to more complexity of invasive attacks some of them could be done without using expensive laboratory equipment. Low-budget attackers are likely to get a cheaper solution on the second-hand market for semiconductor test equipment. With patience and skill it should not be too difficult to assemble all the required tools for even under ten thousand US dollars by buying a second-hand microscope and using self-designed micropositioners. The laser is not essential for first results, because vibrations in the probing needle can also be used to break holes into passivation.

Invasive attacks start with the removal of the chip package. Plastic over the chip could be removed by knife. Epoxy resin around the chip could be removed using fuming nitric acid. Hot fuming nitric acid dissolves the package without affecting the chip. The procedure should preferably be carried out under very dry conditions, as the presence of water could corrode exposed aluminium interconnects. The chip is then washed with acetone in an ultrasonic bath, followed optionally by a short bath in deionized water and isopropanol. After that chip could be glued into a test package and bonded manually. Having enough experience it might be possible to remove epoxy without destroying bonding wires and smartcard contacts.

Once the chip is opened it is possible to perform probing or modifying attacks. The most important tool for invasive attacks is a microprobing workstation. Its major component is a special optical microscope with a working distance of at least 8 mm between the chip surface and the objective lens. On a stable platform around a socket for the test package, we install several micropositioners , which allow us to move a probe arm with submicrometer precision over a chip surface. On this arm, we install a probe needle. These elastic probe hairs allow us to establish electrical contact with on-chip bus lines without damaging them.

On the depackaged chip, the top-layer aluminium interconnect lines are still covered by a passivation layer (usually silicon oxide or nitride), which protects the chip from the environment and ion migration. On top of this, we might also find a polyimide layer that was not entirely removed by HNO3 but which can be dissolved with ethylendiamine. We have to remove the passivation layer before the probes can establish contact. The most convenient depassivation technique is the use of a laser cutter. The UV or green laser is mounted on the camera port of the microscope and fires laser pulses through the microscope onto rectangular areas of the chip with micrometer precision. Carefully dosed laser flashes remove patches of the passivation layer. The resulting hole in the passivation layer can be made so small that only a single bus line is exposed. This prevents accidental contacts with neighboring lines and the hole also stabilizes the position of the probe and makes it less sensitive to vibrations and temperature changes.

It is usually not practical to read the information stored on a security processor directly out of each single memory cell, except for ROM. The stored data has to be accessed via the memory bus where all data is available at a single location. Microprobing is used to observe the entire bus and record the values in memory as they are accessed.

It is difficult to observe all (usually over 20) data and address bus lines at the same time. Various techniques can be used to get around this problem. For instance we can repeat the same transaction many times and use only two to four probes to observe various subsets of the bus lines. As long as the processor performs the same sequence of memory accesses each time, we can combine the recorded bus subset signals into a complete bus trace. Overlapping bus lines in the various recordings help us to synchronize them before they are combined.

In order to read all memory cells without the help of the card software, we have to abuse a CPU component as an address counter to access all memory cells for us. The program counter is already incremented automatically during every instruction cycle and used to read the next address, which makes it perfectly suited to serve us as an address sequence generator. We only have to prevent the processor from executing jump, call, or return instructions, which would disturb the program counter in its normal read sequence. Tiny modifications of the instruction decoder or program counter circuit, which can easily be performed by opening the right metal interconnect with a laser, often have the desired effect.

Another approach to understand how particular microcontroller or smartcard work is to reverse engineer it. The first step is to create a map of a new processor. It could be done by using an optical microscope with a CCD camera to produce several meter large mosaics of high-resolution photographs of the chip surface. Basic architecture structures, such as data and address bus lines, can be identified quite quickly by studying connectivity patterns and by tracing metal lines that cross clearly visible module boundaries (ROM, RAM, EEPROM, ALU, instruction decoder, etc.). All processing modules are usually connected to the main bus via easily recognizable latches and bus drivers. The attacker obviously has to be well familiar with CMOS VLSI design techniques and microcontroller architectures, but the necessary knowledge is easily available from numerous textbooks.

Photographs of the chip surface show the top metal layer, which is not transparent and therefore obscures the view on many structures below. Unless the oxide layers have been planarized, lower layers can still be recognized through the height variations that they cause in the covering layers. Deeper layers can only be recognized in a second series of photographs after the metal layers have been stripped off, which could be achieved by submerging the chip for a few seconds in hydrofluoric acid (HF) in an ultrasonic bath. HF quickly dissolves the silicon oxide around the metal tracks and detaches them from the chip surface. HF is an extremely dangerous substance and safety precautions have to be followed carefully when handling it.

Where the implementation is familiar, there are a number of ways to extract information from the chip by targeting specific gates or fuses or by overwriting specific memory locations. Even where this is not possible, memory cells can be attacked; this can also be done on a relatively modest budget.

Most currently available microcontrollers and smartcard processors have feature sizes of 0.5 – 1 µm and only two metal layers. These can be reverse-engineered and observed with the manual and optical techniques described in the previous sections. For future chip generations with more metal layers and features below the wavelength of visible light, more expensive tools additionally might have to be used.

A focused ion beam (FIB) workstation consists of a vacuum chamber with a particle gun, comparable to a scanning electron microscope (SEM). Gallium ions are accelerated and focused from a liquid metal cathode with 30 kV into a beam of down to 5 – 10 nm diameter, with beam currents ranging from 1 pA to 10 nA. FIBs can image samples from secondary particles similar to a SEM with down to 5 nm resolution. By increasing the beam current, chip material can be removed with the same resolution. Better etch rates can be achieved by injecting a gas like iodine via a needle that is brought to within a few hundred micrometers from the beam target. Gas molecules settle down on the chip surface and react with removed material to form a volatile compound that can be pumped away and is not redeposited. Using this gas-assisted etch technique, holes that are up to 12 times deeper than wide can be created at arbitrary angles to get access to deep metal layers without damaging nearby structures. By injecting a platinum-based organometallic gas that is broken down on the chip surface by the ion beam, platinum can be deposited to establish new contacts. With other gas chemistries, even insulators can be deposited to establish surface contacts to deep metal without contacting any covering layers.

Using laser interferometer stages, a FIB operator can navigate blindly on a chip surface with 0.15 µm precision, even if the chip has been planarized and has no recognizable surface structures. Chips can also be polished from the back side down to a thickness of just a few tens of micrometers. Using laser interferometer navigation or infrared laser imaging, it is then possible to locate individual transistors and contact them through the silicon substrate by FIB editing a suitable hole. This rear-access technique has probably not yet been used by pirates so far, but the technique is about to become much more commonly available and therefore has to be taken into account by designers of new security chips. FIBs are used by attackers today primarily to simplify manual probing of deep metal and polysilicon lines. A hole is drilled to the signal line of interest, filled with platinum to bring the signal to the surface, where a several micrometer large probing pad or cross is created to allow easy access. Modern FIB workstations (for example the FIB 200xP from FEI) cost less than half a million US$ and are available in over hundred organizations. Processing time can be rented from numerous companies all over the world for a few hundred dollars per hour.

References

[1] Ross J. Anderson, Markus G. Kuhn: Tamper Resistance – a Cautionary Note, The Second USENIX Workshop on Electronic Commerce, Oakland, California, November 18-21, 1996

[2] Ross J. Anderson, Markus G. Kuhn: Low Cost Attacks on Tamper Resistant Devices, in M.Lomas et al. (ed.), Security Protocols, 5th International Workshop, Paris, France, April 7-9, 1997

[3] Oliver K�mmerling, Markus G. Kuhn: Design Principles for Tamper-Resistant Smartcard Processors, USENIX Workshop on Smartcard Technology, Chicago, Illinois, USA, May 10-11, 1999

Microcontrollers Overview

Firstly, let’s separate all microcontrollers into two types – ordinary and secure microcontrollers. Secure microcontrollers are designed for security applications (the military, banks, medical service etc.) and used in Smartcards or security modules. They provide different modes of operation, different access levels, encryption of data communication not only outside the chip but also inside it by using bus encryption, signals hiding etc. Attacks on this microcontrollers require very sophisticated and expensive equipment, very high skill of knowledge and should be discussed separately. Ordinary microcontrollers as a rule also have security protection against reading out the program and/or data (in case of microcontrollers with Data memory) but developers should be aware that sometimes this protection is very weak. Before discussing possible ways of attacks on ordinary microcontrollers it would be better to divide them into different classes by type of memory. Next table shows differences between microcontrollers with different type of program memory and also advantages and disadvantages of each type.

Type of program memory Programming method Possibility to update program code Memory access time (CPU core speed) Programming speed/
Time to erase Data retention Price of microcontroller/
programmer unit
Mask ROM
(ROM) Factory programmed
(min order – 1000 items) No possibility 10 ns (100MHz) 2 – 4 weeks/
N/A Unlimited Min/Not used
One Time Programmable ROM
(OTP ROM) Using Programmer Unit No possibility 100 ns (10MHz) 50 words/sec/
N/A 10 years Med/Med
Ultra-Violet Erasable Programmable ROM
(UV EPROM) Using Programmer Unit or InCircuit Programming Up to 100 times 100 ns (10MHz) 50 words/sec/
10-30 minutes 10 years High/Med
Electrically Erasable Programmable ROM
(EEPROM) Using Programmer Unit or InCircuit Programming Up to 10,000 times 200 ns (5MHz) 100 words/sec/
10 ms 40 years High/Low
Flash Erasable Programmable ROM
(Flash EPROM) Using Programmer Unit or InCircuit Programming Up to 100,000 times 100 ns (10MHz) 500 words/sec/
5 ms 100 years High/Low
Ferroelectric RAM
(FRAM) Using Programmer Unit or InCircuit Programming Up to 10¹² times 200 ns (5MHz) 2 Mbytes/sec/
Not necessary 40 years High/Low
Static RAM
(SRAM) InCircuit Programming Unlimited 20 ns (50MHz) 20 Mbytes/sec/
Not necessary 5 years (battery life) High/Low
There are two ways of attacks on microcontrollers – invasive and non-invasive. The first one involves depackaging of the chip followed by exposing certain part of the chip to laser or ion beam, or/and probing under microscope on probing station. Non-invasive attacks include playing around the signals applied to the chip to obtain all necessary information.

If microcontroller has a Mask ROM then as a rule any access is denied by the manufacturer at the stage of production. Meanwhile there might be the way to overcome it if there is some kind of test monitor program on the chip to test the Mask ROM after production. Generally it is very difficult to find it and the fastest way to extract the program is to depackage the chip and read out memory contents optically. Sometimes to increase security manufacturers use transistors with different threshold voltage instead of using presence or absence of a transistor to create cells with 0’s and 1’s. This kind of ROM cannot be read optically. In this case memory contents could be read using microprobing techniques or using selective chemical etching.

If microcontroller has an OTP ROM then end-user can select code protection facility during programming. If it was enabled then it is still possible to apply both invasive and non-invasive attacks. Invasive attacks as a rule include exposing certain part of the chip into Ultra-Violet light, cutting lock lines by laser or restoring security fuses on probing station. Non-Invasive attacks include applying different signals to make internal protection scheme “forget” about protection.

In case of microcontrollers with UV EPROM situation is the same as with OTP ones, because usually they have absolutely the same structure and difference is only in their package.

If microcontroller has an EEPROM memory it is more stable for invasive attacks, because it is very difficult to handle with electrical charge rather than with transistors. Although the same attacks as for OTP microcontrollers could be applied. It is still possible to probe bus lines inside the chip but it requires high skill of attacker. In the same time, non-invasive attacks could be applied very easily. It takes place because EEPROM cell has very specific behavior and very sensible to control signals and to timings of the control signals. That allows the attacker to find ways of overcoming security protection either by selective erasing of the security fuses or by causing the security control scheme get wrong state of the security fuses.

Situation with Flash EPROM microcontrollers practically the same as with EEPROM microcontrollers. Sometimes their security could be easily broken, sometimes harder but the situation still bad. So, there are ways to break the security in almost any Flash and EEPROM microcontroller.

Recently introduced FRAM microcontrollers seems to be more secure due to specific structure of the memory. Although it is still possible to apply microprobing in order to obtain contents of the memory.

Microcontrollers with SRAM quite stable to invasive attacks because any tampering into the device will cause disconnection of the power supply from SRAM with following vanishing of the information. But due to some bugs in hardware and software implementation there is possibility to apply non-invasive attacks on such microcontrollers. For example, secure microcontroller chip DS5002FP from the Dallas Semiconductor is one of the processors for which a way to bypass the security bit was found. You can find explanation of this attack in the next paper:
Markus G. Kuhn: Cipher Instruction Search Attack on the Bus-Encryption Security Microcontroller DS5002FP. IEEE Transactions on Computers, Vol. 47, No. 10, October 1998, pp. 1153-1157.

The most serious threat for microcontrollers with security protection is non-invasive attacks, because in general they are cheaper than invasive. If you can write your own program or legally buy preprogrammed version of microcontroller you will find it cheaper than doing invasive attacks. Meantime, some kind of invasive attacks might be reasonably cheap. For example, if the security bits are vulnerable to UV light. So, designing something using microcontroller you have to assess your work and choose microcontroller with appropriate protection. It is not possible to get perfect protection but you can make hacking of your device to be useless due to high price of attack.

Non-Invasive Attacks on Microcontrollers

I have been investigating into copy protection mechanisms in different microcontrollers since 1996. PIC16F84 was one of the first microcontrollers I have unprotected. Occasionally I do some research in this area and provide testing of new microcontrollers and renew testing of old.

Now let me introduce what sort of equipment I have been using for non-invasive attacks on microcontrollers. I built my own designed programmer device controlled by my software program. It operates on IBM PC under MS-DOS or Windows 95/98 and it was written in C++. Hardware of my programmer allows me to rapidly change power supply and programming voltages in wide range causing different power glitches. This is quite essential if you provide attacks on microcontrollers. Signal block of the programmer generates 32 output digital signals with adjustable logic levels and some of them has open-drain output. Also this block inputs 16 signals at correct logic levels. This is quite enough for most of microcontrollers. Another part of the programmer is the board with different IC sockets for most of microcontrollers I have tested. For some microcontrollers I use additional socket adapters.

Here is some pictures of my device.

The next table shows all microcontrollers I have already tested and found them vulnerable for non-invasive attacks.
Microcontroller Features Attack method Comments
Motorola HC05

MC68HC05B6
MC68HC05B8
MC68HC05B16
(MC68HC05B32)
(MC68HC05X4)
MC68HC05X16
MC68HC05X32 Mask ROM
Data EEPROM
EEPROMed Security bit shared with Data memory Power Glitch or
Clock Glitch Have Write Protection against accidental Erase of Data memory
Motorola HC11

MC68HC11A8
MC68HC11E9
(MC68HC11E20)
MC68HC11L6
(MC68HC11KA2)
(MC68HC11KA4)
(MC68HC11KG2)
(MC68HC11KG4) Mask ROM
Data EEPROM
EEPROMed Security bit Power Glitch Bootloader with autoerasing of the Data memory if Security is enabled
Microchip PIC

PIC16C84 Program EEPROM
Data EEPROM
EEPROMed Security bit Power Overstress or
Power Glitch Chip Erase mode erases CP bits with Program and Data memories
Microchip PIC

PIC16F83
PIC16F84
HCS512 Program Flash EPROM
Data EEPROM
EEPROMed Security Bit Power Glitch Chip Erase mode erases CP bits with Program and Data memories
Microchip PIC

PIC16F84A
PIC16F627
PIC16F628
(PIC16F870)
(PIC16F871)
(PIC16F872)
PIC16F873
PIC16F874
PIC16F876
PIC16F877 Program Flash EPROM
Data EEPROM
EEPROMed Security Bits Power Glitch Chip Erase mode erases CP bits with Program and Data memories
Have improved protection mechanism
Atmel 8051

AT89C51
AT89C52
AT89C55
AT89C1051
AT89C2051
(AT89C4051) Program Flash EPROM
EEPROMed Security Bits Power Glitch Chip Erase mode erases Lock bits with Program memory
Atmel AVR

AT90S1200
AT90S2313
AT90S2323
(AT90S2343)
AT90S8515 Program Flash EPROM
Data EEPROM
EEPROMed Security Bits Power Glitch Chip Erase mode erases Lock bits with Program and Data memories
NEC 78K/0S

(uPD78F9026)
(uPD78F9046)
uPD78F9116
(uPD78F9136) Program Flash EPROM
No Memory Read Function Power Glitch Chip Erase mode erases Program memory
Texas Instruments MSP430

MSP430F110
MSP430F112
MSP430F1101
MSP430F1121
MSP430F122
MSP430F123
MSP430F133
MSP430F135
MSP430F147
MSP430F148
MSP430F149
MSP430F412
MSP430F413 Program Flash EPROM
Data Flash EPROM
EEPROMed Password Clock Glitch Mass Erase mode erases Password with Program and Data memories
Microcontroller in brackets means it has not been tested yet but expecting the same behaviour
Presense of a microcontroller in this table only means that it has some vulnerabilities to non-invasive attacks. It might be possible that newer versions of the same microcontroller do not have such security problems
For some microcontrollers I know a few methods to overcome protection. Some of them give very reliable results, another has less than 20% of success (these methods sometimes appear in the Internet and, moreover, using these methods you could not only burn the chip but programmer unit too).

Invasive Attacks on Microcontrollers

WARNING! I do not carry any responsibility for using further information in order to break your microcontroller. It is only brief short explanation of my experiments. If you are trying to repeat this work you are doing it on your own risk!

1. Introduction

It is commonly believed that invasive attacks are very complicated and require a lot of sophisticated equipment. It is not the case. Of course invasive attacks should cost more than non-invasive because involve depackaging of the chip and applying different physical methods. But sometimes they could be done quite easily without using expensive laboratory equipment. It reveals a huge threat to a device based on microcontroller which was assumed to be strong to non-invasive attacks but nothing related with invasive attacks was evaluated.

Let me break the myth which says that the minimum cost of invasive attack is ten thousand US$, therefore if microcontroller you use is not vulnerable to non-invasive attack you have proper protection against copying of your code. The aim is to make developers to be aware that proper evaluation should be performed before using certain microcontroller.

Let me show how PIC12C508A device could be broken and then you can estimate how difficult it is and how much could it cost. Then I will introduce an attack on PIC16F874 which requires more equipment but could be done using only microscope with probing needle.

2. Attack on PIC12C508A

Firstly we have to depackage the chip. It could be done in two ways: dissolving everything around the chip or removing plastic only above the silicon die. The last one is more intelligent but requires some level of knowledge and experience, while the first way will force you to bond the chip on a test package and it is not possible to carry out it without having access to a bonding station.

So the only convenient way for us is to remove plastic above the chip die. It is possible to do this using fuming nitric acid which dissolves epoxy plastic (material of the package) without affecting the chip and bonding wires. Exhausted acid should be removed by an acetone followed by cleaning the sample in an ultrasonic bath, wash in water to remove remain salts and drying. If you do not have an ultrasonic bath you can skip this operation. In this case the chip surface will remain slightly dirty but it still be transparent to UV light. Meanwhile the ultrasonic bath could be easily built using simple frequency generator connected to ferrite antenna coil and appropriate metal dish for bath.

Here is some pictures of this process.

Next stage is to expose protection fuses to UV light. In order to do this you have to find where they are. If you have a microscope with at least 100x magnification you can easily find them just tracing the wire from the pin for programming voltage input. If you do not have a microscope you can do simple search exposing different part of the chip to UV light and observing the result. Once you have found them you can apply it to protected chip. You should use opaque paper in order to protect Program memory from UV light. Five to ten minutes under UV light should give you proper result and you would be able to read Program memory using any available programmer unit.

Another possible attack requires additional equipment like microscope and laser cutter/thin needle. Once you have found protection fuse you can find all signal lines coming to this part of circuit. Due to design mistake it is possible to disable copy protection just by cutting one line from protection fuse to rest of the circuit. For unknown reason this line is sufficiently far away from other lines. That makes possible to cut this line not only using expensive laser cutter but also scratching surface above this line by a needle until the wire will be cut.

3. Attack on PIC16F874

First stage – depackaging is absolutely the same as for PIC12C508A.
Because this chip uses shielded EEPROM cells for protection it is not possible to reset protection using a UV light. So we should try to use microprobing technique in order to read the memory contents. Once you have depackaged the chip you should look onto it under a microscope. You can easily find data lines going from memory array to rest of the circuit. For unknown reason copy protection doesn’t lock access to the memory in programming mode so if you put probing needle on top of the data line you will see all necessary data. Restarting read operation in programming mode and connecting probing needle to different data lines you can read all the information from both Program and Data memories.

Threat of Attack and Defense Technologies

Now having information about different attack methods we can divide these attacks by threat to device based on microcontroller.

Non-invasive attacks introduce very high level of threat therefore if microcontroller is vulnerable to such attacks it has minimum level of protection. The only equipment which attacker should have is a special programmer unit. For example, you can find such programmer units for PIC16C84 widely available for sale in the Internet for quite reasonable price.

Cheap invasive attacks also reveal big problem to designers. These attacks could be implemented by practically any person familiar with school chemistry course. All necessary equipment could be bought for 100 to 300 US$. And microcontrollers vulnerable to such attacks could not be enough secure.

Such invasive attacks as microprobing could be used only by well funded attackers. It makes microcontrollers vulnerable only to these attacks to be enough secured. But also, if you calculate price of equipment and time to break one microcontroller you will get price of attack not exceeding one thousand US$. So you cannot use such microcontrollers in expensive project where protection is the necessary requirement.

Reverse engineering is the most expensive invasive attack could be used. It gives all the necessary information about chip schematics and structure of protection circuit. But it takes long time and require very expensive equipment. So if microcontroller could not be broken by any of above mentioned attacks it should be good secured. Although maybe it was not broken due to mistake of attacker and other attacker could break it quite easily.

Now we get very awful situation where practically any standard microcontroller could be broken using one of the first three attack methods. Usually it is not possible to redesign project for secure microcontroller which can withstand practically any attack because of high price of such microcontrollers and incompatibility with ordinary microcontrollers. Usually secure microcontrollers are designed for smartcard applications where used only two pins for serial digital interface. Of course, you can use secure microcontroller to protect the project but if attacker interested only in certain part of the algorithm implemented in normal microcontroller he can extract it without a problem.

Another approach is to use hardware protection based on a programmable logic array (PAL, CPLD, EPLD) which usually has better protection and even if you break it you will spend a lot of time to understand how it works.

But why not to use undocumented features of the same microcontroller. If you are using OTP, UV EPROM, EEPROM or Flash microcontroller it is possible to use certain cells of its memory for protection. The idea behind this is the next. All these memories are analog memory, so each cell inside the array keeps charge instead of logic state. When memory cell is read this charge is translated into a logic signal by sense amplifier. If you charge cell to intermediate state corresponds to threshold value of sense amplifier then because of presence of a noise you will read different value from the same cell. This feature could be used as additional protection to ordinary security feature of a microcontroller.

Another possible way of increasing protection is to destroy possibility of further programming. It could be done mechanically by cutting certain pins or electrically by applying high voltage to these pins to blow up bonding wire. Although it does not provide any protection against invasive attacks.

More intelligent way is to destroy certain part of the control circuit dedicated for programming mode. Although in order to do such a thing you should reverse engineer certain part of the chip or apply microprobing technique to learn how it works. But sometimes it might cost more than the value of your project.

Further Research

The other interesting way of research is evaluation of the security in Programmable Logic Arrays (PLA) and Programmable Logic Devices (PLD). They also have security protection feature but it was not tested by the same methods like microcontrollers. Sometimes this devices are used for complex projects in parallel to FPGA chips but only to prevent unauthorised copying because FPGA chip does not have any protection facility due to external loading of configuration. In this case attacks on EEPROMed PLA/PLD also could be serious threat for such devices.

Currently I am trying to sum up the results, make another experiments and prepare the article.

If you are interested in your sample chips to be tested and evaluated we could discuss possible ways of collaboration. Beforehand I want to mention that I am not a commercial company specializing in breaking security in microcontrollers. I am just providing research work and consulting.

The details of my research into microcontrollers security and all the results are confidential until they will be published or disclosed in my PhD thesis. Usually I provide some information and doing specific research only for companies who supports my research or gives me necessary equipment to continue my research into hardware security. It could be done as a sponsoring, giving certain grant or as a consulting.

I’ve spent a huge amount of time and correspondently money doing such research and as I want to publish it in the future I’ll keep it under the secret. At the same time I am opened to any possible contract for building special programmer for testing purposes without sharing all the information.

I always reply to personal emails. But sometimes due to server problems mail could be losted. Therefore please resend me your message if I have not replied within one week. In case of important messages I would prefer you to forward copy of your letter to my Hushmail account.

Java Compiler for microcontrollers

It’s Java source to C source translator, which allows to write MCU firmware in Java.

“yes”  

Key features

  • Source code is written in Java, not C.
  • Source code is translated to C source code, which is compiled and programmed to target device. MCU doesn’t interpret anything.
  • No manual register handling needed! Write, for example, timer.setMode(TimerMode.FAST); instead of inconvenient TCCR1B |= (1<<WGM12); TCCR1A |= (1<<WGM10); Register handling is done automatically by MCU Java Source. Now you need to keep in mind only the principle of operation of MCU devices (timers, UART, ADC), but not registers and bits.
  • MCU register initialization on startup is done separately in init() function and is highly optimized.
  • MCU internal devices (e.g. timers) are represented as Java objects.
  • Interrupts are represented as object’s listeners (e.g. ExternalInterruptListener, TimerCompareListener). Of course, methods addXxxListener() also work.
  • UART uses input and output streams, as usual in Java.
  • User objects
  • Handy documentation (Javadoc) for all available objects and methods (functions).
  • Before translation source code is compiled by Java compiler. This prevents many errors.
  • For highly device-optimized applications, it is possible to work with register directly through Register class, unless there is another way to do needed action.
  • New MCUs and even platforms can be added, if C compiler supporting it exists.

What it is and is not MCU Java Source is:

  • Tool that allows to write MCU programs in Java.

MCU Java Source is not:

  • JVM (Java Virtual Machine) for MCU. All java code is translated to native at source level, then compiled to machine code.
  • Tool for AVR32 with hardware JVM. This program is not for high-end MCU’s.

Supported MCU platforms/devices

AVR Compiler – avr-gcc (or WinAVR package)

  • ATmega8
  • more will be added

Java source code elements

Supported (implemented) now

  • final. Primitive fields with final attribute turn to #define declarations. Strings and primitive arrays are put to program memory and got from it when they are used. No manual working with progmem – just make a field final!
  • Listeners. Only interrupt listeners are supported. Interrupt listeners turn to interrupt service routines.
  • Variables/fields. Only primitive (and primitive array) variables are passed to C source, MCU Java source object handling is interpreted by translator, user object are not supported now.
  • volatile is passed to C source. Use it when variable is used in background thread and interrupt.
  • byte and boolean types are supported throught typedef unsigned char.
  • I/O. InputStream and OutputStream classes are used in UART. Since charset enconders/decoders don’t fit into MCU, only default charset is used. That’s why there’s no BufferedReader, BufferedWriter classes, instead BufferedInputStream, BufferedOutputStream are used.
  • User objects
  • External device library (partially):
    • Multi digit LED display
    • Character LCD
    • Nokia 3310 LCD

Not yet implemented

  • External device library (partially implemented). For example, I2C EEPROM, temperature sensor.
  • Anonymous classes and statement like method(new MyListener())
  • Static initializers and instance initializers will be added to start() function
  • @Section annotation. Will specify, where to put final variables – Flash or EEPROM memory. Now Flash by default. Example:

    @Section(Section.EEMEM)
    private static final String MESSAGE = “Hello, EEPROM!”;

  • Two-threaded model: background thread and interrupt (Event Dispatch) thread. Task (implements Runnable) like in TinyOS 2.0. Tasks will be executed in background thread and posted from anywhere.
  • Simulator: Java source can also be compiled and run on computer. So, program will be simulated.

No way to do it

  • synchronized is completely ignored. Use volatile instead.
  • Exceptions. Native code don’t support them.
  • static is completely ignored because C has different meaning of it.

System requirements

  • Windows or Linux
  • Java 6 JDK

How it works

Java source code is converted to XML representation (java-ml) using modified version of Java2XML. Then every XML element is processed by MCU Java Source Translator. All primitive variables don’t change, all objects are translated. For translation of methods dealing with MCU registers, there is separate translator for each MCU. All listeners are converted to interrupt handlers. Classes of user objects are not processed using XML, they are called using reflection. The result of translation is XML representation of C source code for MCU. Then C source is generated from XML.



 

Fireworks with Microcontroller

At the Arab Museum of Modern Art in Doha, Qatar, Chinese artist Cai Guo-Qiang put on his largest ‘explosion event’ of the last three years, utilizing microchip-controlled explosives to form incredible designs and patterns. The video shot of the event is an impressive testament to how a volatile black powder explosion can be controlled and shaped by computers and microcontroller technology.

 
 

8,300 (206Chex) microcontrollers blast in the air

Computer controlled daytime pyrotechnics show paints the sky

 

 

Each set of explosions was calculated to paint a different picture. One series of explosions created black smoke clouds that looked like “drops of ink splattered across the sky.” In another, 8,300 shells embedded with computer microchips exploded in a pyramid shape over the desert.

Youtube Video link:
http://www.youtube.com/watch?v=FPV8zdiySlI

Low Cost FPGA Board

I was thinking of learning FPGA, although my college lab have plenty of FPGA boards I want to buy one board for my needs. FPGA Boards are very costly. Relative to the microcontrollers FPGA board and the softwares both are 5 times more priced. The sad thing is that in FPGA world there is no free or opensource software for the whole thing. Either you have to use pirated version or Buy a Development board to get a Hardware locked Software Pack. Hardware locked means these pack can be used program only that class of development boards.

Another thing is that if someone want to design a board himself ? is it possible

Yeah its possible, but there is not so much help on the web, But there are some open hardware projects like the XULA Board from Xess Corp.

Xula Board

Xula board uses altera Cyclone IV with 32,000 Logic elements and support for VGA, Now Xula board is produced by some other companies also, available in ebay, digikey…

DE0

DE0 is another lowcost FPGA board for beginners using altera Cyclone IV, people had tried Linux on it. There is two new modified version DE0 Nano and DE4.

Papillio

Papillio is an open hardware project equivalent to Auridino project . The auridino was for microcontrolles and this is for FPGA world. It has equivalent peripheral component blocks like the Auridino Peripheral boards. Papillio hardware is marketed by Digikey, Avnet and other worldwide distributers.

The Basic Architechture

As the FPGA chips have no static memory each time it is powered on the configuration data need to be reloaded by some interface. So the common devlopement board contains a micro controller for this job. Another necessary thing is a interface to computer , if the microcontroller has USB support then it is enough otherwise we need a USB chip like the FTDI. Some Devlopment board vendors also provide a ethrnet interface both for application and Bitstream(configuration data) loading purpose.

 

Board Block Diagram Xula

Am still confused about which one to start with ….

USB to Parallel Port for AVR, FPGA

Parallel port is basic need for hardware engineers involved in Microcontroller, FPGA or DATA Acquisition Projects. But now the PC Assembler companies (Lenevo, Dell) are not giving an parallel port in the system. Few other companies have the port on motherboard not in the back panel. Parallel port is laptop is very rare, I have seen this some of the oldest laptops, (my professor has one like this). The laptops have only USB, HDMI, VGA and RJ45. But they forgot our need the serial port and the Parallel Port.

Parallel Port is the simplest media to interface your project to the computer. Serial is the next simplest interface. But our systems lack both of these ports. So we need some alternative way to get a port on our system. The first option is a USB to parallel convertor or adaptor but these USB adaptors does not work for all purpose but only for printers. They virtualize a printer port. The USB to Serial works good for all purpose.

The PCMIA based parallel port is a real parallel port it works good. But PCMCIA card is not suitable for all. Some laptops don’t allow this.

So here is a option for you.

 

Source: http://www-user.tu-chemnitz.de/~heha/bastelecke/Rund%20um%20den%20PC/USB2LPT/index.html.en

Although I have not tested it but the description seems it will work for all things. Here they Compared with other methods like PCI card , PCMCIA Card based parallel ports with this converter.

Some Pros and Cons of this USB to parallel converter

  • + Emulated true parallel port with ECP/EPP
  •  Reduced speed due to emulation (expect 10..100 times slower)
  • + Base address same as built-in (378h, 278h)
  •  Doesn’t work with programs that expect a true PnP driver stack (scanners, ZIP drives) and software that disables port access redirection (dongles)
  • + Additional USB->ParallelPrinter adapter built-in (High-Speed only)
  • + USB available everywhere
  •  Driver necessary
  •  Driver unstable, tricky, not certified, and currently non-functional for Win64, currently no driver for Linux
  • + open-source, multi-language

Tested in Programmes listed below:

  • AVRdude
  • winPIC
  • AVR ISP
  • PonyProg
  • Xilinx Impact
  • AD9834 Analog devices
  • LabView
  • Matlab
  • And many more things

My days at CSIO

Hi buddies, am now free to write about the khata mitha experience at this institute.

After our 3rd semester was over we were not fully relaxed as there were still some burdens concerning the academics. We had to show the Prototypes of Minor Projects and seminar talk on the same. But my project was still not completed. In the meantime we had to search for a guide for our M.Tech. Thesis. I mailed all my seniors about my need. All of them are continuing SRF, Ph.D., PDF at their respected institutes. They all replied positively but due to some official restrictions I had to leave the choice. Besides this I had also mailed to number of professors from some NIT, IISc, IUAC and TIFR for some specific projects which are suitable for me. They all accepted my proposal but none of them provided accommodation which was necessary for me.I was in search of a senior person as my guide, but not so senior that he would not spare a hour in a week for me. For this I left all the chances.

CSIO, yeah this was the last option for all of us. So at last I decided to join project work at CSIO, as I had seen from a presentation by one of my seniors that there was some work going on E-nose on which I had worked a little.

Leaving H9 NIT Kurukshetra, shifting to Chandigarh

Nine of my classmates applied for CSIO (Me, Yogesh, Anoop, Sharad, Naveen, Gaurav, Manoj Tanwar, Jai, Ramamurthy ), there were two girls from MTech nano stream. We all shifted to a PG Hostel at Chandigarh on 28th dec.

Naveen Arranging Things in the PG Room at Chandigarh, Tiifin supplied by the PG owner

Anyway we got hostel room after some days so we shifted to the hostel. All of us got new roommates except yogesh, manoj and naveen. And then it was time to think about the project and the lab. We are three from NIT are joined for one single project in the agrionics lab(all of us are using different techniques).

U may have seen worst

Anyway we enjoyed a lot, Visited Jammu, Kasauli.. celebrated holi.. and …

 

ARM Microprocessors and Microcontroller

“ARM” you must have heard about this fastest growing family of Microprocessor architecture. Every modern handset uses at least one ARM processor. In daily life you must have using 4/5 of these processors in bike/car, elevator, shop..and many more. As an embedded engineer 8bit or 16bit processors are not enough we have to learn the ARM 32 and there is another reason that we should work on the current technology which would pay us.

Now after completion of thesis (yet not M.Tech.) am jobless so trying to explore the ARM architecture. Writing this blog as a discussion / tutorial, if you wish you may co-author this. I will explain as I have proceeded yet through the domain.

Content

  • History
  • ARM Cores
  • ARM Manufactures and Products
  • Compilers and assemblers
  • “Hello World” on a ARM
  • Tutorials, Links, Forums

ARM is the leading provider of 32-bit embedded microprocessors, offering a wide range of processors based on a common architecture that deliver high performance, industry leading power efficiency and reduced system cost. Now its gained popularity in amateur projects also. ARM is a 32-bit reduced instruction set computer (RISC) instruction set architecture (ISA) developed by ARM Holdings. It was known as the Advanced RISC Machine, and before that as the Acorn RISC Machine.

Acorn Computer (who is famous for the BBC Micro) was in need of a number of second processors to support BBC Micro, processors from Motorola and national was not enough for GUI. They tested all available and then they planned for their own processor ( Berkely RISC Project). They felt if a graduate student can design a 32 bit processor the why not Acorn. They started from western design center (Phoenix) and learnt that they don’t need massive resource and facilities. They simulated their Processor design with BBC Basic on a BBC Micro working with 6502 2nd Processor. They collaborated with  VLSI Technology, Inc was as a silicon partner, since it already supplied Acorn with ROMs and some custom chips. The design was led by Wilson and Furber, with a key design goal of achieving low-latency input/output (interrupt) handling like the 6502. The 6502’s memory access architecture had allowed developers to produce fast machines without the use of costly direct memory access hardware. VLSI produced the first ARM silicon on 26 April 1985 – it worked the first time and came to be known as ARM1 by April 1985. The first “real” production systems named ARM2 were available the following year.

The ARM2 featured a 32-bit data bus, a 26-bit address space and twenty-seven 32-bit registers. Program code had to lie within the first 64 Mbyte of the memory, as the program counter was limited to 24 bits because the top 6 and bottom 2 bits of the 32-bit register served as status flags. The ARM2 was possibly the simplest useful 32-bit microprocessor in the world, with only 30,000 transistors(compare the transistor count with Motorola’s six-year older 68000 model which was aptly named, since it contained 68,000 transistors). Much of this simplicity comes from not having microcode (which represents about one-quarter to one-third of the 68000) and, like most CPUs of the day, not including any cache. This simplicity led to its low power usage, while performing better than the Intel 80286. A successor, ARM3, was produced with a 4 KB cache, which further improved performance.

ARM Cores

Architecture

Family

ARMv1

ARM1

ARMv2

ARM2, ARM3

ARMv3

ARM6, ARM7

ARMv4

StrongARM, ARM7TDMI, ARM9TDMI

ARMv5

ARM7EJ, ARM9E, ARM10E, XScale

ARMv6

ARM11

ARMv7

Cortex

To be Continued …


 

FPGA or DSP Processor

During my thesis works, I found the necessity of DSP and FPGA, so I had learned a bit of both and now I want to buy kit of either FPGA or DSP.

I have searched in various forums about this, here is the summary from edaboard

Q: Hi,
I’ll start working in February and I was asked to choose between working with FPGA(VHDL) or DSP(systemC). Please tell me what’s more interresting?
Thanks

ANS1:DSP is a processor but FPGA is array of gates.
DSP is a optimized processor for digital signal processing and fast processing. but fpga is suitable for boolon functions.

 

ANS2:I find FPGAs a lot more fun/useful/challenging than DSP chips. I started using DSPs about 15 years ago, building various array signal processors and controllers. About 5 years ago I dropped them and switched to Xilinx FPGAs. Enormously faster, more flexible, and less expensive than DSPs. However, many engineers find FPGA HDL more difficult to learn than DSP C/Assembler. An engineer with only software skills probably should not attempt FPGA unless you wish to learn a new career, because to create good FPGA designs you have to think like a digital hardware designer.

 

ANS3:FPGA is a trend of digital R&D, which focus on digital circuit realized in soft code but hardware thinking.
DSP’s famours charactor is it’s data stream processing.
Now, EE need to know the FPGA and DSP even the RISC MPU, ADC, DAC etc….

For DSP users have to implemente algorithm (s/w code) in efficient way (some arm’s programmer might focus on porting code for application/peripheriial rather than for cpu/core); selection of core/model and study of computation standards would be encourted oftenly.

but FPGA, as its high flexibility, one would consider to the system view. I think both them are very chanlleging……..

 

FPGAs have several significant advantages over high-end DSP processors. According to benchmark results (shown in Figure , for example, have shown that high-end, DSP-oriented FPGAs have a huge throughput advantage over high-performance DSP processors for certain types of signal processing. And FPGAs, which are not constrained by a specific instruction set or hardwired processing units, are much more flexible than processors.


Figure: Results of the BDTI Communications Benchmark (OFDM)™

The Two Solutions

The DSP is a specialised microprocessor – typically programmed in C, perhaps with assembly code for performance. It is well suited to extremely complex maths-intensive tasks, with conditional processing. It is limited in performance by the clock rate, and the number of useful operations it can do per clock. As an example, a TMS320C6201 has two multipliers and a 200MHz clock – so can achieve 400M multiplies per second.

In contrast, an FPGA is an uncommitted “sea of gates”. The device is programmed by connecting the gates together to form multipliers, registers, adders and so forth. Using the Xilinx Core Generator this can be done at a block-diagram level. Many blocks can be very high level – ranging from a single gate to an FIR or FFT. Their performance is limited by the number of gates they have and the clock rate. Recent FPGAs have included Multipliers especially for performing DSP tasks more efficiently. – For example, a 1M-gate Virtex-II™ device has 40 multipliers that can operate at more than 100MHz. In comparison with the DSP this gives 4000M multiplies per second.

Where They Excel

When sample rates grow above a few Mhz, a DSP has to work very hard to transfer the data without any loss. This is because the processor must use shared resources like memory busses, or even the processor core which can be prevented from taking interrupts for some time. An FPGA on the other hand dedicates logic for receiving the data, so can maintain high rates of I/O.

A DSP is optimised for use of external memory, so a large data set can be used in the processing. FPGAs have a limited amount of internal storage so need to operate on smaller data sets. However FPGA modules with external memory can be used to eliminate this restriction.

A DSP is designed to offer simple re-use of the processing units, for example a multiplier used for calculating an FIR can be re-used by another routine that calculates FFTs. This is much more difficult to achieve in an FPGA, but in general there will be more multipliers available in the FPGA. 

If a major context switch is required, the DSP can implement this by branching to a new part of the program. In contrast, an FPGA needs to build dedicated resources for each configuration. If the configurations are small, then several can exist in the FPGA at the same time. Larger configurations mean the FPGA needs to be reconfigured – a process which can take some time.

The DSP can take a standard C program and run it. This C code can have a high level of branching and decision making – for example, the protocol stacks of communications systems. This is difficult to implement within an FPGA.

Most signal processing systems start life as a block diagram of some sort. Actually translating the block diagram to the FPGA may well be simpler than converting it to C code for the DSP.

Power hungry FPGA
Energy efficiency is often a critical metric for signal processing applications. Battery-powered products are highly sensitive to energy consumption, and even line-powered products are often sensitive to power consumption, though it may be on a per-channel or per-unit-area basis. FPGAs have long been viewed as too power-hungry for most DSP applications, but we believe that this may be an obsolete perspective.

FPGAs use highly flexible architectures, and this flexibility is perhaps their greatest advantage. But flexibility comes with a hardware cost. More flexibility generally means more gates, more silicon area, more routing resources—and higher energy consumption. For this reason, FPGAs are generally less energy efficient than chips with dedicated hardware, such as ASICs.

But how do FPGAs compare to DSP processors? DSPs are highly tailored for efficient implementation of common DSP tasks, and thus many engineers assume that they are more energy-efficient than FPGAs. But DSP processors have their own inefficiencies. In a DSP, only a tiny fraction of the silicon is devoted to computation; most of the silicon area and most of the energy is devoted to moving instructions and data around. Hence, it would be a mistake to assume that FPGAs are inherently less energy efficient than DSPs.

In some high-performance signal processing applications, for example, FPGAs can take advantage of their highly parallel architectures and offer much higher throughput than DSPs. As a result, FPGAs’ overall energy consumption may be significantly lower than that of DSP processors, in spite of the fact that their chip-level power consumption is often higher.

Unfortunately, there is a dearth of accurate, apples-to-apples energy consumption data for FPGAs and DSP processors, making it difficult to compare their energy efficiency As part of the analysis for our recent report comparing FPGAs to DSPs, “FPGAs for DSP, 2nd Edition,” BDTI did its own “back of the envelope” comparisons of the energy efficiency of FPGAs and DSPs. Based on anecdotal data about FPGA power consumption, we estimated that high-end FPGAs implementing demanding DSP applications, such as that embodied in the BDTI Communications Benchmark (OFDM)™, consume on the order of 10 watts, while high-end DSPs consume roughly 2-3 watts. Our benchmark results have shown that high-end FPGAs can support roughly 10 to 100 times more channels on this benchmark than high-end DSPs, suggesting that their energy consumption per channel is significantly lower than that of DSPs. This contradicts the common view that FPGAs are energy hogs.

Obviously our comparison is based on very rough estimates. While we believe that FPGAs’ energy efficiency is likely to be competitive—or even superior—to that of DSPs in many high-performance signal processing applications, this is still an open question. What’s needed is a rigorous, well-controlled analysis of power consumption under comparable conditions.

Furthermore, the above analysis is only meaningful in the context of high-performance signal processing applications. Estimating the relative energy efficiency of FPGAs and processors for less-demanding signal processing applications would require a slightly different benchmarking approach and the evaluation of different chips (e.g., lower-power processors and smaller FPGAs); this is another area that’s ripe for further investigation.

 

Reference:

eetimes.com/design/signal-processing-dsp/4017003/FPGAs-vs-DSPs-A-look-at-the-unanswered-questions

hunteng.co.uk/info/fpga-or-dsp.htm