LPC2131/2132/2138 User Manual - mct.net

More documents

Recommendations

Info

Philips Semiconductors Preliminary User Manual ARM-based Microcontroller Figure 54: Map of lower memory after reset LPC2131/2132/2138 Criterion for valid user code: The reserved ARM interrupt vector location (0x0000 0014) should contain the 2’s complement of the check-sum of the remaining interrupt vectors. This causes the checksum of all of the vectors together to be 0. The boot loader code disables the overlaying of the interrupt vectors from the boot block, then checksums the interrupt vectors in sector 0 of the flash. If the signatures match then the execution control is transferred to the user code by loading the program counter with 0x 0000 0000. Hence the user flash reset vector should contain a jump instruction to the entry point of the user application code. If the signature is not valid, the auto-baud routine synchronizes with the host via serial port 0. The host should send a ’?’ (0x3F) as a synchronization character and wait for a response. The host side serial port settings should be 8 data bits, 1 stop bit and no parity. The auto-baud routine measures the bit time of the received synchronization character in terms of its own frequency and programs the baud rate generator of the serial port. It also sends an ASCII string ("Synchronized") to the Host. In response to this host should send the same string ("Synchronized"). The auto-baud routine looks at the received characters to verify synchronization. If synchronization is verified then "OK" string is sent to the host. Host should respond by sending the crystal frequency (in KHz) at which the part is running. For example, if the part is running at 10 MHz , the response from the host should be "10000". "OK" string is sent to the host after receiving the crystal frequency. If synchronization is not verified then the auto-baud routine waits again for a synchronization character. For auto-baud to work correctly, the crystal frequency should be greater than or equal to 10 MHz. The on-chip PLL is not used by the boot code. Once the crystal frequency is received the part is initialized and the ISP command handler is invoked. For safety reasons an "Unlock" command is required before executing the commands resulting in flash erase/write operations and the "Go" command. The rest of the commands can be executed without the unlock command. The Unlock command is required to be executed once per ISP session. The Unlock command is explained in "ISP Commands" section. Communication Protocol All ISP commands should be sent as single ASCII strings. Strings should be terminated with Carriage Return (CR) and/or Line Feed (LF) control characters. Extra and characters are ignored. All ISP responses are sent as terminated ASCII strings. Data is sent and received in UU-encoded format. ISP Command Format "Command Parameter_0 Parameter_1 ... Parameter_n" "Data" (Data only for Write commands) ISP Response Format 2.0 GB 2.0 GB - 12KB 0.0 GB Note: memory regions are not drawn to scale. 12K byte Boot Block (re-mapped from top of Flash memory) (Boot Block interrupt vectors) (12k byte Boot Block re-Mapped to higher address range) On-chip Flash Memory Active interrupt vectors from the Boot Block 0x7FFF FFFF 0x7FFF D000 0x000x FFFF 0x0007 D000 0x0000 0000 "Return_CodeResponse_0Response_1 ... Response_n" "Data" (Data only for Read commands) Flash Memory System and Programming 226 November 22, 2004
Philips Semiconductors Preliminary User Manual ARM-based Microcontroller ISP Data Format LPC2131/2132/2138 The data stream is in UU-encode format. The UU-encode algorithm converts 3 bytes of binary data in to 4 bytes of printable ASCII character set. It is more efficient than Hex format which converts 1 byte of binary data in to 2 bytes of ASCII hex. The sender should send the check-sum after transmitting 20 UU-encoded lines. The length of any UU-encoded line should not exceed 61 characters(bytes) i.e. it can hold 45 data bytes. The receiver should compare it with the check-sum of the received bytes. If the check-sum matches then the receiver should respond with "OK" to continue further transmission. If the check-sum does not match the receiver should respond with "RESEND". In response the sender should retransmit the bytes. A description of UU-encode is available at http://www.wotsit.org. ISP Flow control A software XON/XOFF flow control scheme is used to prevent data loss due to buffer overrun. When the data arrives rapidly, the ASCII control character DC3 (stop) is sent to stop the flow of data. Data flow is resumed by sending the ASCII control character DC1 (start). The host should also support the same flow control scheme. ISP Command Abort Commands can be aborted by sending the ASCII control character "ESC". This feature is not documented as a command under "ISP Commands" section. Once the escape code is received the ISP command handler waits for a new command. Interrupts during ISP The boot block interrupt vectors located in the boot block of the flash are active after any reset. Interrupts during IAP The on-chip flash memory is not accessible during erase/write operations. When the user application code starts executing the interrupt vectors from the user flash area are active. The user should either disable interrupts, or ensure that user interrupt vectors are active in RAM and that the interrupt handlers reside in RAM, before making a flash erase/write IAP call. The IAP code does not use or disable interrupts. RAM used by ISP command handler ISP commands use on-chip RAM from 0x4000 0120 to 0x4000 01FF. The user could use this area, but the contents may be lost upon reset. Flash programming commands use the top 32 bytes of on-chip RAM. The stack is located at RAM top - 32. The maximum stack usage is 256 bytes and it grows downwards. RAM used by IAP command handler Flash programming commands use the top 32 bytes of on-chip RAM. The maximum stack usage in the user allocated stack space is 128 bytes and it grows downwards. RAM used by RealMonitor The RealMonitor uses on-chip RAM from 0x4000 0040 to 0x4000 011F. he user could use this area if RealMonitor based debug is not required. The Flash boot loader does not initialize the stack for RealMonitor. Flash Memory System and Programming 227 November 22, 2004
Page 1 and 2:
Philips Semiconductors INTEGRATED C
Page 3 and 4:
Philips Semiconductors Preliminary
Page 5 and 6:
Page 7 and 8:
Page 9 and 10:
Page 11 and 12:
Page 13 and 14:
Page 15 and 16:
Page 17 and 18:
Page 19 and 20:
Page 21 and 22:
Page 23 and 24:
Page 25 and 26:
Page 27 and 28:
Page 29 and 30:
Page 31 and 32:
Page 33 and 34:
Page 35 and 36:
Page 37 and 38:
Page 39 and 40:
Page 41 and 42:
Page 43 and 44:
Page 45 and 46:
Page 47 and 48:
Page 49 and 50:
Page 51 and 52:
Page 53 and 54:
Page 55 and 56:
Page 57 and 58:
Page 59 and 60:
Page 61 and 62:
Page 63 and 64:
Page 65 and 66:
Page 67 and 68:
Page 69 and 70:
Page 71 and 72:
Page 73 and 74:
Page 75 and 76:
Page 77 and 78:
Page 79 and 80:
Page 81 and 82:
Page 83 and 84:
Page 85 and 86:
Page 87 and 88:
Page 89 and 90:
Page 91 and 92:
Page 93 and 94:
Page 95 and 96:
Page 97 and 98:
Page 99 and 100:
Page 101 and 102:
Page 103 and 104:
Page 105 and 106:
Page 107 and 108:
Page 109 and 110:
Page 111 and 112:
Page 113 and 114:
Page 115 and 116:
Page 117 and 118:
Page 119 and 120:
Page 121 and 122:
Page 123 and 124:
Page 125 and 126:
Page 127 and 128:
Page 129 and 130:
Page 131 and 132:
Page 133 and 134:
Page 135 and 136:
Page 137 and 138:
Page 139 and 140:
Page 141 and 142:
Page 143 and 144:
Page 145 and 146:
Page 147 and 148:
Page 149 and 150:
Page 151 and 152:
Page 153 and 154:
Page 155 and 156:
Page 157 and 158:
Page 159 and 160:
Page 161 and 162:
Page 163 and 164:
Page 165 and 166:
Page 167 and 168:
Page 169 and 170:
Page 171 and 172:
Page 173 and 174:
Page 175 and 176: Philips Semiconductors Preliminary
Page 225: Philips Semiconductors Preliminary
show all

LPC2131/2132/2138 User Manual - mct.net

Create successful ePaper yourself

Delete template?

Save as template?