Для установки защиты необходимо по адресу 0x1FC Flash памяти разместить 
специальный ключ, 32 битное слово 0x87654321. Однако сделать это прямо 
в компиляторе вам не удастся, так как распределением занимается линкер. 

Не поможет и указание компилятору специфичного для IAR расширения "@", 
означающего размещение по фиксированному адресу, т.к. оно неприменимо 
для инициализированных переменных и констант. 

Выходом из положения является создание ассемблерного файла, определяющего 
новый сегмент кода и размещающего в нем одно единственное слово 0x87654321. 
А чтобы линкер поместил этот сегмент по нужному нам адресу 0x1FC немного 
модифицируем XCL файл линкера. 

Тестовый проект по ссылке. 
Обратить внимание на файл prot.s79 и 123-ую строку flash.xcl

P.S. На мой взгляд, способ размещения через дополнительный сегмент 
является более правильным, т.к. с незначительными изменениями может быть
использован в любых компиляторах. Однако для IAR есть способ проще - 
разместить в любом из С файлов проекта строку 
__root const unsigned int protectKey @ 0x1FC = 0x87654321;
                                                                 DASM

   Кое-что есть на arm.com - ссылка
   Кое-что есть на сахаре - ссылка

В соответствии с информацией компании Philips Semiconductors,
рекомендуется обновить программу начальной загрузки (bootloader) в
ARM микроконтроллерах семейства LPC2000 версиями бутлоадера
V1.52 или V1.63, если коды даты выпуска микроконтроллера
меньше, чем в приведенном ниже перечне:

LPC2104 All date codes prior to 0425 V1.52
LPC2105 All date codes prior to 0426 V1.52
LPC2106 All date codes prior to 0419 V1.52
LPC2114 All date codes prior to 0420 V1.63
LPC2119 All date codes prior to 0420 V1.63
LPC2124 All date codes prior to 0423 V1.63
LPC2129 All date codes prior to 0425 V1.63
LPC2194 All date codes prior to 0424 V1.63
LPC22xx All date codes prior to 0424 V1.63

Примечание: код даты выпуска, например, 0419 означает, что
микроконтроллер произведен на 19 неделе в 2004 году
(04-год, 19-неделя года). Проблема связана с проявляющейся в ряде
случаев некорректной работой функции In Application Programming (IAP),
которая является частью бутлоадера и контролирует процессы
программирования Flash-памяти микроконтроллера с использованием всех
методов (JTAG, ISP и IAP). Проблема проявляется в следующем. В случае,
если ядро процессора работает на частоте более 12МГц, то до 10%
микроконтроллеров LPC2xxx, в которых версия бутлоадера меньше
1.52 (LPC2104/2105/2106) или
меньше 1.63 (LPC2114/2119/2124/2129/2194/LPC2212/2214/2292/2294),
не могут выйти из процедуры IAP после обращения к ней. Вместе с тем
Philips отмечает, что микроконтроллеры, в которых IAP процедура
функционирует (очевидно, при работе ядра на частотах до 60 МГц),
не относятся к числу проблемных микроконтроллеров.

Предлагается два способа решения проблемы:
1. Ограничить внешнюю опорную частоту до 12МГц и выключать PLL во время
   программирования (или стирания) Flash-памяти, что позволит значительно
   уменьшить вероятность возникновения проблемы.
   Примечание: при выполнении ISP процедуры PLL отключается по умолчанию.

2. Воспользоваться новой версией бутлоадера - это более
   радикальное решение. Необходимо строго следовать инструкции,
   в противном случае микроконтроллер может быть выведен из строя.
   Загрузку бутлоадера рекомендуется осуществлять с помощью
   программы-загрузчика Philips Flash ISP Utility через последовательный
   порт. С её помощью можно также прочитать прошитую в MCU версию
   бутлоадера.
   Информация по этой проблеме содержится также в последних версиях
   Errata Sheet для микроконтроллеров семейства LPC2000. Ознакомиться
   с ними Вы можете здесь или здесь

   Компания Philips сообщила о реализации защиты Flash-памяти от
   несанкционированного чтения в микроконтроллерах серии
   LPC2114/2119/2124/2129/2194/2212/2214/2292/2294 c бутлоадером,
   начиная с версии 1.61.
   Функция защиты осуществляется путем записи значения 0x87654321
   по адресу 0x1FC во Flash-память. В этом случае отключаются функции
   JTAG-интерфейса и начальная загрузка данных из внешней памяти.
   Также становятся недоступны следующие команды в режиме In-System Programming (ISP):
   -Чтение Flash-памяти
   -Запись в ОЗУ
   -Копирование данных из ОЗУ во Flash-память
   В ISP режиме команда стирания инициализирует удаление всей информации
   с пользовательских секторов Flash-памяти.
   Информация о защите Flash-памяти содержится в User Manual
   LPC2114/2124/2212/2214 - стр.224
   LPC2119/2129/2194/2292/2294 - стр.269

   По минимуму - два источника питания (3.3В и 1.8В) с фильтровыми
   конденсаторами на каждую пару ног питания (одна пара 1.8В, две пары на
   3.3В), кварц 10...25МГц, цепочка сброса. Для корректной работы
   загрузчика надо дополнительно подключить UART0 и кнопку на P0.14. Для
   корректной работы JTAG надо дополнительно подключить JTAG0
   (P0.17...P0.21), и джампер на DBGSEL (1-отладка, 0-норма).

   P0.17...P0.31. Это указано в User Manual, раздел "EMBEDDED ICE LOGIC".

   При использовании Wiggler кабель на LPT до 2.5 метров и кабель
   на процессор до 20 см.

   Если все соединения в норме, питание подано, то попробуйте десяток раз
   надавить "Retry". Если все равно не помогает, снизьте скорость работы.
   При использовании Wiggler это происходит достаточно часто.
   ... у меня в Multi2000 такого с вигглером (2 разъема с проводами) неразу
       не происходило - nvn
   ... видимо, это свойство ИАРа или драйверов, прилагаемых к ИАРу. - undefined

   Texas Inst. TPS76318 для 1.8В и TPS76333 для 3.3В. На 3.3В широко
   распространена также LM1117.
   ... Ну а я применил MAX8863. Корпус маленький, два внешних резистора
       задают напряжение... показалось удобно. - Alexey_N

   IAR EWARM. Широко известная унифицированная среда,
   хорошо обновляется, простые правила работы, легко доступна,
   поддерживает Wiggler. Демоверсия доступна онлайн.

   ------------------Другие известные пакеты----------------------

   ARM ADS с оболочкой Metrowerks CodeWarrior.
   Поддержка простейших JTAG адаптеров: Byteblaster. Не поддерживает
   Wiggler.

   ARM RealView.
   Новый пакет от ARM, старый ADS поглощен им.
   Поддержка простейших JTAG адаптеров: нет.
   Демоверсию высылают по почте при заполнении формы.

   Green Hills MULTI.
   Поддержка простейших JTAG адаптеров: Wiggler.
   Демоверсию высылают по почте.

   MetaWare.
   Оболочки нет?
   Поддержка простейших JTAG адаптеров: Wiggler.

   GNU GCC Tools. Бесплатный компилятор под Linux. Может запускаться под
   Win.
   Отладчика нет? Оболочки нет?
   Полная версия с исходниками доступна онлайн.

   Keil software. GNU GCC Tools адаптированные Keil software под свою
   оболочку с отладчиком.
   Содержит в себе независимый дистрибутив GCC под Win .
   Поддержка простейших JTAG адаптеров: ?.
   Демоверсия доступна онлайн.

   ... хочется сразу заметить gnu тулзы названые "адаптированными";
       являются старым добрым GNUPRO http://www.redhat.com/software/gnupro/  (это gcc+newlib)

       при этом лучше всего они адаптированы в CrossWorks http://www.rowley.co.uk/
       по моему мнению - лучшая система разработки для LPC.
       А вообще там (в gnu проектах) сред немеряно,
       и gdb (insight если нужны картинки) должен работать с wiggler-oм
      (на сайте виглера об этом написано).- yes

   Принципиально доступны два пути программирования кристалла: первый -
   через JTAG; второй - через UART0 средствами встроенного загрузчика.

   О заливке через JTAG. Через JTAG программу можно залить в ОЗУ (для
   отладочных целей). Это могут делать любые отладчики без специальных
   ухищрений. Нужно лишь при линковке прописать размещение кода
   программы в ОЗУ.
   Записать программу во Flash через JTAG пока можно только одним
   способом - написав промежуточный код загрузчика который исполняется
   в ОЗУ и пишет вашу программу во флешь. Так поступает, например,
   IAR EWARM версий 4.хх.

   О заливке через бутлоадер При поставке кристалл прошит загрузчиком
   (bootloader), который получает управление при аппаратном сбросе и по
   определенным признакам принимает решение - отдать управление
   программе пользователя или не стоит.
   Этих признаков два - состояние ноги P0.14 в момент сброса и
   корректная CRC программы пользователя.
   Загрузчик работает через порт UART0 и имеет автодетект скорости.
   Исчерпывающее описание протокола загрузчика и его работы приведено в
   LPC2100 Manual.

   Филипс бесплатно распространяет программу под Windows, которая
   именуется ISP. Она умеет загружать программу во Flash и запускать ее
   на исполнение.

   Загрузчик не умеет грузить программу в ОЗУ, однако, при смене версии
   bootloader'а, код загружается именно в ОЗУ и ему передается управление.
   Он (загрузчик) , как утверждается Филипсом, не имеет также никаких
   функций мониторинга или отладки.

   Бутлоадер сидит во Flash и вполне доступен для стирания ))). Если в
   результате отладки Вы его затерли, то единственный способ вернуть
   контроль над кристаллом - через JTAG.

   Это ошибка. Бутлоадер запускает нога P0.16. Это выяснено опытным
   путем на имеющихся кристаллах lpc210х. На остальных кристаллах
   bootloader запускается сигналом на P0.14.
   Внимание! Похоже гуляет две версии кристалла lpc210x - старый с ногой
   P0.16 и новый - c ногой P0.14

   Если хочется иметь полноценную отладку кода, залитого во Flash,
   то действия немного усложняются:
   Скомпилируйте проект в HEX-файл и залейте его во Flash средствами
   прошивки Flash (через бутлоадер).
   Поменяйте в проекте выходной формат на отладочный и запустите отладчик.
   Отладчик конечно не сможет прошить Flash, но ведь там уже все прошито, и
   он не заметит обмана...
   При наличии версии IAR EWARM 4.xx действия несколько изменяются, так как
   он самостоятельно может загрузить код во flash. Подробно эта процедура
   описана в разделе C-SPY driver-specific characteristics на стр. 187(219)
   документа EWARM_UserGuide.pdf идущего в комплекте с IAR. В случае неудачной
   загрузки рекомендуется обновить версию bootloader'а. Если и это не поможет,
   то остается действовать как указано выше, только можно воспользоваться
   возможностью IAR одновременно генерировать два выходных файла разных
   форматов дабы избежать частой смены опций проекта.

   При использовании основного JTAG (ножки P0.17..P0.21) также
   включается отладочный механизм "EMBEDDED ICE LOGIC", в результате
   чего выводы P0.22..P0.31 становятся недоступными при отладке.
   Этого можно избежать, если воспользоваться вторым JTAG, имеющимся
   в кристалле. Он занимает ножки P0.27..P0.31 и при отладке через
   него все остальные выводы доступны, включая и ноги первого JTAG.
   Для отладки через него не требуется использовать вывод DBGSEL.
   Единственное требование - процессор после включения должен в своей
   программе разрешить использование второго JTAG.
   Для этого достаточно написать простейшую программу, где при
   инициализации контроллера выполняется строка вида
   "PINSEL1 = (1 << 22) | (1 << 24) | (1 << 26) | (1 << 28) | (1 << 30);"
   Согласно стр.79 User Manual это и даст доступ ко второму JTAG.
   Программу с этой строчкой после компиляции зашить стандартным
   способом через UART0. Естественно, если есть желание в реальных
   программах иметь доступ к такой отладке, эти биты PINSEL1 должны
   оставаться настроенными именно таким образом.
   ссылка

   User Manual рекомендует от 10 до 25 МГц, но для корректного
   использования UART лучше использовать "стандартные"
   11.0592 или 14.7456 Мгц.

   При правильных настройках MEMORY ACCELERATOR MODULE у меня
   производительность снижалась очень незначительно,
   составляя примерно 90 процентов от исполнения кода из ОЗУ.
   Типичная процедура настройки акселератора  и PLL такова:

   MAMCR = 2;  //разрешим полное использование MAM
   MAMTIM = 3; //3 цикла ожидания при выборке из флеш
   PLLCON = 1; //разрешим PLL но не подключаем ее к ядру
   PLLCFG = 5; //см. стр 48 User Manual (UM). 5 дает умножение частоты
               //кварца на 5+1 = 6. При частоте кварца 11.0592 Мгц
               //частота PLL будет 11.059 * 6 = 66.35 Мгц
   PLLFEED = 0xAA; PLLFEED = 0x55; // см 46 стр UM
   while (!(PLLSTAT & (1 << 10))); // подождем, пока PLL войдет в захват
   PLLCON = 3; // подключим PLL к ядру
   PLLFEED = 0xAA; PLLFEED = 0x55; // см 46 стр UM