Как программить flash в LPC без IAP ? Опции

[VLM]

Информация низкоуровнего доступа к внутренней flash микроконтроллеров от NXP явлается секретом. А также является секретом как первоначально прошивается bootloader на предприятии изготавливающем эти чипы.
Поэтому я был бы весьма признателен, если конить поможет пролить свет на эти "секреты". Ведь производитель некоторых программ загрузчиов имеют представление как в LPC программить flash без IAP. Помогите кто может!

[zltigo]

Поэтому я был бы весьма признателен, если конить поможет пролить свет на эти "секреты".

Зачем?

Ведь производитель некоторых программ загрузчиов имеют представление как в LPC программить flash без IAP.

Поограммы загрузчики загружают код работающий через IAP, что позволяет им работать по документированнму интерфейсу. Чего и Вам желаю.

[VLM]

Зачем?

Поограммы загрузчики загружают код работающий через IAP, что позволяет им работать по документированнму интерфейсу. Чего и Вам желаю.

Зачем - чтобы сделать хорошую защиту кода. Второе - если есть возможность с помощью загрузкика обновить версию bootload , то наверняка перед записью нового старый полностью затирается. Это предпологает, что загрузчик копирует или грузи в RAM те функции через которые потом программирует новую версию. Чтобы сделать хорошую защиту кода - надо сделать свой загрузчик(ни кому не известный) заместо штатного, или не дать возможность после резета отрабатывать штатному. Для этого мне и нужно либо знать как работать с flash на низком уровне или иметь проттотипы функций IAP, что вобщемто одно и тоже.

А почему хотите избавиться от IAP? Чем не устраивает?
Немного про устройство загрузчиков есть здесь
P.S. Я бы тоже не отказался узнать как ведет себя контроллер с полностью чистым флешем - срабатывает ли CRP и не блокируется ли доступ по JTAG.

По всей видимотси контроллер с чистым флешем ни как себя не ведёт, и наверное в этом случае имеется возможность только параллельного программирования, когда ядро контроллера не работает. Но это мои догадки. И если это так, то полностью защитить свой код во флеше нет.

[zltigo]

Зачем - чтобы сделать хорошую защиту кода.

Разработчики от NXP хотели сделать плохую, или хорошую, но у них не хватило информации и квалификации

...или не дать возможность после резета отрабатывать штатному. Для этого мне и нужно либо знать как работать с flash на низком уровне или иметь проттотипы функций IAP, что вобщемто одно и тоже.

Маниакальные идеи . Впрочем, для этого ничего из вышеописанного знать не нужно - просто подправить одно словечко в штатном загрузчике - переход на конгениальную сверхнеломаемую самоделку, вместо штатного.

[VslavX]

Разработчики от NXP хотели сделать плохую, или хорошую, но у них не хватило информации и квалификации

ИМХО, ирония здесь несколько неуместна. Разработчики кристаллов почти никогда (за исключением специальных случаев, когда разрабатывается защищенная система) не заморачиваются защитой кода клиентов, CRP - это просто "бесплатный бонус. Есть - и ладно, но никто ничего не гарантирует, даже "на словах".
Навскидку - два примера:
- еще 5 лет назад я изучал загрузчик MSP430F149, прошитый в ROM. Там была найдена дыра, сегодня известная как баг "BSL03", о чем Texas был поставлен в известность. F149-й до сих пор выпускается с этой "дырой" и успешно не применяется в моих изделиях.
- "дыра" в загрузчиках для тех же LPC21xx - в версиях до 1.64 включительно также хорошо известна (даже обсуждалась у нас на форуме) и отлично свидетельствует об избытке "квалификации и информации" у разработчиков NXP. И не факт, что там (и в других загрузчиках от NXP) больше не осталось таких проблемных мест.
Далее - загрузчик от NXP, с известным протоколом и с отсутствующей криптографией, легко обойти применяя несложные методы социальной инженерии и некоторое знание психологии. Не кражей, не подкупом, не шантажом и не другими некрасивыми методами, а просто основываяясь на невнимательности сервисников/ремонтников.
Поэтому разработка своего загрузчика достаточно актуальна, притом что, например, в моей компании cуществует более чем 10-летняя традиция использования своего протокола и методики криптозащиты, которые к тому же составляют заметную часть функциональности изделий. И замалчивание деталей программирования флеша со стороны NXP вызывает недоумение и некоторое раздражение, тем что вынуждает заниматься реверс-инжинирингом (со временем я стал находить дизассемблирование все более и более скучным занятием ).
Вот такие у меня 5 коп