LPC1769FBD100,551 NXP Semiconductors, LPC1769FBD100,551 Datasheet - Page 617

• Manufacturer Part Number: LPC1769FBD100,551
• Description: IC ARM CORTEX MCU 512K 100-LQFP
• Manufacturer: NXP Semiconductors
• Series: LPC17xxr

Specifications of LPC1769FBD100,551

• Program Memory Type: FLASH
• Program Memory Size: 512KB (512K x 8)
• Package / Case: 100-LQFP
• Core Processor: ARM® Cortex-M3™
• Core Size: 32-Bit
• Speed: 120MHz
• Connectivity: CAN, Ethernet, I²C, IrDA, Microwire, SPI, SSI, UART/USART, USB OTG
• Peripherals: Brown-out Detect/Reset, DMA, I²S, Motor Control PWM, POR, PWM, WDT
• Number Of I /o: 70
• Ram Size: 64K x 8
• Voltage - Supply (vcc/vdd): 2.4 V ~ 3.6 V
• Data Converters: A/D 8x12b, D/A 1x10b
• Oscillator Type: Internal
• Operating Temperature: -40°C ~ 85°C
• Processor Series: LPC17
• Core: ARM Cortex M3
• Data Bus Width: 32 bit
• Data Ram Size: 64 KB
• Interface Type: Ethernet, USB, OTG, CAN
• Maximum Clock Frequency: 120 MHz
• Number Of Programmable I/os: 70
• Number Of Timers: 4
• Operating Supply Voltage: 3.3 V
• Maximum Operating Temperature: + 85 C
• Mounting Style: SMD/SMT
• 3rd Party Development Tools: MDK-ARM, RL-ARM, ULINK2, MCB1760, MCB1760U, MCB1760UME
• Minimum Operating Temperature: - 40 C
• On-chip Adc: 12 bit, 8 Channel
• On-chip Dac: 10 bit
• Lead Free Status / RoHS Status: Lead free / RoHS Compliant
• For Use With: 622-1005 - USB IN-CIRCUIT PROG ARM7 LPC2K
• Eeprom Size: -
• Lead Free Status / Rohs Status: Lead free / RoHS Compliant
• Other names: 568-4966; 935290522551

NXP Semiconductors
UM10360
User manual
32.3.2.1 ISP command format
32.3.2.2 ISP response format
32.3.2.3 ISP data format
32.3.2 Communication protocol
sends an ASCII string ("Synchronized<CR><LF>") to the host. In response to this the host
should send the same string ("Synchronized<CR><LF>"). The auto-baud routine looks at
the received characters to verify synchronization. If synchronization is verified then
"OK<CR><LF>" string is sent to the host. The 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<CR><LF>". "OK<CR><LF>" 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 in case of user invoked ISP, the CCLK frequency should be greater than or equal
to 10 MHz.
For more details on Reset, PLL and startup/boot code interaction see
“PLL0 and startup/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
Section 32.7 “ISP commands” on page
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 <CR> and
<LF> characters are ignored. All ISP responses are sent as <CR><LF> terminated ASCII
strings. Data is sent and received in UU-encoded format.
"Command Parameter_0 Parameter_1 … Parameter_n<CR><LF>" "Data" (Data only for
Write commands).
"Return_Code<CR><LF>Response_0<CR><LF>Response_1<CR><LF> …
Response_n<CR><LF>" "Data" (Data only for Read commands).
The data stream is in UU-encoded 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<CR><LF>" to continue
further transmission. If the check-sum does not match the receiver should respond with
"RESEND<CR><LF>". In response the sender should retransmit the bytes.
All information provided in this document is subject to legal disclaimers.
Chapter 32: LPC17xx Flash memory interface and programming
Rev. 2 — 19 August 2010
interaction”.
623.
UM10360
Section 4.5.1.1
© NXP B.V. 2010. All rights reserved.
617 of 840