forked from avrprog2/avrprog2-code
-
Notifications
You must be signed in to change notification settings - Fork 0
/
doc.txt
151 lines (103 loc) · 6.26 KB
/
doc.txt
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
/*!
@page Documentation
This documentation is mainly for programmers who want to extend the functionality of \a avrprog2 (https://github.com/avrprog2/avrprog2-code) or want to reuse code in their own projects.
\a avrprog2 is a linux frontend for the mikroElektronika (http://mikroe.com) AVRprog2 programming hardware.
@section install Compilation and Installation
This project uses the \a GNU \a autoconf toolchain.
If you want to use the source directly from the repository start with (in this the newest trunk version is used):
@code
git clone https://github.com/avrprog2/avrprog2-code.git avrprog2
cd avrprog2
./autogen.sh
@endcode
To build the application from a downloaded source package start with:
@code
tar xfvz avrprog2-1.4.2.tar.gz
cd avrprog2-1.4.2
@endcode
The following steps are equal in both cases and will compile the application in the build directory.
@code
mkdir build
cd build
../configure
make
@endcode
To install the application type
@code
sudo make install
@endcode
To build the doxygen reference execute
@code
make doc
@endcode
@section programflow Program flow
The program does all its tasks in the following order.
- Parse the command line arguments and check the correctness of them.
- Do all things which do not need a connection to the hardware device.
- Print version information.
- List all supported devices.
- Read input files.
- Connect to the programming hardware.
- If not specified on the command line try use auto detect the following parameters.
- Auto detect programming pins.
- Auto detect device by the device signature.
- Auto detect device frequency.
- Perform the actions according to the command line parameters in the following order.
- Perform a chip erase.
- Perform Fuses actions (write, read, verify).
- Perform Flash memory actions (write, read, verify).
- Perform EEPROM memory actions (write, read, verify).
- Close the connection to the programming hardware.
@section autodetection Auto detection Mechanisms
This section describes the mode of operation of the implemented autodetection mechanisms.
@subsection socket Programming Pins
Some mcu cards for the mikroElektronika development boards have more than one mcu socket. Hence it is necessary to specify the right one before one tries to communicate with the device.
The procedure to detect the right pins is quite simple. It selects the first socket, tries to detect a device and stops if a device answers. If not, the same procedure is done with the second socket.
@subsection device Device
If no device type is specified on the command line the programmer tries to identify the device itself. Todo so it reads the device signature and looks in the config directories for the according configuration file.
To avoid unintended damage of the target device, this feature is deactivated when fuse bytes are written.
@subsection frequency Device frequency
If no frequency is specified at the command line the programmer tries to detect the device frequency in the following way.
- It sets the frequency to the lowest possible value (128kHz).
- Then it reads the device signature.
- Now the frequency is increased up to 16Mhz and after each step the device signature is read again. If it does not coincide with the first read signature, this frequency was too high and the programmer returns to the last working one.
@section configfiles Device Configuration Files
Default locations for device description files are /etc/avrprog2 (system wide) and ~/.avrprog2 (per user).
Device description files contain the following information about a AVR device.
- name
- device signature
- size of Flash memory
- size of EEPROM memory
- number of Fuse bytes
- package (used to select the programming pins, this is optional)
This information is stored in *.xml files, which look like this one:
@code
<device>
<name>ATmega 128</name>
<signature>0x1e9702</signature>
<flashSize>4096</flashSize>
<eepromSize>4096</eepromSize>
<numOfFuses>3</numOfFuses>
<package>TQFP64</package>
</device>
@endcode
If the \a package is not specified, avrprog2 tries to auto detect a device and to select the right programming pins.
@section files Binary Files
Avrprog2 can read files in \a elf and \a ihex format. It determines the type by the file extension. Where *.elf files are opened as elf, whereas *.hex, *.ihex and *.eep files are treated as intel hex files.
In the following the behavior of the file parsers is described. It depends mainly on the type of memory (EEPROM, Flash or Fuses) to which the file should be written.
When reading content from memory to a file, this application writes always files in ihex format.
@subsection ihex ihex Parser
When a hex file is read, all sections of the file are copied to the programming buffer. If the target memory is flash memory, the \a lma entries in each section are considered. For other memory types the entry is ignored and all sections are written sequentially.
@subsection elf elf Parser
When a elf file is read it depends on the target memory which sections are copied to the internal buffer. If the target is Flash memory, then the \a .text and \a .data sections are copied with consideration of the \a lma entries.
If the target is EEPROM memory, the \a .eeprom section is copied to the internal buffer without processing the \a lma entry. Hence the content will start at EEPROM address 0x0000. This allows programming of elf files, without the need to invoke \a objcopy.
When the target of the programming operation are fuse bytes, then the \a .fuse section of the elf file is read. Again the \a lma entry is ignored.
@section libs Libraries
The following libraries are used by this programmer.
- \a libbfd is used for reading and writing binary files.
- \a libboostfilesystem is used to traverse the config directories.
- \a libusb is used for usb communication. Here a version greater 1 is necessary since in older versions the isochronous transfer mode is no implemented.
- \a libboostpropertytree is used for reading the xml configuration files.
@section docs Further Documentation
More implementation details are documented directly in the source code. A class reference can be build with Doxygen (Todo so use the \a doc make target.) The used low level commands for the communication with the programming hardware are documented in CAvrProgCommands.cpp.
*/