Перейти к содержанию
    

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

 

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

 

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

 

Вот то что надо записать в формате Intel HEX, адрес предшествует данным.

post-84635-1427285571_thumb.png

 

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

post-84635-1427285890_thumb.png

 

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

post-84635-1427286823_thumb.png

 

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

post-84635-1427286902_thumb.png

 

 

Что скажете?

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Уже было тут недавно про не стираемое начало флеши на LPC

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Пишу внутрисистемный (ISP) программатор для LPC 2366,

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

Непонятно почему NXP до сих пор не поправил это поведение. Например в LPC11C14 вообще бред получается - если войти в UART бутлоадер флешь на месте, а если в CAN - нет!

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Нет! у NXP при включении питания или по ресету всегда отмаплен загрузчик, первыми командами он отключает возможность отладки у NXP ARM7 чисто софтовая защита, потом проверяет можно ли включить отладку, потом проверяет ногу для запуска загрузчика по UART, если в загрузчик входить не надо мапит флешь и запускает пользовательскую программу.

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

 

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

ну не знаю...

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Что-то странное Вы говорите....

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

И как Вы с ISP что-то отмапите? Это-же не IAP. ISP выполняет ROM-код он и должен рулить мапингом при необходимости.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Blank check

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

 

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

This command is used to blank check one or more sectors of on-chip flash memory.

Blank check on sector 0 always fails as first 64 bytes are re-mapped to flash

boot block.

When CRP is enabled, the blank check command returns 0 for the offset and value

of sectors which are not blank. Blank sectors are correctly reported irrespective of

the CRP setting.

 

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

 

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

 

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Не что-то вы обманываете
Да, виноват, не дочитал :(

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

 

Если верить даташиту, то CRP включается следующим образом:

post-84635-1427367447_thumb.png

 

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

post-84635-1427367538_thumb.png

 

Когда отсылаю в 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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Что-то странное Вы говорите....

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

И как Вы с ISP что-то отмапите? Это-же не IAP. ISP выполняет ROM-код он и должен рулить мапингом при необходимости.

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

 

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

 

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

 

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

Записать их не проблема!

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

 

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...