реклама на сайте
подробности

 
 
 
Reply to this topicStart new topic
> Отладка 1986ВЕ81Т
Konrad
сообщение Apr 17 2018, 17:41
Сообщение #1


Местный
***

Группа: Участник
Сообщений: 202
Регистрация: 7-04-08
Пользователь №: 36 555



Коллеги, всем привет.

Осваиваю 1986ВЕ81Т. Это отечественный Cortex-m4 для космоса без Флеш/ПЗУ, у которого есть специальное ОЗУ программ.
Написал в 5ом Кейле небольшой проект и пытаюсь отлаживать на отладочной плате через Ulink2. Для этого использую flash programming algorithm из FLM-файла для СОЗУ 1986ВЕ81Т, скачанного с форума Миландра.

Ulink и МК Кейл видит, всё как-будто хорошо, но частенько при попытке залить программу в СОЗУ (область начинается с 0х1000000) и запустить Debug-сессию, Keil сначала призадумывается и немного погодя выдает ошибку. Точный текст сообщения смогу сказать завтра, но речь про превышение таймаута. При этом изредка загрузка и debug проходят нормально.

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

Сейчас же мне важен чужой опыт - кто-нибудь сталкивался с подобной проблемой? И если да, то каково было решение?
Go to the top of the page
 
+Quote Post
Сергей Борщ
сообщение Apr 17 2018, 19:17
Сообщение #2


Гуру
******

Группа: Модераторы
Сообщений: 8 455
Регистрация: 15-05-06
Из: Рига, Латвия
Пользователь №: 17 095



QUOTE (Konrad @ Apr 17 2018, 19:41) *
Сейчас же мне важен чужой опыт - кто-нибудь сталкивался с подобной проблемой? И если да, то каково было решение?
Была подобная проблема на совсем другом проце (уже не помню, то ли STM32 то ли вообще AT91SAM7) и совсем в другой среде (gdb+openocd). Суть проблемы была в следующем - в программе настраивалась пересылка данных из АЦП в ОЗУ через ПДП. В процессе заливки свежей программы отладчик использовал эту же область ОЗУ то ли под буфер для записываемых во флешь данных, то ли для кода самого загрузчика. Поскольку АЦП и ПДП продолжали "молотить" - то ли записываемые данные затирались и вылетала ошибка при проверке записанного, то ли сам загрузчик затирался и в процессе его выполнения процессор улетал в исключение, а отладчик не мог дождаться его попадания на точку останова в конце загрузчика. Вылечил принудительным выключением ПДП в скрипте отладчика перед началом загрузки.


--------------------
На любой вопрос даю любой ответ
"Write code that is guaranteed to work, not code that doesn’t seem to break" (C++ FAQ)
Go to the top of the page
 
+Quote Post
Konrad
сообщение Apr 17 2018, 19:49
Сообщение #3


Местный
***

Группа: Участник
Сообщений: 202
Регистрация: 7-04-08
Пользователь №: 36 555



Цитата(Сергей Борщ @ Apr 17 2018, 22:17) *
Была подобная проблема на совсем другом проце (уже не помню, то ли STM32 то ли вообще AT91SAM7) и совсем в другой среде (gdb+openocd). Суть проблемы была в следующем - в программе настраивалась пересылка данных из АЦП в ОЗУ через ПДП. В процессе заливки свежей программы отладчик использовал эту же область ОЗУ то ли под буфер для записываемых во флешь данных, то ли для кода самого загрузчика. Поскольку АЦП и ПДП продолжали "молотить" - то ли записываемые данные затирались и вылетала ошибка при проверке записанного, то ли сам загрузчик затирался и в процессе его выполнения процессор улетал в исключение, а отладчик не мог дождаться его попадания на точку останова в конце загрузчика. Вылечил принудительным выключением ПДП в скрипте отладчика перед началом загрузки.


Сергей, благодарю за ответ. Только, боюсь, у меня иной случай. При включении питания в ОЗУ нет программы и периферия бездействует - в поисках источника проблемы я много раз ресетил и обесточивал МК прежде чем начать debug. Хотя, в буте отечественного МК, конечно, может сидеть что-то интересное

Я включаю питание. Пользовательский код не загружен. Контроллер в одном из загрузочных режимов. Инициирую debug... Когда все проходит штатно, сразу начинают бежать индикаторы прогресса и загрузка+верификация длятся секунд 5-10. Но если возникает ошибка, то сначала возникает пауза, а затем через пару секунд вылетает сообщение об истечении таймаута.

Сообщение отредактировал Konrad - Apr 17 2018, 20:08
Go to the top of the page
 
+Quote Post
-=Sergei=-
сообщение Apr 18 2018, 05:17
Сообщение #4


Местный
***

Группа: Свой
Сообщений: 339
Регистрация: 26-10-04
Пользователь №: 985



Цитата(Konrad @ Apr 17 2018, 22:49) *
Сергей, благодарю за ответ. Только, боюсь, у меня иной случай. При включении питания в ОЗУ нет программы и периферия бездействует - в поисках источника проблемы я много раз ресетил и обесточивал МК прежде чем начать debug. Хотя, в буте отечественного МК, конечно, может сидеть что-то интересное

Я включаю питание. Пользовательский код не загружен. Контроллер в одном из загрузочных режимов. Инициирую debug... Когда все проходит штатно, сразу начинают бежать индикаторы прогресса и загрузка+верификация длятся секунд 5-10. Но если возникает ошибка, то сначала возникает пауза, а затем через пару секунд вылетает сообщение об истечении таймаута.


Я думаю на форуме Миландра и в его службе тех поддержки вы быстрее найдете ответ.
Go to the top of the page
 
+Quote Post

Reply to this topicStart new topic
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0

 


RSS Текстовая версия Сейчас: 19th July 2025 - 04:43
Рейтинг@Mail.ru


Страница сгенерированна за 0.0135 секунд с 7
ELECTRONIX ©2004-2016