|
|
  |
Breakpoints, IAR,Wiggler,H-JTAG,at91sam7x256-ek |
|
|
|
Jan 26 2007, 23:17
|
Частый гость
 
Группа: Свой
Сообщений: 169
Регистрация: 10-11-05
Из: Воронеж
Пользователь №: 10 687

|
Доброго времени суток! Весь день пытался освоить отладку софта в IAR. Имеем Wiggler + H-JTAG. В IAR работаю через RDI.При отладке из флеша все как положено - не более 2 бряков. Но ведь при работе в ОЗУ их должно быть сколько угодно? ИАР так не думает 1) Создаем в IAR новый пустой проект: int main() { return 0;}. Для линкера берем файл из примеров at91SAM7X256_ram.xcl, предварительно осознав что там написано и не выявив никакого криминала. Для отладчика берем макро (тоже из примеров) sam7_ram.mac. На вкладке Download никаких галок не стоит. Галка run to main снята. Отладчик запускается, рисует стрелку на 0 адресе. При любой попытке трассировки в окошке debug log RDI ругается, что все бряки уже использованы и еще одну добавить низя! Смотрим Breakpoint Usage и точно - стоят 2 служебных точки самой среды: C-SPY Terminal I/O и что-то про стек (сейчас точно их названия воспроизвести не могу - под рукой нет проекта). Странно, но я думал, что при отладке из ОЗУ я не ограничен двумя бряками 2) Файлы xcl и mac не меняем, но поставим галки на вкладке Debug/Download "Verify download" и "Use flash loader". Тогда, если я правильно понимаю, среда зашьет бинарник во флеш, но при этом опять будет выполнять софт из ОЗУ. О, чудо!!! Отладка работает. Нет ограничений на количество БП. Готов застрелиться....  Я, конечно, могу оставить все как есть, т.е. при каждом сеансе отладки перешивать еще из флэшку, но это как-то, мягко говоря, неправильно. Подскажите, в чем может быть засада?
|
|
|
|
|
Jan 27 2007, 22:45
|
Частый гость
 
Группа: Свой
Сообщений: 169
Регистрация: 10-11-05
Из: Воронеж
Пользователь №: 10 687

|
Цитата(KRS @ Jan 27 2007, 12:07)  Очень странно! У меня имеено в такой связке все работает нормально. Правда с филипсами разными (2103, 2129 ...) из озу без проблем сколько угодно точек. При этом флеш часто вообще не прошит. С атмелом X256 тоже пробовал, на eval boarde, точно не помню, но вроде проблем не было. Наверное проблема с отображением памяти. надо проверить .mac и .xcl файлы. Попробовать вообще грузить в озу ( без мапа) и в .mac файле установить PC на начало программы... Действительно, если задать области RAM и ROM в диапазон ОЗУ (0х200000 - 0х20FFFF) и в макросе выставить PC=0х200000, то отладка работает не зависимо от того, сделан ли ремап. Соответственно, можно только задать правильно области и сделать ремап, а РС не трогать. Спасибо за ценный совет. Дальше попробую сам докопаться до причин такого поведения...
|
|
|
|
|
Jan 28 2007, 15:10
|
Частый гость
 
Группа: Свой
Сообщений: 169
Регистрация: 10-11-05
Из: Воронеж
Пользователь №: 10 687

|
Тема закрыта. Для тех, кому интересно, вот причины такого странного поведения: 1) При работе из ОЗУ отладчик выполняет макросы: - execUserPreload() перед загрузкой кода в ОЗУ - execUserReset() после загрузки перед стартом - execUserSetup сразу после execUserReset() 2) Смотрим на код макро-файла sam7_ram.mac, который я взял из какого-то примера для моего кита: Код /********************************************************************* * * _MapRAMAt0() * * Function description * Maps RAM at 0. */ _MapRAMAt0(){ __message "Changing mapping: RAM mapped to 0"; __writeMemory32(0x00000001,0xFFFFFF00,"Memory"); }
/********************************************************************* * * _InitRSTC() * * Function description * Initializes the RSTC (Reset controller). * This makes sense since the default is to not allow user resets, which makes it impossible to * apply a second RESET via J-Link */ _InitRSTC() { __writeMemory32(0xA5000001, 0xFFFFFD08,"Memory"); // Allow user reset }
/********************************************************************* * * _InitPLL() * Function description * Initializes the PMC. * 1. Enable the Main Oscillator * 2. Configure PLL to 96MHz * 3. Switch Master Clock (MCK) on PLL/2 = 48MHz */ _InitPLL() {
__message "Set Main Oscillator"; __writeMemory32(0x00004001,0xFFFFFc20,"Memory"); // MOSC while( !(__readMemory32(0xFFFFFc68,"Memory") & 0x1) );
__message "Set PLL to 96MHz"; __writeMemory32(0x10483f0e,0xFFFFFc2c,"Memory"); // LOCK while( !(__readMemory32(0xFFFFFc68,"Memory") & 0x4) );
__message "Set Master Clock to 48MHz"; __writeMemory32(0x00000004,0xFFFFFc30,"Memory"); // MCKRDY while( !(__readMemory32(0xFFFFFc68,"Memory") & 0x8) ); __writeMemory32(0x00000007,0xFFFFFc30,"Memory"); // MCKRDY while( !(__readMemory32(0xFFFFFc68,"Memory") & 0x8) ); }
/********************************************************************* * * execUserReset() : JTAG set initially to Full Speed */ execUserReset() { __message "execUserReset()"; __emulatorSpeed(30000); // Set JTAG speed to 30kHz to make a hardware reset __hwReset(0); // Hardware Reset: CPU is automatically halted after the reset _InitPLL(); // Allow to debug at JTAG Full Speed _MapRAMAt0(); // Remap RAM to address 0 __emulatorSpeed(0); // Set JTAG speed to full speed }
/********************************************************************* * * execUserPreload() : JTAG set initially to 32kHz */ execUserPreload() { __message "execUserPreload()"; __hwReset(0); // Hardware Reset: CPU is automatically halted after the reset (JTAG is already configured to 32kHz) _InitPLL(); // Allow to load Code at JTAG Full Speed _MapRAMAt0(); // Remap RAM to address 0 _InitRSTC(); // Enable User Reset to allow execUserReset() execution } 3) Видим, что перед загрузкой в макросе execUserPreload() делается ремап, т.е. ОЗУ проецируется на адреса 0000-FFFF. После загрузки, перед стартом в execUserReset() делается опять ремап! Хоть он делается и после __hwReset(0), но он отменяет действие предыдущего, и ОЗУ уже не отображается в начало памяти. Отсюда и проблемы с отладкой. Интересно, а __hwReset(0) должен сбрасывать ремап или нет?
|
|
|
|
|
Jan 28 2007, 15:34
|

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

|
Цитата(gladov @ Jan 28 2007, 14:10)  3) Видим, что перед загрузкой в макросе execUserPreload() делается ремап, т.е. ОЗУ проецируется на адреса 0000-FFFF. После загрузки, перед стартом в execUserReset() делается опять ремап! Хоть он делается и после __hwReset(0), но он отменяет действие предыдущего, и ОЗУ уже не отображается в начало памяти. Отсюда и проблемы с отладкой. могу предложить вам вариант, который делает нужный ремап независимо от того, сколько раз вызывается: Код __var tmp; Remap_RAM() { tmp = __readMemory32(0x00200000, "Memory"); // read from RAM area __writeMemory32(~tmp, 0x00200000, "Memory"); // alter RAM area if( ~tmp != __readMemory32(0x00000000, "Memory") ) // check if altering mirrored to remap area { __writeMemory32(0x00000001, 0xFFFFFF00,"Memory"); } __writeMemory32(tmp, 0x00200000 ,"Memory"); // restore RAM data __message " remaped to RAM "; }
Remap_FLASH() { tmp = __readMemory32(0x00200000, "Memory"); // read from RAM area __writeMemory32(~tmp, 0x00200000, "Memory"); // alter RAM area if( ~tmp == __readMemory32(0x00000000, "Memory") ) // check if altering mirrored to remap area { __writeMemory32(0x00000001, 0xFFFFFF00,"Memory"); } __writeMemory32(tmp, 0x00200000 ,"Memory"); // restore RAM data __message " remaped to Flash "; }
--------------------
На любой вопрос даю любой ответ"Write code that is guaranteed to work, not code that doesn’t seem to break" ( C++ FAQ)
|
|
|
|
|
  |
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|