summaryrefslogtreecommitdiff
path: root/sp12rc.txt
blob: cb0fabe8457813c0b2687e23345089c22758ccbb (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159

_SP12RC RUNTME CONFIGURATION FILE SETTINGS

 PORT=<nnn>

   Before creating _sp12rc, the programmer looks for available
   parallel ports. If more than one address is found, or you know
   about an address missed by sp12, you may want to edit the PORT= 
   line.
   
 KANDA=<n>

   Sp12 is compatible with three programming cables; the one as
   used with previous versions - with or without Ken Huntington's
   `dongle' - and the cable/dongles supplied with the Kanda
   STK200/300 starter kits. The latter two are functionally
   equivalent. To select a hardware mode, you edit the `KANDA' line
   to read `KANDA=0' (original sp12 cable), `KANDA=1' (Kanda mode),
   or `KANDA=3', to make sp12 behave according to how it is called.
   A name with a `k' in it will cause Kanda mode, plain sp12 will be
   just that. In Linux, this allows easy switching between the modes
   when you make a symbolic link to the executable, like
   
      ln -s /usr/local/bin/sp12 /usr/local/bin/sp12.kanda

   This results in 

   -r-sr-xr-x 1 root root 53208 Jan 18 09:02 sp12*
   lrwxrwxrwx 1 root root    19 Jan  1 11:15 sp12.kanda -> /usr/local/bin/sp12*

   Creating a single executable with two names.
   
   Note that the Kanda cable/dongle lacks some features, which means
   that the port control option (see sp12.txt) is of limited use in
   this mode.
   
 LOGPATH=<path/logfile>

   You can set a log path/file, where SP12 will log its write and
   lock operations. The default is "sp12log.txt" in the current 
   directory, creating a separate log file for each project.
   Adding a path combines everything in a single log file.

 LOGGING=<n>
 
   You can set LOGGING=1 (Default is 0.) When `logging' is set,
   every write and lock operation will cause a single line to be
   appended to the log.

 QUERY=<n>

   You can also set QUERY=1 (Default is 0). SP12 normally checks
   each location (or ATmega page) right after writing; if the
   content doesn't match what was written, SP12 retries a couple
   of times before giving up. This procedure achieves correct
   programming when conditions or memory cells are marginal, and
   also catches the large majority of hard errors. But defects and
   averse conditions may sometimes cause the content of one
   address to change, while another is being written to. You can
   catch these (extremely rare) errors by setting both `logging'
   and `query'. After writing a file content into the designated
   memory area, the flash or eeprom will then be read back and
   compared with the file, address by address. When all is well, a
   checksum is calculated and added to the log; else "readback
   ERROR" is reported. For instance:

   AT90S2313    -wpf   diz_2.hex        checksum cb46   Sat Sep 23 18:43:49 2000
   AT90S2313    -wef   diz_2.eep        checksum 0f37   Sat Sep 23 18:43:53 2000
   AT90S2313    -wea   00000052:0xaa    verified        Sat Sep 23 18:43:54 2000 
   AT90S2313    -wpa   00000006:0x5679  readback ERROR  Sat Sep 23 19:30:24 2000
   AT90S2313    -wpf   diz_2.hex        readback ERROR  Fri Sep 23 19:33:02 2000

   NOTE: The overlay option modifies the `query' behaviour; see
   sp12.txt.
   Lock operations are preceded by memory checksum calculations,
   and results are logged like this:
     
   ATmega8      -L3c   flash 2451       eeprom 3d44     Sat Jan 18 09:49:40 2003

   Note that the log command is written in hex, to save space.
   So in the above case the command -wL111100 was used to read and
   write protect the Mega8.
   When logging is set but query is not, the address by address 
   comparison is not performed, and writes are logged like this:

   AT90S2313    -wpf   diz_2.hex        not queried     Fri Sep 29 14:42:21 2000
   AT90S2313    -wef   diz_2.eep        not queried     Fri Sep 29 14:42:22 2000

 CHIPERASE=<nnn>
   
   The default value of 120ms is demanded by for instance the old
   Mega103. Many other devices can make do with 30 or 20ms. If you
   feel the difference is significant, by all means edit this value,
   but be sure to read the datasheets of your devices. There is
   usually a table in the `serial downloading' section.
   
 POWERON=<nnn>

   The value of this time constant depends partly on the power supply
   of your target, which may need time to reach a stable Vcc.
   Note however that for values shorter than 100ms, it is necessary
   to keep both reset and sck at gnd while the device powers up,
   which isn't always possible. It's best to read the `serial
   programming algorithm' in your device's datasheet before
   experimenting with this setting.

 CLOCKSPDDEFAULT=<n.n>

   The default is 0.7MHz, which usually fits devices running on their 
   internal RC clock at Vcc > 4V. You can edit the value and/or
   ask for something different by using the -M option on the command
   line (see sp12.txt). For instance, with `-M4' you state that your
   target is clocked at 4MHz. The minimum value is 0.1.

 LOOPCOUNT=<n.ne+n>

   The default is an autocalibrated number representing one second,
   and used to calculate timing values as demanded by clockSpdDefault
   and the -M option. Manual editing is recommended only if there is
   no way to make autocalibration work well enough. (See the `bugs & 
   bother' section in readme.linux or readme.dos.)

 PORTACCESSTIME=<n.ne-n>

   The time your parallel port needs to respond to an outportb()
   call. Don't edit. As this time is typically longer than 1us, this
   is likely to limit the shortest timing to about 1.3us for an Sck
   half cycle. Most AVR uCs need the Sck low and high phases to be
   at least two clock cycles long; the AT89S1200 is an exception,
   needing an Sck high phase of at least four clock cycles. So
   while SP12 works correctly with very fast uCs, the time needed to
   execute a command line is not likely to decrease for -M and
   clockSpdDefault settings above 3MHz for the 1200, and 1.5MHz for
   the other family members. SP12 reports the timing achieved.

 BYTEWRITE=<nnn>
 PAGEWRITE=<nnn>
 PROGRAMENABLE=<nn>
 RESETPULS=<nnn>

   None of the above settings should be edited, with the possible
   exceptiong of RESETPULS. The default number represents 50ms, and
   is mostly determined by assumptions about the reset circuit of
   your target. A very simple arrangement would consist of 10K
   between the reset pin and Vcc, and a capacitor between that pin
   and gnd. The constant must be (more than) long enough to allow
   that cap to be (dis)charged. If your target has a rapid
   (brown-out) reset circuit, a shorther value is possible.

   NOTE: You may have written software which grabs the i/o lines
   used for programming immediately after reset, and your device's
   reset delay (CKSEL/SUT settings) may be shorter than 50ms.
   This won't usually cause trouble. Sp12 either prevents the grab or
   gently takes back control of the programming lines. You probably
   won't even notice the grab attempt. But in rare cases, RESETPULS
   may have to be reduced to a low value (divide the default by 500
   or 1000) or zero. This has never happened to me (Steve), so I'd
   be interested to hear the details of such cases.