Здравствуйте форумчане! Прошу помочь, т.к. уже не знаю что делать...

Пишу внутрисистемный (ISP) программатор для LPC 2366, и столкнулся с тем, что в процессе прошивки не получается стереть полностью весь флэш, адреса с 0x00 по 0x40 зарезервированы под вектора прерываний. При форматировании всего флэша посредством ISP-команды "E 0 14\r\n" в этом диапазоне остается что-то, все остальное как и положено - FF.

Согласно hex-файлу прошивки, которую я пытаюсь туда записать, в этом диапазоне должны находиться определённые данные, которые туда не записываются.

Вот то что надо записать в формате Intel HEX, адрес предшествует данным.
Нажмите для просмотра прикрепленного файла

Вот как выглядит флэш после полного форматирования:
Нажмите для просмотра прикрепленного файла

Вот что я пытаюсь записать из оперативной памяти во флэш по адресу 0x0:
Нажмите для просмотра прикрепленного файла

Во флэше по указанному адресу это появляется в следующем искаженном виде:
Нажмите для просмотра прикрепленного файла


Что скажете?

Уже было тут недавно про не стираемое начало флеши на LPC
У вас ножка бут подтянута на штатную загрузку? тогда получается что у вас начальный регион должен на загрузчик быть замаплен, вроде как... не это ли у вас тут происходит?

у большинства LPC есть такая багафича в бутлоадере - по умолчанию 64 байта отмаплены на BOOT ROM. родному бутлоадеру этот мапинг не нужен, но и на flash он почему то его мапит только если вход в бутлоадер не произведен, для запуска пользовательской программы. Поэтому все программаторы в начале грузят и запускают код в озу, который записью в регистр мапит flash. Это достаточно сделать один раз, конечно если врублена защита в начале придется всю флешь стереть.
Непонятно почему NXP до сих пор не поправил это поведение. Например в LPC11C14 вообще бред получается - если войти в UART бутлоадер флешь на месте, а если в CAN - нет!

ну я так понимаю что он мапит бут ром в начало флеш и по этой причине загружается в загрузчик, а не в пользовательское приложение... То есть это как бы принцип работы или я чего то не понимаю?

Нет! у NXP при включении питания или по ресету всегда отмаплен загрузчик, первыми командами он отключает возможность отладки у NXP ARM7 чисто софтовая защита, потом проверяет можно ли включить отладку, потом проверяет ногу для запуска загрузчика по UART, если в загрузчик входить не надо мапит флешь и запускает пользовательскую программу.
Кстати это надо учитывать при отладке - и обходить место отключения ног отладчика в ARM7 если есть необходимость шагать с самого запуска (на самом деле после ресета отладчиком). Для cortex -ов я не разбирался как защита устроена, но схема очень похожа, не разбирался только как они блокируют возможность подключения по SWD пока ресет активен.

Так вот мапинг bootrom нужен только что бы стартовал загрузчик, загрузчик не использует прерывания и больше не обращается по 0ым адресам. По хорошему после старта надо мапить флешь, все равно загрузчик ее мапит перед запуском пользовательской программы и почему бы это не делать сразу непонятно. И в LPC11C14, например это происходит, но почему только для UART. в LPC17xx не происходит, там тоже надо всегда запускать программу.

Но это все надо делать только если хочется проверить запись флеша или считать его. Запись, стирание будет корректно и без мапинга.
По идее это - ближе к баге! Т.к. в даташитах расписан ISP - в частности команда чтения и нигде не указано что надо что то мапить!!! И родной бутлоадер без костылей не обеспечивает ее работу. А про костыли NXP умалчивает.

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

Что-то странное Вы говорите....
Уже много лет пользуем в своих устройствах LPC2378. Прошиваем и стираем его FlashMagic-ом. В том числе и 0-сектор. И вроде проблем с этим никогда не было (если конечно P2.10 в нужном положении при снятии RESET).
И как Вы с ISP что-то отмапите? Это-же не IAP. ISP выполняет ROM-код он и должен рулить мапингом при необходимости.

Вот и мне так кажется...

Единственное что я сейчас подумал, а как проверить что в 0 сектор флеши записано? если на чтение замаплин бутлоадер?

Теоретически, в ISP есть команда Blank check sector(s) <sector number> <end sector number>. Если она вдруг будет сравнивать с отраженными векторами загрузчика - бомбить письмами техподдержку. Они английским по белому в руководстве пользователя обещали, что сравниваться будет именно с флеш.

ТС знает ли о существовании CRP (Code Read Protection) ?

Не что-то вы обманываете

UM10601 (первый какой нашел)


Или же когда он будет выкидывать не совпавший контекст он весь сектор выкинет с правильными данными? Да еще игнорируя CRP?

Интересно как FlashMagic проверяет целостность записи прошивки...

а для 1768 уже такая приписка к этой функции пропала...

Да, виноват, не дочитал

Спасибо за быстрый отклик! Сейчас уточню некоторые моменты, т.к. вижу что это необходимо.

Если верить даташиту, то CRP включается следующим образом:
Нажмите для просмотра прикрепленного файла

По указанному адресу при залитой прошивке лежит следующее:
Нажмите для просмотра прикрепленного файла

Когда отсылаю в ISP "E 0 14 \r\n" то это место как и положено записывается FF FF FF FF.

В ISP я же вхожу зажиманием P2.10 на "0", потом последовательно "0" и "1" на RESET, затем "1" на P2.10 и начинаю отсылать стандартные команды ISP-бутлоадера.

Хотелось бы услышать следующее: важны ли эти самые первые 64 байта? если важны, то как их туда записать?

Если надо могу написать всю последовательность высылаемых команд.

P.S. Еще такой вопрос возник по ходу дела: это нормально, что после сброса в оперативной памяти с самого начала лежит какой-то мусор?

UPD Вспомнил: когда поторшил HEX прошивки в конце нашел такую запись:

:04 0000 05 00000234 C1, что мною было интерпретировано после гугла как "Линейный адрес старта: начало программы по адресу 0x00000234." Это имеет какое-то отношение к проблеме?

чудно однако....

ведь FlashMagic реально сначала пишет, потом проверяет... может Campare читает из пользовательской флеши?

Вот подключитесь снифером и посмотрите! FlashMagic грузит в озу программу и запускает ее! Эта программа мапит флешь на адрес 0! И только после этого все проверки работают!

Я с самого появления АРМ еще у Philips работаю с ними, когда еще и баги в бутлоадере были, которые позволяли защищенный флешь читать

CRP начинает действовать только после перезагрузки и фактически это всего лишь отключение ног отладчика! И запрет бутлоадеру выполнять определенные команды.


Записать их не проблема!
Они запишутся! Проблема с чтением и проверкой, что бы это с работало надо загрузиь в ОЗУ и выполнить простую подпрограмму которая запишет регистр и отмапит флешь на адрес 0! Все это делается с помощью команд бутлоадера. Это можно сделать сразу после подключения если CRP не было или сразу после стирания...

Еще важно не забыть посчитать контрольную сумму векторов прерываний, не все тулчаины ее при сборке рассчитывают, если ее не будет программа не будет запускаться чип в бутлоадер будет переходить!

Должен, но он этого не делает!
Все программаторы, если они хотят счтитать или проверить первые 64 байта флеша, при помощи команд ISP грузят в ОЗУ подпрограмму которая мапит флеш на адрес 0! После этого все работает как ожидается.

Да и кстати это, по крайней мере не у всех серий, не ROM - а флешь. У первых серий это вообще была последняя страница флеша. Для некоторых серий NXP выкладывал апгрейд бутлоадера.

Ну что-ж - вполне правдоподобно. Значит ТС может сделать то же самое.

Кроме того если нужно ускорить прошивку. можно загрузить в ОЗУ подпрограмму которая принимает данные из UART по другому протоколу - например просто принимает напр 4 кб данных и возвращает контрольную сумму для проверки и возвращается в бутлоадер, а программатор потом вызывает команду записи флеша, потом опять подпрограмму загрузки для следующей старницы и т.д.
Причем подпрограмму можно грузить один раз ни бутлоадер ни IAP не портят память, они используют те области которые указаны в даташите.

Ускорение полезно для больших прошивок, особенно когда к чипу через USBUART идет подключение.

Поподробнее, если можно....пока что не понимаю как конкретно пошагово это делать...какие команды и т.д.

загрузить в ОЗУ, например по адресу
0x40000200
24 байта
(0x0C, 0x00, 0x9F, 0xE5, 0x01, 0x10, 0xA0, 0xE3, 0x00, 0x10, 0x80, 0xE5, 0x0E, 0xE0, 0x81, 0xE1, 0x1E, 0xFF, 0x2F, 0xE1, 0x40, 0xC0, 0x1F, 0xE0,)

Потом дать бутлоадеру команду
"G 1073742336 A"

код этот не очень "красивый", взят ЕМНИП снифером из первого филисовского программатора.


но тут оптимизации не к чему Работает вроде на всех LPC2xxx.

На всех, у которых ROM-код исполняется в Thumb. :-)

ЗЫ: Его можно оптимизировать по размеру, переписав в Thumb. :-)

А у всех LPC ARM7 boot код в THUMB, а что IAP (который часть boot rom) в THUMB - так явно в даташите указано.

Инструкция
ORR LR, R1, LR
лишняя, если конечно в какой то версии бутлоадера не было баги в реализации команды G.

А так можно смело в THUMB запускать, кстати удобно тесты железа запускать еще до прошивки.

Спасибо всем огромное! В очередной раз форумчане выручают начинающего чайника!)

Думал что на этом эпопея закончится, ан нет...

Новый виток: перед тем как шиться выполняю из оперативной памяти код, который скинул форумчанин KRS, получаю всю память в FF как и желаю, пишу первый блок в 256 байт, он записывается как положено, потом дописываю все остальное (всего чуть больше килобайта). Записываемая программа должна моргать диодом с периодом в 1-2 секунды. Что происходит по окончании прошивки: диод начинает моргать циклично, но период увеличен раз так в 10-20, и после выключения-включения питания первые 64 байта опять переписываются как им удобно и код перестает работать.

Что здесь можно предпринять?

Именно переписываются? Или все таки это бутлоадер туда отмаплен?

Контрольная сумма векторов прерываний посчитана?

Надо отпустить ногу бута.

Порт 2.10? Отпущен.

Если контрольная сумма векторов прерываний не посчитана, чип будет переходить в бутлоадер в любом случае!

Я думал, что в готовой прошивке все должно быть посчитано....

Вот что в даташите написано по этому поводу
Нажмите для просмотра прикрепленного файла

Как в таком случае самому подсчитать и записать куда надо эту контрольную сумму?

При записи по 0 адресу:

а записать ее надо в серединку таблицы прерываний в адрес 0х14 если от нуля
UPD, не заметил ее там уже пихают в 5 ячейку

пока что не очень понятно....

Я не знаю "архитектуру" Вашего программатора, но логично предположить...
что есть функция которая записывает блок флеша, на вход подаются данные и адрес, так вот если адрес = 0, buf - указатель на данные надо перед отправкой данных вставить этот код.

Там же возможна запись из ОЗУ во Flash только блоками по 256 байт минимум...и это ограничение от NXP

Да все равной какой размер! Главное что первый блок будет больше 32 байт и перед передачей его в ОЗУ для записи надо вставить этот код, который заменит одно слово.

В вашей прошивке в начале лежит таблица прерываний, в 0x14 - это 5 ячейка если ее мерить 32 битными словами, должна лежать контрольная сумма этой таблицы, такая что сумма по всей таблице должна давать 0.

То есть после того как вы получили файл прошивки, с ним выполняете указанные действия считаете сумму всей таблицы кроме 5 ячейки. И отрицательное значение записываете в 5 ячейку, таким образом сумма по всей таблице станет 0. После этого такую поправленную прошивку пихаете во флэш и все будет!

В LPC17xx минимум == 16 байт. Скорей всего в LPC23xx так же.

да не в размере дело, а в том что надо поправить 4 байта с адреса 0х14 в прошивке, это надо сделать еще до записи всей прошивки, так что абсолютно не важно какими блоками потом ее записывать...

флеш 128 битный с ECC поэтому меньше 16 байт = 128 бит нельзя.
Но это только если Вы умеете сами писать. Через документированное API нельзя! И в LPC17xx тоже

так же как нельзя писать в не стертую флэшь (если мы конечно хотим верных в ней данных) потому дописать ничего не получиться, надо писать с 1 раза.

Можно. Если предварительно считать страничку. У меня так даже журналы (с размером записей кратным 16 байт) в эту флешь пишутся.


Можно дописывать. Только элементами выровненными по границам 16-байтных кусочков.

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

Одно время столкнулся с проблемой на LPC2368: когда дописывал таким образом, иногда получал случайно запорченные данные по соседству.

Писали невыровненные на 16 байт данные.

да в общем можно и не считывать, а просто заполнить FF, кроме нужных 16 байт, может в таком случае и писать быстрее будет.

Только вот способ не гарантированный, теоретически NXP может поменять технологию флеша.

Вряд-ли. Так как у самой NXP есть какой-то AN где так и советуют делать.

Нет, точно выровненные

А я заставил линкер gcc считать контрольную сумму. Убил двух зайцев - нет описанных выше проблем с дополнительной обработкой прошивки и программа работает после загрузки отладчиком (OpenOCD), который про контрольную сумму векторов ничего не знает и считать не умеет.

Возможно в LPC23xx были какие-то проблемы. На LPC1758/68 у меня уже в нескольких проектах ведутся журналы во внутренней флешь таким образом. И никаких проблем.

А у Вас названия обработчиков прерываний фиксированные?
Или в скрипте линкера всетаки как то можно получить доступ к данным по определенному адресу...