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

at91rm9200

Помогите разобраться... Камень AT91RM9200, JTAG эмулятор - MT-Link v5. JTAG работает - идентификатор процессора читается правильно, кварцы работают - смотрел осциллографом. Пробовал использовать MULTI2000 через RDI - возникает проблема установки брейкпоинтов - warning: Could not set breakpoint, disabling, но программа вроде как заливается. Пробовал CodeWarrior + AXD - при загрузке образа вылетает предупреждение Warning: Trace functionality is not available with current target configuration. Образ вроде грузится, брейкопоинты срабатывают, но в окне дизассемблирования память пустая - память либо заполнена последовательностями 0х00000000, либо 0хFFFFFFFF. Может кто подскажет, какой подход нужен для прошивки AT91RM9200? Самому ранее никогда не приходилось работать с этим процессором.

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


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

Я, честно говоря, только про IAR могу что-то сказать, да и то только про работу в SRAM и SDRAM.

У меня J-Link 5.

 

Куда ты грузишь? Как-то странно, программа работает, а код не видно.

Если посмотреть сеггеровской утилиткой (J-Mem), что видно?

Изменено пользователем Ruslan1

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


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

Спасибо за помощь. Я уже сам разобрался в чём дело. За день глаза на работе замылились ))). Дело было в следующем. Опыта работы с камнем, как в прочем и со средой MULTI у меня нет. Оказалось, что маппинг памяти для линкера был указан неверно. Кроме того, MULTI генерит довольно большой кусок startup кода - значительно больший, чем размер SRAM на чипе (16К). Поэтому и возникали такие вещи: как я говорил - MULTI не могла установить брейкпоинт, а в AXD код вроде бы отлаживался, но не на камне. C AXD я не стал разбираться.

После того, как от startup кода я избавился - откомпилировал свой crt0.o модуль, где оставил только вызов _statup(), в котором вызывал собственный main() - памяти стало хватать и проблема исчезла.

Сейчас всё работает без нареканий. Как только разбирусь с SDRAM и bootloader`ом, - startup верну на место.

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


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

Кроме того, MULTI генерит довольно большой кусок startup кода - значительно больший, чем размер SRAM на чипе (16К).

Нифига себе! И как с этим работать? Это стандартный стартап или уже твои инициализации?

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


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

Нифига себе! И как с этим работать? Это стандартный стартап или уже твои инициализации?

 

Стандартный стартап - я тут ни при чём. Если бы это были мои инициализации - тогда я сразу бы догадался в чём дело. Среда MULTI на самом деле содержит очень серьёзный компилятор, со множеством расширений, включая проверку ошибок времени выполнения, RTTI (C++) и прочее - всё то, что уже давно поддерживают компиляторы на х86. Видимо этим и вызвано такое раздувание. Странно что он не выбрасывает всё это из кода - в опциях я отказывался от всевозможных наворотов. В общем тут надо ещё будет разбираться.

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


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

Нифига себе! И как с этим работать? Это стандартный стартап или уже твои инициализации?

 

Стандартный стартап - я тут ни при чём. Если бы это были мои инициализации - тогда я сразу бы догадался в чём дело. Среда MULTI на самом деле содержит очень серьёзный компилятор, со множеством расширений, включая проверку ошибок времени выполнения, RTTI (C++) и прочее - всё то, что уже давно поддерживают компиляторы на х86. Видимо этим и вызвано такое раздувание. Странно что он не выбрасывает всё это из кода - в опциях я отказывался от всевозможных наворотов. В общем тут надо ещё будет разбираться.

 

Я это к чему удивился: Существуют варианты, когда просто необходимо, чтобы программа помещалась в внутренний SRAM. Например, если грузишься из SPI DataFlash, твоя программка сначала должна загрузиться в SRAM, проиницииализировать хотя бы контроллер SDRAM, и только после этого можно что-то заливать в SDRAM. Если же у тебя даже этот бутлодер из-за стартапа не помещается в внутреннюю RAM, то получается, что загрузится невозможно.

 

Но думаю, что этот стартап какими-нибудь прагмами все-таки должен усекаться при желании. Иначе ну ее к монахам из ембидеда, эту серьезную среду!

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


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

Да тут вы правы. Слишком большой код генерится. Мало того, сейчас снова начали обнаруживаться странности при заливке: решил написать переключение на основной кварц... После этого, брейкпоинты снова перестали отлавливаться, при чём даже до входа в функцию переключения на основной кварц. Одним словом - шаманство. Сейчас решил поставить IAR - попробовать - может с ним будет меньше проблем.

 

Руслан вы сказали, что работаете в IAR с at91rm9200. Помогите мне разобраться: как настроить среду так, чтобы программу можно было заливать в SRAM, а то у меня что то не получается: в Project->Options->Linker настроил собственный linker command file. SRAM поделил на две части: под RAM отвёл адреса 200000-201FFF, под ROM - адреса 202000-203FFF. Тем не менее после сохранения файла настройки для ROM оказываются прежними - как по умолчанию. А при заходе в отладку точка входа располагается с нулевого адреса. Что я делаю не так?

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


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

Да тут вы правы. Слишком большой код генерится. Мало того, сейчас снова начали обнаруживаться странности при заливке: решил написать переключение на основной кварц... После этого, брейкпоинты снова перестали отлавливаться, при чём даже до входа в функцию переключения на основной кварц. Одним словом - шаманство. Сейчас решил поставить IAR - попробовать - может с ним будет меньше проблем.

 

Руслан вы сказали, что работаете в IAR с at91rm9200. Помогите мне разобраться: как настроить среду так, чтобы программу можно было заливать в SRAM, а то у меня что то не получается: в Project->Options->Linker настроил собственный linker command file. SRAM поделил на две части: под RAM отвёл адреса 200000-201FFF, под ROM - адреса 202000-203FFF. Тем не менее после сохранения файла настройки для ROM оказываются прежними - как по умолчанию. А при заходе в отладку точка входа располагается с нулевого адреса. Что я делаю не так?

xcl

//*************************************************************************
// XLINK command file template for EWARM/ICCARM
//
// Usage:  xlink  -f lnkarm  <your_object_file(s)>
//                -s <program start label>  <C/C++ runtime library>
//
// $Revision: 1.2 $
//*************************************************************************

// The flash loader is loaded into the 2M external RAM avaiable on the
-DMEMSTART=0x00000000
-DMEMEND=0x000003FFF

//*************************************************************************
// In this file it is assumed that the system has the following
// memory layout:
//
//   Exception vectors [0x000000--0x00001F]  RAM or ROM
//   ROMSTART--ROMEND  [0x008000--0x0FFFFF]  ROM (or other non-volatile memory)
//   RAMSTART--RAMEND  [0x100000--0x7FFFFF]  RAM (or other read/write memory)
//
// -------------
// Code segments - may be placed anywhere in memory.
// -------------
//
//   INTVEC     -- Exception vector table.
//   SWITAB     -- Software interrupt vector table.
//   ICODE      -- Startup (cstartup) and exception code.
//   DIFUNCT    -- Dynamic initialization vectors used by C++.
//   CODE       -- Compiler generated code.
//   CODE_I     -- Compiler generated code declared __ramfunc (executes in RAM)
//   CODE_ID    -- Initializer for CODE_I (ROM).
//
// -------------
// Data segments - may be placed anywhere in memory.
// -------------
//
//   CSTACK     -- The stack used by C/C++ programs (system and user mode).
//   IRQ_STACK  -- The stack used by IRQ service routines.
//   SVC_STACK  -- The stack used in supervisor mode
//                 (Define other exception stacks as needed for
//                 FIQ, ABT, UND).
//   HEAP       -- The heap used by malloc and free in C and new and
//                 delete in C++.
//   INITTAB    -- Table containing addresses and sizes of segments that
//                 need to be initialized at startup (by cstartup).
//   CHECKSUM   -- The linker places checksum byte(s) in this segment,
//                 when the -J linker command line option is used.
//   DATA_y     -- Data objects.
//
// Where _y can be one of:
//
//   _AN        -- Holds uninitialized located objects, i.e. objects with
//                 an absolute location given by the @ operator or the
//                 #pragma location directive. Since these segments
//                 contain objects which already have a fixed address,
//                 they should not be mentioned in this linker command
//                 file.
//   _C         -- Constants (ROM).
//   _I         -- Initialized data (RAM).
//   _ID        -- The original content of _I (copied to _I by cstartup) (ROM).
//   _N         -- Uninitialized data (RAM).
//   _Z         -- Zero initialized data (RAM).
//
// Note:  Be sure to use end values for the defined address ranges.
//        Otherwise, the linker may allocate space outside the
//        intended memory range.
//*************************************************************************

//************************************************
// Inform the linker about the CPU family used.
//************************************************

-carm

//*************************************************************************
// Segment placement - General information
//
// All numbers in the segment placement command lines below are interpreted
// as hexadecimal unless they are immediately preceded by a '.', which
// denotes decimal notation.
//
// When specifying the segment placement using the -P instead of the -Z
// option, the linker is free to split each segment into its segment parts
// and randomly place these parts within the given ranges in order to
// achieve a more efficient memory usage. One disadvantage, however, is
// that it is not possible to find the start or end address (using
// the assembler operators .sfb./.sfe.) of a segment which has been split
// and reformed.
//
// When generating an output file which is to be used for programming
// external ROM/Flash devices, the -M linker option is very useful
// (see xlink.pdf for details).
//*************************************************************************


//*************************************************************************
// Read-only segments mapped to ROM.
//*************************************************************************

-DROMSTART=MEMSTART
-DROMEND=MEMEND

//************************************************
// Address range for reset and exception
// vectors (INTVEC).
// The vector area is 32 bytes,
// an additional 32 bytes is allocated for the
// constant table used by ldr PC in cstartup.s79.
//************************************************

-Z(CODE)INTVEC=MEMSTART:+40

//************************************************
// Startup code and exception routines (ICODE).
//************************************************

-Z(CODE)ICODE,DIFUNCT=ROMSTART-ROMEND
-Z(CODE)SWITAB=ROMSTART-ROMEND

//************************************************
// Code segments may be placed anywhere.
//************************************************

-Z(CODE)CODE=ROMSTART-ROMEND

//************************************************
// Original ROM location for __ramfunc code copied
// to and executed from RAM.
//************************************************

-Z(CONST)CODE_ID=ROMSTART-ROMEND

//************************************************
// Various constants and initializers.
//************************************************

-Z(CONST)INITTAB,DATA_ID,DATA_C=ROMSTART-ROMEND
-Z(CONST)CHECKSUM=ROMSTART-ROMEND

//*************************************************************************
// Read/write segments mapped to RAM.
//*************************************************************************

-DRAMSTART=(MEMSTART+40)
-DRAMEND=MEMEND

//************************************************
// Data segments.
//************************************************

-Z(DATA)DATA_I,DATA_Z,DATA_N=RAMSTART-RAMEND

//************************************************
// __ramfunc code copied to and executed from RAM.
//************************************************

-Z(DATA)CODE_I=RAMSTART-RAMEND

//************************************************
// ICCARM produces code for __ramfunc functions in
// CODE_I segments. The -Q XLINK command line
// option redirects XLINK to emit the code in the
// CODE_ID segment instead, but to keep symbol and
// debug information associated with the CODE_I
// segment, where the code will execute.
//************************************************

-QCODE_I=CODE_ID

//*************************************************************************
// Stack and heap segments.
//*************************************************************************

-D_CSTACK_SIZE=500
-D_SVC_STACK_SIZE=100
-D_IRQ_STACK_SIZE=100
-D_HEAP_SIZE=500

-Z(DATA)CSTACK+_CSTACK_SIZE=RAMSTART-RAMEND
// -Z(DATA)SVC_STACK+_SVC_STACK_SIZE=RAMSTART-RAMEND
-Z(DATA)IRQ_STACK+_IRQ_STACK_SIZE,HEAP+_HEAP_SIZE=RAMSTART-RAMEND
-Z(NEAR)BUF_START=RAMSTART-RAMEND
-Z(NEAR)BUF_END=RAMEND

//*************************************************************************
// ELF/DWARF support.
//
// Uncomment the line "-Felf" below to generate ELF/DWARF output.
// Available format specifiers are:
//
//   "-yn": Suppress DWARF debug output
//   "-yp": Multiple ELF program sections
//   "-yas": Format suitable for debuggers from ARM Ltd (also sets -p flag)
//
// "-Felf" and the format specifiers can also be supplied directly as
// command line options, or selected from the Xlink Output tab in the
// IAR Embedded Workbench.
//*************************************************************************

// -Felf

mac

execUserPreload()
{
setup();
// init_PLL();
  // Test and set Remap
__writeMemory32(0xAAAAAAAA,0x00000000,"Memory");
  if(__readMemory32(0x00000000,"Memory") != 0xAAAAAAAA)
  {
    __writeMemory32(0x01,0xFFFFFF00,"Memory");    // MC_RCR: toggle remap bit
  }
// init_SDRAM ();
  __message("Target init macro complete");
}


setup()
{
  __var i,clk;


  __writeMemory32(0x1, 0xFFFFFC00, "Memory");             // PMC_SCER: PCK = 1

  __writeMemory32(0x0000FF01, 0xFFFFFC20, "Memory");      // PMC_MOR: MOSCEN = 1, enable main clock

  while(((clk = __readMemory32(0xFFFFFC24, "Memory")) & 0x00010000) == 0);  // Read PMC_MCFR to determine Fosc

  clk = (clk & 0x0000FFFF) * 32768 / 16;    // * 244 / 5;

  __writeMemory32(0x1, 0xFFFFFC30, "Memory");             // PMC_MCKR: CSS = 1, PRES = 0, MDIV = 0

}

 

смотрим внимательно даташит, IAR User Guide и примеры в поставке IAR ТАМ ЕСТ ВСЁ.

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


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

Руслан вы сказали, что работаете в IAR с at91rm9200. Помогите мне разобраться: как настроить среду так, чтобы программу можно было заливать в SRAM, а то у меня что то не получается: в Project->Options->Linker настроил собственный linker command file. SRAM поделил на две части: под RAM отвёл адреса 200000-201FFF, под ROM - адреса 202000-203FFF. Тем не менее после сохранения файла настройки для ROM оказываются прежними - как по умолчанию. А при заходе в отладку точка входа располагается с нулевого адреса. Что я делаю не так?

Я начинающий АРМовод, поэтому просто боюсь давать непроверенные временем советы, вдруг у меня только случайно все работает. :) Да и почту часто смотреть не получается, поэтому торможу иногда на сутки.

При отладке настраиваете железо макросом, в нем же делается ремап. После ремапа SRAM находится с адреса 0x000000.

Тут уже Ken@t написал, что делать. Еще можете посмотреть http://electronix.ru/forum/index.php?showtopic=20153

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


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

Спасибо, я уже со всем разобрался. IAR работает с MT-LINK намного лучше, если не сказать - идеально. Правда через RDI работать под IAR не пробовал - не знаю как там. C MULTI так и не получилось добиться стабильного результата - странно она себя ведёт: если поставить брейкпоинт и залить программу - до брейкопоинта доходит без вопросов. Но если попытаться войти в функцию, в которой производится настройка клоков (!) - совершенно непонятное явление - тогда среда с радостью сообщает, что не может установить брейпоинт - после этого связь с процессором по JTAG теряется. В то время как в другие функции входит без проблем. Очень жаль, что такие вещи происходят. Компилятор MULTI мне больше понравился: генерирует очень компактный код - если заранее избавиться от стартап кода - IARу до него в этом плане далеко, кроме того и настройка маппингов памяти при линковке в MULTI, на мой взгляд, гораздо удобнее сделана. Но стабильная работа отладки намного важнее. Поэтому я выбираю IAR.

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


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

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

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

Гость
К сожалению, ваш контент содержит запрещённые слова. Пожалуйста, отредактируйте контент, чтобы удалить выделенные ниже слова.
Ответить в этой теме...

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

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

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

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

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

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