Demo-7    <<-BACK            HOME            UP --^           NEXT-->>  Demo-9
side4linux, a simple integrated development environment!

PCBS Demo-8  Program the 'MC1' Machine Controller with the AVR assembly code 'Debug' monitor.


Purpose: 
Test the Machine Controller MC-1 Programmer, Central Processing Unit and load some code.

Requirements:
Make sure that the latest help packages are installed.

Further Requirements:
Pre-Requisites: Presumes you have a basic understanding of assembly coding and do Demo-/3/4/5/6/7 first.
Preamble:
This is the testing practical for the MC-1 CPU Board, it tests the Programmer between the parallel printer port of your computer and the MC-1 CPU and continues to show how to 'Build' and 'Load' the resulting code into the MC-1 CPU board's Flash and EEprom memory.


Step-1: Test the MC-1 Programmer.

As a first step in the Practical we are going to test the signal lines from your computer through the Programmer, but first please test with a multimeter and ensure that there are no short circuits between lines ( zero Ohms ). Connect up the Power Supply to the Programmer ( and nothing else! ) and switch on. Check all your voltages are correct and switch off. Now plug in the cable to connect the parallel printer port of your computer to the Programmer and switch on. Your computer should be still operating normally! Bring up the side4linux IDE on your computer and open the test project's 'hello.prf' file,  /SIDE/PRODUCTS/MC1/AVRA/Hello/hello.prf using 'Project>Open Project'  from the Main Menu as follows,

Open Project Hello
Fig-1 Open Hello Project Dialog


Now open the file 'hello.asm' using the 'Open-TXT' Toolbar button. You are now looking at a basic master assembly file for the Machine Controller modified for the 'Hello World' practical in Demo-9 to follow. Click on the 'Build' button in the Toolbar and you should see the following in the Output Window below the open file.

Removing src/hello.hex
Removing src/hello.eep.hex
Building src/hello
AVRA: advanced AVR macro assembler Version 1.2.0 Build 30 (15. October 2006)
Copyright (C) 1998-2006. Check out README file for more info

   AVRA is an open source assembler for Atmel AVR microcontroller family
   It can be used as a replacement of 'AVRASM32.EXE' the original assembler
   shipped with AVR Studio. We do not guarantee full compatibility for avra.

   AVRA comes with NO WARRANTY, to the extent permitted by law.
   You may redistribute copies of avra under the terms
   of the GNU General Public License.
   For more information about these matters, see the files named COPYING.

Pass 1...
Pass 2...
done


Assembly complete with no errors.
Segment usage:
   Code      :       604 words (1208 bytes)
   Data      :         0 bytes
   EEPROM    :        28 bytes
Removed upload hex program Flash file from dbavrprog
Removed upload hex data EEprom file from dbavrprog
Copying Flash and EEprom hex files to dbavrprog

You have done more than just assemble the code, the IDE has also transferred your machine code program Flash file and your EEprom data file to the 'dbavrprog' serial programming program's 'files' directory ready for uploading to your MC-1 CPU. These files are 'upprog.hex' and 'upeeprom.hex',
in 'Intel 8-bit Hex' file format. Note that if you were building your own board for an unrelated Product then the procedure will remain the same but we are concentrating
only on the MC-1 for the rest of this Demo. OK, now that you have code to upload to your MC-1 CPU you will need to open the 'dbavrprog' program to program your AVR chip but first a discussion about access 'permissions'.

On Linux users can have their power to access the hardware and/or programs on a computer increased to unlimited use or just restricted to a very small area! This process is called 'setting the permission level' for that user. The Systems Administrator can make someone the 'Super User' 'root' who has unlimited access such as the SA but more likely the SA will limit access via a program such as 'sudo'. The 'sudo' program is not part of side4linux but comes with all Linux Distributions as a helper program. This program allows privileged users access to specified hardware and programs as if they were the 'Super User' but no access to anything else. OK, so you are just a hobbyist running Ubuntu on your own home computer, you will need just to enter your log in password when asked and you will be off. So why the fuss? In a bigger organisation with many computers and CNC ( read dangerous automatic ) machinery it matters a great deal who can have access. A designer may well have access to the programming program that your are about to use but may have no access to the 'drive programs' such as 'Lathedrive' or 'Milldrive' etc. that actually controls CNC equipment. Novice apprentices are a good example of workers who must be supervised at all times by a qualified trades person. This is industrial law in Australia and in many other countries and is usually referred to as 'employee/employer mutual obligation under Occupational, Health, Welfare, Safety and Environmental regulations'.

So in short side4linux programs that access the hardware on your computer are called via the 'sudo' program as 'sudo theCalledProgram optionsList'.

So how are the user permissions set? 
Permissions are set by entering them into a special text file on the computer called 'sudoers'.

As an exercise look for yours using the 'whereis' command from a terminal e.g.

db@wks1:~$ whereis sudoers
sudoers: /etc/sudoers /usr/share/man/man5/sudoers.5.gz
db@wks1:~$

So I have two options /etc/sudoers and /usr/share/man/man5/sudoers.5.gz this means I could issue the 'info sudoers' command from the terminal for the information on sudoers or I could edit the sudoers file '/etc/sudoers' from a super user's terminal as say 'gedit /etc/sudoers'.

The contents of the 'sudoers' file on the office PC which I share is as follows,

# /etc/sudoers
#
# This file can be edited with the 'gedit /etc/sudoers' command as root.
#
# See the man page for details on how to write a sudoers file.
#
# Host alias specification
# User alias specification
# Cmnd alias specification
# Defaults

Defaults    !lecture,tty_tickets,!fqdn

# User privilege specification
root    ALL=(ALL) ALL

# Members of the admin group may gain root privileges
%admin    ALL=(ALL) ALL

# add to allow use of dbavrprog program for members of group 'db'
%db    ALL = /home/db/Data/Projects/SIDE/TOOLS/SIDEtools/GNOMEC/Dbavrprog/src/dbavrprog

Look at the area under the line,
'# User privilege specification',  this 'sudoers' file gives the super user 'root' full privileges and also any one in the 'admin' group full access also. The last line of the file says that those in the 'db' users group namely me (David Burke) can have super user access to the ports needed by the 'dbavrprog' program. So if you are just an ordinary user of this computer like me you need to be in the 'db' group. If you are the only user such as our hobbyist on Ubuntu mentioned earlier then you would be in the 'admin' group by default and hence covered by all sudo launched programs.

So after all that let use launch the serial programming program as 'Tools>AVRA>AVR PROGRAM', you should be greeted by 'sudo's' password dialog similar to the graphic below,

 Sudo Dialog Box
Fig-2 Sudo Dialog Box.

After using your normal password that you signed on with and on clicking the Continue' button you should now have the dbavrprog screen up on your display as follows,


dbavrprog Sign On Screen
Fig-3 dbavrprog sign on screen.

Now to set up access to your printer port, click on the 'SetSerial' button and you should be greeted with the message,

I/O Permission granted

    Port Access Granted, you may continue!


Step-2: Testing the power.

Notice that most of the other Toolbar buttons should no longer be grayed out. You can now
plug in and switch on your programmer. We can try toggling the serial switching lines, 'RESET', 'MOSI' and 'SCK'.

Click on the 'Debug' Toolbar button and look at the following graphics in Figures-4/5,

dbavrprog Debug Dialog Programmer Top View
Fig-4 Debug Dialog
Fig-5 Programmer Top View

You need to place a logic probe on each signal line at 'CONN101' corresponding with the signal to be toggled then click on the radio buttons in the Debug Dialog. The logic probe should go from low to high and back as you click from one radio button and back (use a multimeter set to twenty volts if you do not have a logic probe in which case low = 0 volts and high = 5 volts approx.). If your lines seem stuck high or low or the other voltages do not tally then switch off and disconnect the programmer and check for shorting between the pads and wiring. Once you are past this point close down the 'dbavrprog' program and switch off. Connect the MC-1 CPU ready for programming by plugging in the ribbon cable, make sure the switch across 'CONN102' is closed! Notice that you bring up the programmer program and click on the 'SetSerial' button before powering up the power supply, use this sequence always!


Step-3: Testing the MC-1 CPU.

Once again open the 'dbavrprog' program, you have now reached the stage where we will see if your AVR chip likes you! Click on the 'SetSerial' Toolbar button with the power supply switched off. Now click on the 'ReadID' button, you should be greeted with the error message,

  Device not responding to Programming Enable Instruction!
  Is device energised?

Switch on the power supply and try the 'ReadID' button again and see if you get the following message,

  Looking for signature bytes = : 1E :  97 :  02 : 

(the ID bytes will be different if you are using another Atmel chip type in your own project, if that is the case then check that chip's manual for the correct ID),

If you do not get the message or the ID bytes are wrong then close the programmer program and alter the IDE's global Delay timing value to a higher number.

  'Preferences>IDE>Basic>
Delay Value'

( 5 = OK for 1 Gigahertz machine, more for faster machines and less for slower ones! ),

If this fails to get the required message then using the logic probe, check to see if 'MISO', 'MOSI' and 'SCK' are toggling and that 'RESET' is always held low. Make sure that the switch across 'CONN102' is closed and voltages are correct on the MC-1 CPU and programmer.

You can also open the Dbavrprog project and set some of the 'debug' flags for more information. Recompile Dbavrprog and launch side4linux from a terminal and look what is printed in the terminal.

Now if you can get this far click on the 'EraseALL' button then on the 'Test' button. This should turn up the following message,

Testing Flash Memory for Full Erasure!
Trying to Upload Intel Hex file files/upprog.hex to measure length!
Verify program Flash of length 004F0h bytes in progress!

Verify Program Address     0 = FFFF
Verify Program Address   100 = FFFF
Verify Program Address   200 = FFFF
Verify Program Address   300 = FFFF
Verify Program Address   400 = FFFF
Verify Program Address   500 = FFFF

 Trying to read 'EESAVE' Fuse on chip,  'EESAVE' flag = 0
 OK testing Flash Memory, I will now test EEprom Memory for Full Erasure.

Verify EEprom Address -->     0 = FF
Verify EEprom Address -->   100 = FF
Verify EEprom Address -->   200 = FF
Verify EEprom Address -->   300 = FF
Verify EEprom Address -->   400 = FF
Verify EEprom Address -->   500 = FF
Verify EEprom Address -->   600 = FF
Verify EEprom Address -->   700 = FF
Verify EEprom Address -->   800 = FF
Verify EEprom Address -->   900 = FF
Verify EEprom Address -->   A00 = FF
Verify EEprom Address -->   B00 = FF
Verify EEprom Address -->   C00 = FF
Verify EEprom Address -->   D00 = FF
Verify EEprom Address -->   E00 = FF
Verify EEprom Address -->   F00 = FF
Verify EEprom Address -->  1000 = FF

The Program and EEprom memory are erased!

Step-4: Programming the MC-1 CPU.

Once you can complete Step-3 successfully you are ready to do some programming! Click on the 'WriteEEprom' button and get the following message,

Uploading Intel Hex file to EEPROM memory

Addr: 00000 writing byte |4D|
Addr: 00001 writing byte |43|
Addr: 00002 writing byte |2D|
Addr: 00003 writing byte |31|
Addr: 00004 writing byte |20|
Addr: 00005 writing byte |56|
Addr: 00006 writing byte |65|
Addr: 00007 writing byte |72|
Addr: 00008 writing byte |20|
Addr: 00009 writing byte |37|
Addr: 0000A writing byte |2E|
Addr: 0000B writing byte |30|
Addr: 0000C writing byte |20|
Addr: 0000D writing byte |2D|
Addr: 0000E writing byte |20|
Addr: 0000F writing byte |20|
Addr: 00010 writing byte |48|
Addr: 00011 writing byte |65|
Addr: 00012 writing byte |6C|
Addr: 00013 writing byte |6C|
Addr: 00014 writing byte |6F|
Addr: 00015 writing byte |20|
Addr: 00016 writing byte |57|
Addr: 00017 writing byte |6F|
Addr: 00018 writing byte |72|
Addr: 00019 writing byte |6C|
Addr: 0001A writing byte |64|
Addr: 0001B writing byte |21|

Write from file to chip EEPROM was successful

If it did not work properly then slow down the timing by altering the timing value to a bigger number as in Step-3 above.
Now click on  the 'EraseALL' button then on the 'Test' button followed by the 'WriteFlash' button and get the following,

Attempting to write the program Flash Type-2

Uploading Intel Hex file files/upprog.hex to Program Flash memory

Writing Addr: 00000 Data|05C0|
Writing Addr: 00100 Data|002D|
Writing Addr: 00200 Data|0D91|

Writing Image to Program Flash
Writing Page: 0000
Writing program Flash Page:0 to chip
Verifying Page 00:80 Addr 00080
Writing Page: 0001
Writing program Flash Page:1 to chip
Verifying Page 01:80 Addr 00100
Writing Page: 0002
Writing program Flash Page:2 to chip
Verifying Page 02:80 Addr 00180
Writing Page: 0003
Writing program Flash Page:3 to chip
Verifying Page 03:80 Addr 00200
Writing Page: 0004
Writing program Flash Page:4 to chip
Verifying Page 04:80 Addr 00280

Write from file to Program Flash was successful

Notice that you must click on the 'EraseALL'  button then the 'Test' button and test the Flash for erasure before trying to program the Flash! The EEprom can be programmed at anytime but you must set the 'EESAVE' fuse yourself (unset by default) to prevent the 'EraseALL' button from erasing the EEprom along with the Flash. Also once the 'EESAVE' fuse is set then the 'Test' button only checks the Flash for erasure.

Step-5: Program the Fuses.

Click on the 'FuseBits' button and set the 'EESAVE' box. Click the 'FuseBits' button again to see if it reads back as set. Repeat this sequence but unset the box to see if the fuse is unset on reading back.

Now let us set the fusebits so that the chip will function correctly in Demo-9.

Set the fusebits as shown below in Figure-6 . This enables ATmega128 mode ( unset M103C ) , turns off the JTAG interface (unset JTAGEN ) and set for the external crystal oscillator.

dbavrprog Fuse Map
Fig-6 MC-1 Fuse Map Settings

Once the fusebits have been set as above in Figure-6, click on 'Apply' but be careful not to set all 'CKSEL' fuses on as you will then need an external clock source signal attached to the 'XTAL1' pin with the crystal removed to recover! ( You need to have some form of clock source to run the 'SPI' module in the chip so that you can do your programming! ) Why not alter the software to block this? Well there are times when an external clock source might be needed, and you have been warned!

Now check with an oscilloscope or logic probe that your crystal is oscillating!

Close the programming software 'dbavrprog' and switch the MC-1 power supply off then back on. Re-launch the programmer software and after clicking on 'SetSerial' click on 'ReadID' this should return the message,

 'Looking for signature bytes = : 1E :  97 :  02 :  '

If it does then you have moved from the default internal oscillator to your crystal oscillator successfully! If not then you need to replace the crystal and maybe the capacitors attached varying the values within the range set by the AVRmaga128 workshop manual until it oscillates.

Step-6: Verify the Programming and End.

Programmed data and code is verified against upload files during programming but you could compare the original files uploaded with those downloaded using the 'diff' or 'meld' programs.

You could click on the 'EraseALL' button and program the Flash and EEprom (optional) then click on  'ReadFlash' and 'ReadEEprom' to download the chip's memory into files in the Project's directory.

If you have a slow computer and operations take an age try reducing the 'Delay' variable set in Step-3 to you find an optimum value.

Congratulations if you have got this far as this is the end of Demo-8!


In Demo-9 We will communicate with the 'MC1' Machine Controller PCB via the 'Bterm' program.


We will provide other demos as 'side4linux' develops to cover integration into a real world machine controller.