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

Пишу внутрисистемный (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." Это имеет какое-то отношение к проблеме?

Сообщение отредактировал lavrik - Mar 26 2015, 11:10

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

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

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

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

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


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

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