| 1 |
50 |
olivier.gi |
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
|
| 2 |
|
|
<html>
|
| 3 |
|
|
<head>
|
| 4 |
|
|
<title>openMSP430 Integration and Connectivity</title>
|
| 5 |
|
|
</head>
|
| 6 |
|
|
<body>
|
| 7 |
|
|
<a name="TOC"></a>
|
| 8 |
|
|
<h3>Table of content</h3>
|
| 9 |
|
|
<ul>
|
| 10 |
|
|
<li><a href="#1. Overview"> 1. Overview</a></li>
|
| 11 |
|
|
<li><a href="#2. Clocks"> 2. Clocks</a></li>
|
| 12 |
|
|
<li><a href="#3. Resets"> 3. Resets</a></li>
|
| 13 |
|
|
<li><a href="#4. Program Memory"> 4. Program Memory</a></li>
|
| 14 |
|
|
<li><a href="#5. Data Memory"> 5. Data Memory</a></li>
|
| 15 |
|
|
<li><a href="#6. Peripherals"> 6. Peripherals</a></li>
|
| 16 |
|
|
<li><a href="#7. Interrupts"> 7. Interrupts</a></li>
|
| 17 |
|
|
<li><a href="#8. Serial Debug Interface">8. Serial Debug Interface</a></li>
|
| 18 |
|
|
</ul>
|
| 19 |
|
|
|
| 20 |
|
|
<a name="1. Overview"></a>
|
| 21 |
|
|
<h1>1. Overview</h1>
|
| 22 |
|
|
|
| 23 |
|
|
This chapter aims to give a comprehensive description of all openMSP430 core interfaces in order to facilitates its integration within an ASIC or FPGA.<br /><br />
|
| 24 |
|
|
|
| 25 |
|
|
The following diagram shows an overview of the openMSP430 core connectivity:<br /><br />
|
| 26 |
116 |
olivier.gi |
<img src="usercontent,img,1306268589" width="100%" alt="Core Integration - 24 May 2011" title="Core Integration - 24 May 2011" />
|
| 27 |
50 |
olivier.gi |
<br /><br />
|
| 28 |
|
|
The full pinout of the core is summarized in the following table.<br />
|
| 29 |
|
|
<br />
|
| 30 |
|
|
<table border="1">
|
| 31 |
|
|
<tr> <td align="center"><b>Port Name</b></td> <td align="center"><b>Direction</b></td> <td align="center"><b>Width</b> </td> <td align="center"><b>Description</b></td> </tr>
|
| 32 |
|
|
|
| 33 |
|
|
<tr> <td colspan="4" align="center"> <b><i>Clocks</i></b> </td></tr>
|
| 34 |
116 |
olivier.gi |
<tr>
|
| 35 |
|
|
<td> <a href="#2. Clocks">cpu_en</a> </td>
|
| 36 |
|
|
<td> Input </td>
|
| 37 |
|
|
<td> 1 </td>
|
| 38 |
|
|
<td> Enable CPU code execution (asynchronous) </td>
|
| 39 |
|
|
</tr>
|
| 40 |
50 |
olivier.gi |
<tr>
|
| 41 |
|
|
<td> <a href="#2. Clocks">dco_clk</a> </td>
|
| 42 |
|
|
<td> Input </td>
|
| 43 |
|
|
<td> 1 </td>
|
| 44 |
|
|
<td> Fast oscillator (fast clock), CPU clock </td>
|
| 45 |
|
|
</tr>
|
| 46 |
|
|
<tr>
|
| 47 |
|
|
<td> <a href="#2. Clocks">lfxt_clk</a> </td>
|
| 48 |
|
|
<td> Input </td>
|
| 49 |
|
|
<td> 1 </td>
|
| 50 |
|
|
<td> Low frequency oscillator (typ. 32kHz) </td>
|
| 51 |
|
|
</tr>
|
| 52 |
|
|
<tr>
|
| 53 |
|
|
<td> <a href="#2. Clocks">mclk</a> </td>
|
| 54 |
|
|
<td> Output </td>
|
| 55 |
|
|
<td> 1 </td>
|
| 56 |
|
|
<td> Main system clock </td>
|
| 57 |
|
|
</tr>
|
| 58 |
|
|
<tr>
|
| 59 |
|
|
<td> <a href="#2. Clocks">aclk_en</a> </td>
|
| 60 |
|
|
<td> Output </td>
|
| 61 |
|
|
<td> 1 </td>
|
| 62 |
|
|
<td> ACLK enable </td>
|
| 63 |
|
|
</tr>
|
| 64 |
|
|
<tr>
|
| 65 |
|
|
<td> <a href="#2. Clocks">smclk_en</a> </td>
|
| 66 |
|
|
<td> Output </td>
|
| 67 |
|
|
<td> 1 </td>
|
| 68 |
|
|
<td> SMCLK enable </td>
|
| 69 |
|
|
</tr>
|
| 70 |
|
|
|
| 71 |
|
|
<tr> <td colspan="4" align="center"> <b><i>Resets</i></b> </td></tr>
|
| 72 |
|
|
<tr>
|
| 73 |
116 |
olivier.gi |
<td> <a href="#3. Resets">puc_rst</a> </td>
|
| 74 |
50 |
olivier.gi |
<td> Output </td>
|
| 75 |
|
|
<td> 1 </td>
|
| 76 |
|
|
<td> Main system reset </td>
|
| 77 |
|
|
</tr>
|
| 78 |
|
|
<tr>
|
| 79 |
|
|
<td> <a href="#3. Resets">reset_n</a> </td>
|
| 80 |
|
|
<td> Input </td>
|
| 81 |
|
|
<td> 1 </td>
|
| 82 |
116 |
olivier.gi |
<td> Reset Pin (low active, asynchronous) </td>
|
| 83 |
50 |
olivier.gi |
</tr>
|
| 84 |
|
|
|
| 85 |
|
|
|
| 86 |
|
|
<tr> <td colspan="4" align="center"> <b><i>Program Memory interface</i></b> </td></tr>
|
| 87 |
|
|
<tr>
|
| 88 |
|
|
<td> <a href="#4. Program Memory">pmem_addr</a> </td>
|
| 89 |
|
|
<td> Output </td>
|
| 90 |
|
|
<td> `PMEM_AWIDTH<sup>1</sup> </td>
|
| 91 |
|
|
<td> Program Memory address </td>
|
| 92 |
|
|
</tr>
|
| 93 |
|
|
<tr>
|
| 94 |
|
|
<td> <a href="#4. Program Memory">pmem_cen</a> </td>
|
| 95 |
|
|
<td> Output </td>
|
| 96 |
|
|
<td> 1 </td>
|
| 97 |
|
|
<td> Program Memory chip enable (low active) </td>
|
| 98 |
|
|
</tr>
|
| 99 |
|
|
<tr>
|
| 100 |
|
|
<td> <a href="#4. Program Memory">pmem_din</a> </td>
|
| 101 |
|
|
<td> Output </td>
|
| 102 |
|
|
<td> 16 </td>
|
| 103 |
|
|
<td> Program Memory data input </td>
|
| 104 |
|
|
</tr>
|
| 105 |
|
|
<tr>
|
| 106 |
|
|
<td> <a href="#4. Program Memory">pmem_dout</a> </td>
|
| 107 |
|
|
<td> Input </td>
|
| 108 |
|
|
<td> 16 </td>
|
| 109 |
|
|
<td> Program Memory data output </td>
|
| 110 |
|
|
</tr>
|
| 111 |
|
|
<tr>
|
| 112 |
|
|
<td> <a href="#4. Program Memory">pmem_wen</a> </td>
|
| 113 |
|
|
<td> Output </td>
|
| 114 |
|
|
<td> 2 </td>
|
| 115 |
116 |
olivier.gi |
<td> Program Memory write byte enable (low active) </td>
|
| 116 |
50 |
olivier.gi |
</tr>
|
| 117 |
|
|
|
| 118 |
|
|
<tr> <td colspan="4" align="center"> <b><i>Data Memory interface</i></b> </td></tr>
|
| 119 |
|
|
<tr>
|
| 120 |
|
|
<td> <a href="#5. Data Memory">dmem_addr</a> </td>
|
| 121 |
|
|
<td> Output </td>
|
| 122 |
|
|
<td> `DMEM_AWIDTH<sup>1</sup> </td>
|
| 123 |
|
|
<td> Data Memory address </td>
|
| 124 |
|
|
</tr>
|
| 125 |
|
|
<tr>
|
| 126 |
|
|
<td> <a href="#5. Data Memory">dmem_cen</a> </td>
|
| 127 |
|
|
<td> Output </td>
|
| 128 |
|
|
<td> 1 </td>
|
| 129 |
|
|
<td> Data Memory chip enable (low active) </td>
|
| 130 |
|
|
</tr>
|
| 131 |
|
|
<tr>
|
| 132 |
|
|
<td> <a href="#5. Data Memory">dmem_din</a> </td>
|
| 133 |
|
|
<td> Output </td>
|
| 134 |
|
|
<td> 16 </td>
|
| 135 |
|
|
<td> Data Memory data input </td>
|
| 136 |
|
|
</tr>
|
| 137 |
|
|
<tr>
|
| 138 |
|
|
<td> <a href="#5. Data Memory">dmem_dout</a> </td>
|
| 139 |
|
|
<td> Input </td>
|
| 140 |
|
|
<td> 16 </td>
|
| 141 |
|
|
<td> Data Memory data output </td>
|
| 142 |
|
|
</tr>
|
| 143 |
|
|
<tr>
|
| 144 |
|
|
<td> <a href="#5. Data Memory">dmem_wen</a> </td>
|
| 145 |
|
|
<td> Output </td>
|
| 146 |
|
|
<td> 2 </td>
|
| 147 |
116 |
olivier.gi |
<td> Data Memory write byte enable (low active) </td>
|
| 148 |
50 |
olivier.gi |
</tr>
|
| 149 |
|
|
|
| 150 |
|
|
<tr> <td colspan="4" align="center"> <b><i>External Peripherals interface</i></b> </td></tr>
|
| 151 |
|
|
<tr>
|
| 152 |
|
|
<td> <a href="#6. Peripherals">per_addr</a> </td>
|
| 153 |
|
|
<td> Output </td>
|
| 154 |
116 |
olivier.gi |
<td> 14 </td>
|
| 155 |
50 |
olivier.gi |
<td> Peripheral address </td>
|
| 156 |
|
|
</tr>
|
| 157 |
|
|
<tr>
|
| 158 |
|
|
<td> <a href="#6. Peripherals">per_din</a> </td>
|
| 159 |
|
|
<td> Output </td>
|
| 160 |
|
|
<td> 16 </td>
|
| 161 |
|
|
<td> Peripheral data input </td>
|
| 162 |
|
|
</tr>
|
| 163 |
|
|
<tr>
|
| 164 |
|
|
<td> <a href="#6. Peripherals">per_dout</a> </td>
|
| 165 |
|
|
<td> Input </td>
|
| 166 |
|
|
<td> 16 </td>
|
| 167 |
|
|
<td> Peripheral data output </td>
|
| 168 |
|
|
</tr>
|
| 169 |
|
|
<tr>
|
| 170 |
|
|
<td> <a href="#6. Peripherals">per_en</a> </td>
|
| 171 |
|
|
<td> Output </td>
|
| 172 |
|
|
<td> 1 </td>
|
| 173 |
|
|
<td> Peripheral enable (high active) </td>
|
| 174 |
|
|
</tr>
|
| 175 |
|
|
<tr>
|
| 176 |
116 |
olivier.gi |
<td> <a href="#6. Peripherals">per_we</a> </td>
|
| 177 |
50 |
olivier.gi |
<td> Output </td>
|
| 178 |
|
|
<td> 2 </td>
|
| 179 |
116 |
olivier.gi |
<td> Peripheral write byte enable (high active) </td>
|
| 180 |
50 |
olivier.gi |
</tr>
|
| 181 |
|
|
|
| 182 |
|
|
<tr> <td colspan="4" align="center"> <b><i>Interrupts</i></b> </td></tr>
|
| 183 |
|
|
<tr>
|
| 184 |
|
|
<td> <a href="#7. Interrupts">irq</a> </td>
|
| 185 |
|
|
<td> Input </td>
|
| 186 |
|
|
<td> 14 </td>
|
| 187 |
|
|
<td> Maskable interrupts (one-hot signal) </td>
|
| 188 |
|
|
</tr>
|
| 189 |
|
|
<tr>
|
| 190 |
|
|
<td> <a href="#7. Interrupts">nmi</a> </td>
|
| 191 |
|
|
<td> Input </td>
|
| 192 |
|
|
<td> 1 </td>
|
| 193 |
|
|
<td> Non-maskable interrupt (asynchronous) </td>
|
| 194 |
|
|
</tr>
|
| 195 |
|
|
<tr>
|
| 196 |
|
|
<td> <a href="#7. Interrupts">irq_acc</a> </td>
|
| 197 |
|
|
<td> Output </td>
|
| 198 |
|
|
<td> 14 </td>
|
| 199 |
|
|
<td> Interrupt request accepted (one-hot signal) </td>
|
| 200 |
|
|
</tr>
|
| 201 |
|
|
|
| 202 |
|
|
<tr> <td colspan="4" align="center"> <b><i>Serial Debug interface</i></b> </td></tr>
|
| 203 |
|
|
<tr>
|
| 204 |
116 |
olivier.gi |
<td> <a href="#8. Serial Debug Interface">dbg_en</a> </td>
|
| 205 |
|
|
<td> Input </td>
|
| 206 |
|
|
<td> 1 </td>
|
| 207 |
|
|
<td> Debug interface enable (asynchronous) </td>
|
| 208 |
|
|
</tr>
|
| 209 |
|
|
<tr>
|
| 210 |
50 |
olivier.gi |
<td> <a href="#8. Serial Debug Interface">dbg_freeze</a> </td>
|
| 211 |
|
|
<td> Output </td>
|
| 212 |
|
|
<td> 1 </td>
|
| 213 |
|
|
<td> Freeze peripherals </td>
|
| 214 |
|
|
</tr>
|
| 215 |
|
|
<tr>
|
| 216 |
|
|
<td> <a href="#8. Serial Debug Interface">dbg_uart_txd</a> </td>
|
| 217 |
|
|
<td> Output </td>
|
| 218 |
|
|
<td> 1 </td>
|
| 219 |
|
|
<td> Debug interface: UART TXD </td>
|
| 220 |
|
|
</tr>
|
| 221 |
|
|
<tr>
|
| 222 |
|
|
<td> <a href="#8. Serial Debug Interface">dbg_uart_rxd</a> </td>
|
| 223 |
|
|
<td> Input </td>
|
| 224 |
|
|
<td> 1 </td>
|
| 225 |
116 |
olivier.gi |
<td> Debug interface: UART RXD (asynchronous) </td>
|
| 226 |
50 |
olivier.gi |
</tr>
|
| 227 |
|
|
</table>
|
| 228 |
|
|
<br />
|
| 229 |
|
|
<sup>1</sup>: This parameter is declared in the "openMSP430_defines.v" file and defines the RAM/ROM size.<br />
|
| 230 |
|
|
<br />
|
| 231 |
|
|
|
| 232 |
|
|
|
| 233 |
|
|
<a name="2. Clocks"></a>
|
| 234 |
|
|
<div style="text-align: right"><a href="#TOC">Top</a></div>
|
| 235 |
|
|
<h1>2. Clocks</h1>
|
| 236 |
|
|
|
| 237 |
|
|
The different clocks in the design are managed by the Basic Clock Module:
|
| 238 |
|
|
<br /><br />
|
| 239 |
|
|
<img src="getimg.php?1246434498" width="75%" alt="Clock structure diagram" title="Clock structure diagram" />
|
| 240 |
|
|
<br />
|
| 241 |
|
|
<ul>
|
| 242 |
116 |
olivier.gi |
<li>
|
| 243 |
|
|
<b><font color="#0000b0">CPU_EN</font></b>: this input port provide a hardware mean to stop or resume CPU execution. When unused, this port should be set to 1.
|
| 244 |
|
|
<br /><br />
|
| 245 |
|
|
</li>
|
| 246 |
|
|
<li>
|
| 247 |
|
|
<b><font color="#0000b0">DCO_CLK</font></b>: this input port is typically connected to a PLL, RC oscillator or any clock resource the target FPGA might provide.<br />
|
| 248 |
50 |
olivier.gi |
From a synthesis tool perspective (ISE, Quartus, Libero, Design Compiler...), this the only port where a clock needs to be declared.
|
| 249 |
|
|
<br /><br />
|
| 250 |
|
|
</li>
|
| 251 |
|
|
<li>
|
| 252 |
116 |
olivier.gi |
<b><font color="#0000b0">LFXT_CLK</font></b>: if ACLK_EN or SMCLK_EN are going to be used in the project (for example through the Watchdog or TimerA peripherals), then this port needs to be connected to a clock running at least two time slower as DCO_CLK (typically 32kHz). It can be connected to 0 or 1 otherwise.
|
| 253 |
50 |
olivier.gi |
<br /><br />
|
| 254 |
|
|
</li>
|
| 255 |
|
|
<li>
|
| 256 |
116 |
olivier.gi |
<b><font color="#00b000">MCLK</font></b>: the main system clock drives the complete openMSP430 clock domain, including program/data memories and the peripheral interfaces.
|
| 257 |
50 |
olivier.gi |
<br /><br />
|
| 258 |
|
|
</li>
|
| 259 |
|
|
<li>
|
| 260 |
116 |
olivier.gi |
<b><font color="#00b000">ACLK_EN / SMCLK_EN</font></b>: these two clock enable signals can be used in order to emulate the original ACLK and SMCLK from the MSP430 specification.<br />
|
| 261 |
50 |
olivier.gi |
An example of this can be found in the Watchdog and TimerA modules, where it is implemented as following:<br /><br />
|
| 262 |
|
|
<img src="getimg.php?1246434793" alt="Clock implementation example" title="Clock implementation example" />
|
| 263 |
|
|
<br /><br />
|
| 264 |
|
|
</li>
|
| 265 |
|
|
</ul>
|
| 266 |
|
|
|
| 267 |
|
|
As an illustration, the following waveform shows the different clocks where the software running on the openMSP430 configures the BCSCTL1 and BCSCTL2 registers so that <i>ACLK_EN</i> and <i>SMCLK_EN</i> are respectively running at <i>LFXT_CLK/2</i> and <i>DCO_CLK/4</i>.<br /><br />
|
| 268 |
|
|
<img src="getimg.php?1263320613" width="100%" alt="Waveforms: Clocks - Jan 12. 2010" title="Waveforms: Clocks - Jan 12. 2010" />
|
| 269 |
|
|
<br /><br />
|
| 270 |
|
|
|
| 271 |
|
|
<a name="3. Resets"></a>
|
| 272 |
|
|
<div style="text-align: right"><a href="#TOC">Top</a></div>
|
| 273 |
|
|
<h1>3. Resets</h1>
|
| 274 |
|
|
|
| 275 |
|
|
<ul>
|
| 276 |
|
|
<li><b><font color="#0000b0">RESET_N</font></b>: this input port is typically connected to a board push button and is generally combined with the system power-on-reset.
|
| 277 |
|
|
<br /><br />
|
| 278 |
|
|
</li>
|
| 279 |
|
|
<li>
|
| 280 |
116 |
olivier.gi |
<b><font color="#00b000">PUC_RST</font></b>: the Power-Up-Clear signal is asynchronously set with the reset pin (<i>RESET_N</i>), the watchdog reset or the serial debug interface reset. In order to get clean timings, it is synchronously cleared with MCLK's falling edge. As a general rule, this signal should be used as the reset of the <i>MCLK</i> clock domain.
|
| 281 |
50 |
olivier.gi |
<br /><br />
|
| 282 |
|
|
</li>
|
| 283 |
|
|
</ul>
|
| 284 |
|
|
The following waveform illustrates this:<br /><br />
|
| 285 |
|
|
<img src="getimg.php?1263320655" width="100%" alt="Waveforms: Resets - Jan 12. 2010" title="Waveforms: Resets - Jan 12. 2010" />
|
| 286 |
|
|
<br /><br />
|
| 287 |
|
|
|
| 288 |
|
|
<a name="4. Program Memory"></a>
|
| 289 |
|
|
<div style="text-align: right"><a href="#TOC">Top</a></div>
|
| 290 |
|
|
<h1>4. Program Memory</h1>
|
| 291 |
|
|
|
| 292 |
|
|
Depending on the project needs, the program memory can be either implemented as a ROM or RAM.<br />
|
| 293 |
|
|
<br />
|
| 294 |
|
|
If a ROM is selected then the <i>PMEM_DIN</i> and <i>PMEM_WEN</i> ports won't be connected. In that case, the software debug capabilities are limited because the serial debug interface can only use hardware breakpoints in order to stop the program execution. In addition, updating the software will require a reprogramming of the FPGA.<br />
|
| 295 |
|
|
<br />
|
| 296 |
|
|
If the program memory is a RAM, the developer gets full flexibility regarding software debugging. The serial debug interface can be used to update the program memory and software breakpoints can be used.<br />
|
| 297 |
|
|
<br /><br />
|
| 298 |
|
|
That said, the protocol between the openMSP430 and the program memory is quite standard. Signal description goes as following:
|
| 299 |
|
|
<ul>
|
| 300 |
|
|
<li><b><font color="#00b000">PMEM_CEN</font></b>: when this signal is active, the read/write access will be executed with the next <i>MCLK</i> rising edge. Note that this signal is LOW ACTIVE.
|
| 301 |
|
|
<br /><br />
|
| 302 |
|
|
</li>
|
| 303 |
|
|
<li>
|
| 304 |
|
|
<b><font color="#00b000">PMEM_ADDR</font></b>: Memory address of the 16 bit word which is going to be accessed.<br />
|
| 305 |
|
|
<b>Note:</b> in order to calculate the core logical address from the program memory physical address, the formula goes as following: <i>LOGICAL@=2*PHYSICAL@+0x10000-PMEM_SIZE</i>
|
| 306 |
|
|
<br /><br />
|
| 307 |
|
|
</li>
|
| 308 |
|
|
<li>
|
| 309 |
|
|
<b><font color="#0000b0">PMEM_DOUT</font></b>: the memory output word will be updated with every valid read/write access (i.e. <i>PMEM_DOUT</i> is not updated if <i>PMEM_CEN</i>=1).
|
| 310 |
|
|
<br /><br />
|
| 311 |
|
|
</li>
|
| 312 |
|
|
<li>
|
| 313 |
|
|
<b><font color="#00b000">PMEM_WEN</font></b>: this signal selects which byte should be written during a valid access. PMEM_WEN[0] will activate a write on the lower byte, PMEM_WEN[1] a write on the upper byte. Note that these signals are LOW ACTIVE.
|
| 314 |
|
|
<br /><br />
|
| 315 |
|
|
</li>
|
| 316 |
|
|
<li>
|
| 317 |
|
|
<b><font color="#00b000">PMEM_DIN</font></b>: the memory input word will be written with the valid write access according to the <i>PMEM_WEN</i> value.
|
| 318 |
|
|
<br /><br />
|
| 319 |
|
|
</li>
|
| 320 |
|
|
</ul>
|
| 321 |
|
|
The following waveform illustrates some read accesses of the program memory (write access are illustrated in the data memory section):<br /><br />
|
| 322 |
|
|
<img src="getimg.php?1263320706" width="100%" alt="Waveforms: Program memory - Jan " title="Waveforms: Program memory - Jan " />
|
| 323 |
|
|
<br /><br />
|
| 324 |
|
|
<a name="5. Data Memory"></a>
|
| 325 |
|
|
<div style="text-align: right"><a href="#TOC">Top</a></div>
|
| 326 |
|
|
<h1>5. Data Memory</h1>
|
| 327 |
|
|
|
| 328 |
|
|
The data memory is always implemented as a RAM.<br />
|
| 329 |
|
|
<br />
|
| 330 |
|
|
The protocol between the openMSP430 and the data memory is the same as the one of the program memory. Therefore, the signal description is the same:
|
| 331 |
|
|
<ul>
|
| 332 |
|
|
<li><b><font color="#00b000">DMEM_CEN</font></b>: when this signal is active, the read/write access will be executed with the next <i>MCLK</i> rising edge. Note that this signal is LOW ACTIVE.
|
| 333 |
|
|
<br /><br />
|
| 334 |
|
|
</li>
|
| 335 |
|
|
<li>
|
| 336 |
|
|
<b><font color="#00b000">DMEM_ADDR</font></b>: Memory address of the 16 bit word which is going to be accessed.<br />
|
| 337 |
|
|
<b>Note:</b> in order to calculate the core logical address from the data memory physical address, the formula goes as following: <i>LOGICAL@=2*PHYSICAL@+0x200</i>
|
| 338 |
|
|
<br /><br />
|
| 339 |
|
|
</li>
|
| 340 |
|
|
<li>
|
| 341 |
|
|
<b><font color="#0000b0">DMEM_DOUT</font></b>: the memory output word will be updated with every valid read/write access (i.e. <i>DMEM_DOUT</i> is not updated if <i>DMEM_CEN</i>=1).
|
| 342 |
|
|
<br /><br />
|
| 343 |
|
|
</li>
|
| 344 |
|
|
<li>
|
| 345 |
|
|
<b><font color="#00b000">DMEM_WEN</font></b>: this signal selects which byte should be written during a valid access. DMEM_WEN[0] will activate a write on the lower byte, DMEM_WEN[1] a write on the upper byte. Note that these signals are LOW ACTIVE.
|
| 346 |
|
|
<br /><br />
|
| 347 |
|
|
</li>
|
| 348 |
|
|
<li>
|
| 349 |
|
|
<b><font color="#00b000">DMEM_DIN</font></b>: the memory input word will be written with the valid write access according to the <i>DMEM_WEN</i> value.
|
| 350 |
|
|
<br /><br />
|
| 351 |
|
|
</li>
|
| 352 |
|
|
</ul>
|
| 353 |
|
|
The following waveform illustrates some read/write access to the data memory:<br /><br />
|
| 354 |
|
|
<img src="getimg.php?1263320770" width="100%" alt="Waveforms: Data memory - Jan 12." title="Waveforms: Data memory - Jan 12." />
|
| 355 |
|
|
<br /><br />
|
| 356 |
|
|
|
| 357 |
|
|
<a name="6. Peripherals"></a>
|
| 358 |
|
|
<div style="text-align: right"><a href="#TOC">Top</a></div>
|
| 359 |
|
|
<h1>6. Peripherals</h1>
|
| 360 |
|
|
|
| 361 |
|
|
The protocol between the openMSP430 core and its peripherals is the exactly same as the one with the data and program memories in regards to write access and differs slightly for read access.<br />
|
| 362 |
|
|
<br />
|
| 363 |
|
|
On the connectivity side, the specificity is that the read data bus of all peripherals should be ORed together before being connected to the core, as showed in the diagram of the <a href="#1. Overview">Overview</a> section.<br />
|
| 364 |
|
|
From the logical point of view, during a read access, each peripheral outputs the combinatorial value of its read mux and returns 0 if it doesn't contain the addressed register. On the waveforms, this translates by seeing the register value on <i>PER_DOUT</i> while <i>PER_EN</i> is valid and not one clock cycle afterwards as it is the case with the program and data memories.<br />
|
| 365 |
|
|
In any case, it is recommended to use the templates provided with the core in order to develop your own custom peripherals.<br />
|
| 366 |
|
|
The signal description therefore goes as following:
|
| 367 |
|
|
<ul>
|
| 368 |
|
|
<li><b><font color="#00b000">PER_EN</font></b>: when this signal is active, read access are executed during the current <i>MCLK</i> cycle while write access will be executed with the next <i>MCLK</i> rising edge. Note that this signal is HIGH ACTIVE.
|
| 369 |
|
|
<br /><br />
|
| 370 |
|
|
</li>
|
| 371 |
|
|
<li>
|
| 372 |
116 |
olivier.gi |
<b><font color="#00b000">PER_ADDR</font></b>: peripheral register address of the 16 bit word which is currently accessed. It is to be noted that a 14 bit address will always be provided from the openMSP430 to the peripheral in order to accommodate the biggest possible PER_SIZE Verilog configuration option (i.e. 32kB as opposed to 512B by default).<br />
|
| 373 |
50 |
olivier.gi |
<b>Note:</b> in order to calculate the core logical address from the peripheral register physical address, the formula goes as following: <i>LOGICAL@=2*PHYSICAL@</i>
|
| 374 |
|
|
<br /><br />
|
| 375 |
|
|
</li>
|
| 376 |
|
|
<li>
|
| 377 |
|
|
<b><font color="#0000b0">PER_DOUT</font></b>: the peripheral output word will be updated with every valid read/write access, it will be set to 0 otherwise.
|
| 378 |
|
|
<br /><br />
|
| 379 |
|
|
</li>
|
| 380 |
|
|
<li>
|
| 381 |
116 |
olivier.gi |
<b><font color="#00b000">PER_WE</font></b>: this signal selects which byte should be written during a valid access. PER_WE[0] will activate a write on the lower byte, PER_WE[1] a write on the upper byte. Note that these signals are HIGH ACTIVE.
|
| 382 |
50 |
olivier.gi |
<br /><br />
|
| 383 |
|
|
</li>
|
| 384 |
|
|
<li>
|
| 385 |
|
|
<b><font color="#00b000">PER_DIN</font></b>: the peripheral input word will be written with the valid write access according to the <i>PER_WEN</i> value.
|
| 386 |
|
|
<br /><br />
|
| 387 |
|
|
</li>
|
| 388 |
|
|
</ul>
|
| 389 |
|
|
The following waveform illustrates some read/write access to the peripheral registers:<br /><br />
|
| 390 |
|
|
<img src="getimg.php?1263320825" width="100%" alt="Waveforms: Peripherals - Jan 12." title="Waveforms: Peripherals - Jan 12." />
|
| 391 |
|
|
<br /><br />
|
| 392 |
|
|
|
| 393 |
|
|
|
| 394 |
|
|
<a name="7. Interrupts"></a>
|
| 395 |
|
|
<div style="text-align: right"><a href="#TOC">Top</a></div>
|
| 396 |
|
|
<h1>7. Interrupts</h1>
|
| 397 |
|
|
|
| 398 |
|
|
As with the original MSP430, the interrupt priorities of the openMSP430 are fixed in hardware accordingly to the connectivity of the <i>NMI</i> and <i>IRQ</i> ports.<br />
|
| 399 |
|
|
If two interrupts are pending simultaneously, the higher priority interrupt will be serviced first.<br />
|
| 400 |
|
|
The following table summarize this:<br /><br />
|
| 401 |
|
|
<table border="1">
|
| 402 |
|
|
<tr>
|
| 403 |
|
|
<td align="center"><b> Interrupt Port </b></td>
|
| 404 |
|
|
<td align="center"><b> Vector address </b></td>
|
| 405 |
|
|
<td align="center"><b> Priority </b></td>
|
| 406 |
|
|
</tr>
|
| 407 |
|
|
<tr>
|
| 408 |
|
|
<td align="center">RESET_N</td>
|
| 409 |
|
|
<td align="center">0xFFFE</td>
|
| 410 |
|
|
<td align="center">15 (highest)</td>
|
| 411 |
|
|
</tr>
|
| 412 |
|
|
<tr>
|
| 413 |
|
|
<td align="center">NMI</td>
|
| 414 |
|
|
<td align="center">0xFFFC</td>
|
| 415 |
|
|
<td align="center">14</td>
|
| 416 |
|
|
</tr>
|
| 417 |
|
|
<tr>
|
| 418 |
|
|
<td align="center">IRQ[13]</td>
|
| 419 |
|
|
<td align="center">0xFFFA</td>
|
| 420 |
|
|
<td align="center">13</td>
|
| 421 |
|
|
</tr>
|
| 422 |
|
|
<tr>
|
| 423 |
|
|
<td align="center">IRQ[12]</td>
|
| 424 |
|
|
<td align="center">0xFFF8</td>
|
| 425 |
|
|
<td align="center">12</td>
|
| 426 |
|
|
</tr>
|
| 427 |
|
|
<tr>
|
| 428 |
|
|
<td align="center">IRQ[11]</td>
|
| 429 |
|
|
<td align="center">0xFFF6</td>
|
| 430 |
|
|
<td align="center">11</td>
|
| 431 |
|
|
</tr>
|
| 432 |
|
|
<tr>
|
| 433 |
|
|
<td align="center">IRQ[10]</td>
|
| 434 |
|
|
<td align="center">0xFFF4</td>
|
| 435 |
|
|
<td align="center">10</td>
|
| 436 |
|
|
</tr>
|
| 437 |
|
|
<tr>
|
| 438 |
|
|
<td align="center">IRQ[9]</td>
|
| 439 |
|
|
<td align="center">0xFFF2</td>
|
| 440 |
|
|
<td align="center">9</td>
|
| 441 |
|
|
</tr>
|
| 442 |
|
|
<tr>
|
| 443 |
|
|
<td align="center">IRQ[8]</td>
|
| 444 |
|
|
<td align="center">0xFFF0</td>
|
| 445 |
|
|
<td align="center">8</td>
|
| 446 |
|
|
</tr>
|
| 447 |
|
|
<tr>
|
| 448 |
|
|
<td align="center">IRQ[7]</td>
|
| 449 |
|
|
<td align="center">0xFFEE</td>
|
| 450 |
|
|
<td align="center">7</td>
|
| 451 |
|
|
</tr>
|
| 452 |
|
|
<tr>
|
| 453 |
|
|
<td align="center">IRQ[6]</td>
|
| 454 |
|
|
<td align="center">0xFFEC</td>
|
| 455 |
|
|
<td align="center">6</td>
|
| 456 |
|
|
</tr>
|
| 457 |
|
|
<tr>
|
| 458 |
|
|
<td align="center">IRQ[5]</td>
|
| 459 |
|
|
<td align="center">0xFFEA</td>
|
| 460 |
|
|
<td align="center">5</td>
|
| 461 |
|
|
</tr>
|
| 462 |
|
|
<tr>
|
| 463 |
|
|
<td align="center">IRQ[4]</td>
|
| 464 |
|
|
<td align="center">0xFFE8</td>
|
| 465 |
|
|
<td align="center">4</td>
|
| 466 |
|
|
</tr>
|
| 467 |
|
|
<tr>
|
| 468 |
|
|
<td align="center">IRQ[3]</td>
|
| 469 |
|
|
<td align="center">0xFFE6</td>
|
| 470 |
|
|
<td align="center">3</td>
|
| 471 |
|
|
</tr>
|
| 472 |
|
|
<tr>
|
| 473 |
|
|
<td align="center">IRQ[2]</td>
|
| 474 |
|
|
<td align="center">0xFFE4</td>
|
| 475 |
|
|
<td align="center">2</td>
|
| 476 |
|
|
</tr>
|
| 477 |
|
|
<tr>
|
| 478 |
|
|
<td align="center">IRQ[1]</td>
|
| 479 |
|
|
<td align="center">0xFFE2</td>
|
| 480 |
|
|
<td align="center">1</td>
|
| 481 |
|
|
</tr>
|
| 482 |
|
|
<tr>
|
| 483 |
|
|
<td align="center">IRQ[0]</td>
|
| 484 |
|
|
<td align="center">0xFFE0</td>
|
| 485 |
|
|
<td align="center">0 (lowest)</td>
|
| 486 |
|
|
</tr>
|
| 487 |
|
|
</table>
|
| 488 |
|
|
<br /><br />
|
| 489 |
|
|
The signal description goes as following:
|
| 490 |
|
|
<ul>
|
| 491 |
|
|
<li>
|
| 492 |
|
|
<b><font color="#0000b0">NMI</font></b>: The <b>N</b>on-<b>M</b>askable <b>I</b>nterrupt has higher priority than other IRQs and is masked by the NMIIE bit instead of GIE.<br />
|
| 493 |
|
|
It is internally synchronized to the <i>MCLK</i> domain and can therefore be connected to any asynchronous signal of the chip (which could for example be a pin of the FPGA). If unused, this signal should be connected to 0.
|
| 494 |
|
|
<br /><br />
|
| 495 |
|
|
</li>
|
| 496 |
|
|
<li>
|
| 497 |
|
|
<b><font color="#0000b0">IRQ</font></b>: The standard interrupts can be connected to any signal coming from the <i>MCLK</i> domain (typically a peripheral). Priorities can be chosen by selecting the proper bit of the <i>IRQ</i> bus as shown in the table above. Unused interrupts should be connected to 0.<br />
|
| 498 |
|
|
<b>Note</b>: <i>IRQ[10]</i> is internally connected to the Watchdog interrupt. If this bit is also used by an external peripheral, they will both share the same interrupt vector.
|
| 499 |
|
|
<br /><br />
|
| 500 |
|
|
</li>
|
| 501 |
|
|
<li>
|
| 502 |
|
|
<b><font color="#00b000">IRQ_ACC</font></b>: Whenever an interrupt request is serviced, some peripheral automatically clear their pending flag in hardware. In order to do so, the <i>IRQ_ACC</i> bus can be used by using the bit matching the corresponding <i>IRQ</i> bit. An example of this is shown in the implementation of the TACCR0 Timer A interrupt.
|
| 503 |
|
|
<br /><br />
|
| 504 |
|
|
</li>
|
| 505 |
|
|
</ul>
|
| 506 |
|
|
The following waveform illustrates a TAIV interrupt issued by the Timer-A, which is connected to <i>IRQ[8]</i> :<br /><br />
|
| 507 |
|
|
<img src="getimg.php?1263320861" width="100%" alt="Waveforms: Interrupts - Jan 12. " title="Waveforms: Interrupts - Jan 12. " />
|
| 508 |
|
|
|
| 509 |
|
|
<br /><br />
|
| 510 |
|
|
|
| 511 |
|
|
|
| 512 |
|
|
<a name="8. Serial Debug Interface"></a>
|
| 513 |
|
|
<div style="text-align: right"><a href="#TOC">Top</a></div>
|
| 514 |
|
|
<h1>8. Serial Debug Interface</h1>
|
| 515 |
|
|
|
| 516 |
|
|
The serial debug interface module provides a two-wires communication bus for remote debugging and an additional freeze signal which might be useful for some peripherals.<br />
|
| 517 |
|
|
<br />
|
| 518 |
|
|
<ul>
|
| 519 |
|
|
<li>
|
| 520 |
116 |
olivier.gi |
<b><font color="#0000b0">DBG_EN</font></b>: this signal allows the user to enable or disable the serial debug interface without interfering with the CPU execution. It is to be noted that when disabled (i.e. DBG_EN=0), the debug interface is held into reset.
|
| 521 |
|
|
<br /><br />
|
| 522 |
|
|
</li>
|
| 523 |
|
|
<li>
|
| 524 |
50 |
olivier.gi |
<b><font color="#00b000">DBG_FREEZE</font></b>: this signal will be set whenever the debug interface stops the CPU (and if the <i>FRZ_BRK_EN</i> field of the <a href="http://www.opencores.org/project,openmsp430,serial%20debug%20interface#2.2.2%20CPU_CTL">CPU_CTL</a> debug register is set). As its name implies, the purpose of <i>DBG_FREEZE</i> is to freeze a peripheral whenever the CPU is stopped by the software debugger.<br />
|
| 525 |
|
|
For example, it is used by the Watchdog timer in order to stop its free-running counter. This prevents the CPU from being reseted by the watchdog every times the user stops the CPU during a debugging session.
|
| 526 |
|
|
<br /><br />
|
| 527 |
|
|
</li>
|
| 528 |
|
|
<li>
|
| 529 |
|
|
<b><font color="#00b000">DBG_UART_TXD</font> / <font color="#0000b0">DBG_UART_RXD</font></b>: these signals are typically connected to an RS-232 transceiver and will allow a PC to communicate with the openMSP430 core.
|
| 530 |
|
|
<br /><br />
|
| 531 |
|
|
</li>
|
| 532 |
|
|
</ul>
|
| 533 |
|
|
The following waveform shows some communication traffic on the serial bus :<br /><br />
|
| 534 |
|
|
<img src="getimg.php?1263320887" width="100%" alt="Waveforms: SDI - Jan 12. 2010" title="Waveforms: SDI - Jan 12. 2010" />
|
| 535 |
|
|
<br /><br />
|
| 536 |
|
|
</body>
|
| 537 |
|
|
</html>
|
