Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Breakpoints
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > ARM
gladov
Доброго времени суток!

Весь день пытался освоить отладку софта в IAR. Имеем Wiggler + H-JTAG. В IAR работаю через RDI.При отладке из флеша все как положено - не более 2 бряков. Но ведь при работе в ОЗУ их должно быть сколько угодно? ИАР так не думает sad.gif

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 и что-то про стек (сейчас точно их названия воспроизвести не могу - под рукой нет проекта). Странно, но я думал, что при отладке из ОЗУ я не ограничен двумя бряками blink.gif

2) Файлы xcl и mac не меняем, но поставим галки на вкладке Debug/Download "Verify download" и "Use flash loader". Тогда, если я правильно понимаю, среда зашьет бинарник во флеш, но при этом опять будет выполнять софт из ОЗУ. О, чудо!!! Отладка работает. Нет ограничений на количество БП.

Готов застрелиться.... smile3046.gif Я, конечно, могу оставить все как есть, т.е. при каждом сеансе отладки перешивать еще из флэшку, но это как-то, мягко говоря, неправильно. Подскажите, в чем может быть засада?
KRS
Очень странно! У меня имеено в такой связке все работает нормально. Правда с филипсами разными (2103, 2129 ...) из озу без проблем сколько угодно точек. При этом флеш часто вообще не прошит.
С атмелом X256 тоже пробовал, на eval boarde, точно не помню, но вроде проблем не было.
Наверное проблема с отображением памяти. надо проверить .mac и .xcl файлы.
Попробовать вообще грузить в озу ( без мапа) и в .mac файле установить PC на начало программы...
gladov
Цитата(KRS @ Jan 27 2007, 12:07) *
Очень странно! У меня имеено в такой связке все работает нормально. Правда с филипсами разными (2103, 2129 ...) из озу без проблем сколько угодно точек. При этом флеш часто вообще не прошит.
С атмелом X256 тоже пробовал, на eval boarde, точно не помню, но вроде проблем не было.
Наверное проблема с отображением памяти. надо проверить .mac и .xcl файлы.
Попробовать вообще грузить в озу ( без мапа) и в .mac файле установить PC на начало программы...


Действительно, если задать области RAM и ROM в диапазон ОЗУ (0х200000 - 0х20FFFF) и в макросе выставить PC=0х200000, то отладка работает не зависимо от того, сделан ли ремап. Соответственно, можно только задать правильно области и сделать ремап, а РС не трогать. Спасибо за ценный совет. Дальше попробую сам докопаться до причин такого поведения...
gladov
Тема закрыта. Для тех, кому интересно, вот причины такого странного поведения:

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) должен сбрасывать ремап или нет?
Сергей Борщ
Цитата(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 ";
}
gladov
Спасибо. Так, конечно, правильнее.
Alechek
У меня теперь немного обратный вопрос возник.
Как убрать этот самый
C-SPY Terminal I/O & libsupport module
из бряков?
Если я не использую его терминал, зачем расходовать половину возможных бряков??
IgorKossak
Цитата(Alechek @ Oct 15 2007, 11:56) *
У меня теперь немного обратный вопрос возник.
Как убрать этот самый
C-SPY Terminal I/O & libsupport module
из бряков?
Если я не использую его терминал, зачем расходовать половину возможных бряков??

В опциях линкера Output -> Format убираем галочки With runtime... и With I/O ...
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.