STM32: Отладка в RAM Опции

[_Макс]

Беру демку или свой проект, как только меняю в настройках линкера STM32F10x_FLASH.icf на STM32F10x_RAM.icf (беру из IAR), программа останавливается на первом брекпоинте, а потом программа переходит к инструкции 0x8000856: 0xe7fe DC16 59390 ; 'þç' и будто останавливается. Сколько не нажимай Go и Break, стоит на одном месте. Почему так? Как это исправить?

Что это за инструкция DC16?

Имеет ли негативные последствия отладка программ во флеше? Казалось бы количество циклов записи измеряется тысячами, но как на практике, стоит отлаживать в RAM?

[skripach]

стоит отлаживать в RAM?

если только быстрее будет, а так не вижу смысла.

[Dron_Gus]

По-идее надо сдвинуть таблицу векторов на РАМ.

[aaarrr]

если только быстрее будет, а так не вижу смысла.

Из-за некоторых особенностей архитектуры - не будет.

[_Макс]

По-идее надо сдвинуть таблицу векторов на РАМ.

Какие именно мне указать адреса для RAM, ROM и intvec? Пробовал оставлять intvec по умолчанию, а остальную память (64k) делить пополам между RAM и ROM, результат тот же

[skripach]

Сам не пробовал но...
Думаю дело в этом, вот кусок примера идущего с иаром:

Код

  // NVIC init
#ifndef  EMB_FLASH
  /* Set the Vector Table base location at 0x20000000 */
  NVIC_SetVectorTable(NVIC_VectTab_RAM, 0x0);
#else  /* VECT_TAB_FLASH  */
  /* Set the Vector Table base location at 0x08000000 */
  NVIC_SetVectorTable(NVIC_VectTab_FLASH, 0x0);
#endif
  NVIC_PriorityGroupConfig(NVIC_PriorityGroup_4);

[_Макс]

Сам не пробовал но...
Думаю дело в этом, вот кусок примера идущего с иаром:

Код

  // NVIC init
#ifndef  EMB_FLASH
  /* Set the Vector Table base location at 0x20000000 */
  NVIC_SetVectorTable(NVIC_VectTab_RAM, 0x0);
#else  /* VECT_TAB_FLASH  */
  /* Set the Vector Table base location at 0x08000000 */
  NVIC_SetVectorTable(NVIC_VectTab_FLASH, 0x0);
#endif
  NVIC_PriorityGroupConfig(NVIC_PriorityGroup_4);

Это правильный код или не правильный? Какой это файл? В чем тут дело?

[msalov]

Это правильный код или не правильный? В чем тут дело?

это правильный код. Суть в том, что после ресета ядро настроено на таблицу прерываний расположенную во флеш, но так как вы собираетесь отлаживаться в ОЗУ - необходимо указать смещение и область памяти по которому находятся вектора - это делается функцией NVIC_SetVectorTable(). Как несложно догадаться первый параметр - область памяти, второй - смещение. То есть вам надо просто убрать дефайн EMB_FLASH или сделать явный #undef EMB_FLASH

[_Макс]

Получилось, действительно. Как так получается, что процессор стартует ни с нуля, а с адреса 0x00000150 после описания векторов прерывания?

[aaarrr]

Получилось, действительно. Как так получается, что процессор стартует ни с нуля, а с адреса 0x00000150 после описания векторов прерывания?

Ядро читает адрес старта из таблицы векторов при запуске.

[msalov]

Получилось, действительно. Как так получается, что процессор стартует ни с нуля, а с адреса 0x00000150 после описания векторов прерывания?

По нулевому адресу лежит адрес конца стека, а по 4-ому - адрес точки входа в вашу программу - вот с него и стартует.

[_Макс]

У меня по адресу 4 лежит 20000D0D, а код стартует с 0x20000150.

Код

   0x1ffffff4: 0xffffffff     MRC2      p15, #7, pc, c15, c15, #7
   0x1ffffff8: 0xffffffff     MRC2      p15, #7, pc, c15, c15, #7
   0x1ffffffc: 0xffffffff     MRC2      p15, #7, pc, c15, c15, #7
__vector_table:
   0x20000000: 0x20001308     DC32      CSTACK$$Limit
   0x20000004: 0x20000d0d     DC32      Reset_Handler
   0x20000008: 0x20000751     DC32      NMI_Handler
   0x2000000c: 0x20000753     DC32      ??HardFault_Handler_0
   0x20000010: 0x20000755     DC32      ??MemManage_Handler_0
   0x20000014: 0x20000757     DC32      ??BusFault_Handler_0
   0x20000018: 0x20000759     DC32      ??UsageFault_Handler_0
   0x2000001c: 0x00000000     DC32      NVIC_ST_CTRL_ENABLE
   0x20000020: 0x00000000     DC32      NVIC_ST_CTRL_ENABLE
   0x20000024: 0x00000000     DC32      NVIC_ST_CTRL_ENABLE
   0x20000028: 0x00000000     DC32      NVIC_ST_CTRL_ENABLE
   0x2000002c: 0x2000075b     DC32      SVC_Handler
   0x20000030: 0x2000075d     DC32      DebugMon_Handler
   0x20000034: 0x00000000     DC32      NVIC_ST_CTRL_ENABLE
   0x20000038: 0x20000995     DC32      PendSV_Handler
   0x2000003c: 0x200006ef     DC32      SysTick_Handler
   0x20000040: 0x20000e09     DC32      WWDG_IRQHandler
   0x20000044: 0x20000e0d     DC32      PVD_IRQHandler
   0x20000048: 0x20000e11     DC32      TAMPER_IRQHandler
   0x2000004c: 0x20000e15     DC32      RTC_IRQHandler
   0x20000050: 0x20000e19     DC32      FLASH_IRQHandler
   0x20000054: 0x20000e1d     DC32      RCC_IRQHandler

Код

   0x2000013c: 0x20000ee9     DC32      CAN2_TX_IRQHandler
   0x20000140: 0x20000eed     DC32      CAN2_RX0_IRQHandler
   0x20000144: 0x20000ef1     DC32      CAN2_RX1_IRQHandler
   0x20000148: 0x20000ef5     DC32      CAN2_SCE_IRQHandler
   0x2000014c: 0x20000ef9     DC32      OTG_FS_IRQHandler
__sti__routine:
??__sti__routine:
   0x20000150: 0xb510         PUSH      {r4, lr}
TProc1 Proc1;
   0x20000152: 0x4c6e         LDR.N     r4, ??DataTable6 [0x2000030c]; CSTACK$$Limit
   0x20000154: 0x0018f104     ADD.W     r0, r4, #24            ; 0x18
   0x20000158: 0xfe3af000     BL        _ZN2OS7processILNS_9TPriorityE3ELt400EEC1Ev; 0x20000dd0
TProc2 Proc2;
   0x2000015c: 0x10b0f204     ADDW      r0, r4, #432           ; 0x1b0
   0x20000160: 0xfe38f000     BL        _ZN2OS7processILNS_9TPriorityE2ELt400EEC1Ev; 0x20000dd4
TProc3 Proc3;
   0x20000164: 0x3048f204     ADDW      r0, r4, #840           ; 0x348
   0x20000168: 0xfe36f000     BL        _ZN2OS7processILNS_9TPriorityE1ELt400EEC1Ev; 0x20000dd8
TBlinkProc BlinkProc;
   0x2000016c: 0x609cf504     ADD.W     r0, r4, #1248          ; 0x4e0
   0x20000170: 0xfe34f000     BL        _ZN2OS7processILNS_9TPriorityE4ELt300EEC1Ev; 0x20000ddc
TAfricanSlon African;  
   0x20000174: 0x6014f204     ADDW      r0, r4, #1556          ; 0x614
   0x20000178: 0xfe26f000     BL        _ZN12TAfricanSlonC1Ev  ; 0x20000dc8
TIndianSlon  Indian;    
   0x2000017c: 0x60c3f504     ADD.W     r0, r4, #1560          ; 0x618

[ViKo]

Пытаюсь запускать программу из RAM STM32F103. Тренируюсь на примере и плате Keil\ARM\Boards\Keil\MCBSTM32\STLIB_Blinky.
Там задаются начало и размер ROM 0x20000000 и 0x4000, RAM 0x20004000 и 0x1000, при отладке загружается файл RAM.ini, в котором выполняется загрузка кода в RAM, и с помощью функции устанавливается указатель стека и сброс на 0x20000000 и 0x20000004, и задается смещение 0x20000000 в регистр таблицы векторов.

Вопрос - почему перемычки BOOT0, BOOT1 не влияют на то место, куда и откуда загружается и запускается код отладчиком?
Почему, когда нажимаю сброс в отладчике или непосредственно на плате, при установленных перемычках 1,1 (RAM), программа не работает. Кто-то портит содержимое RAM. А если перемычки в 0,0 (Flash), то запускается программа, записанная в Flash.
Еще вопрос - есть ли способ не перемещать код в адреса RAM, а с помощью перемычек отразить область 0x00000000 на адреса RAM, и занести код сразу в RAM?

[ViKo]

Попробую сформулировать вопрос проще.
Как получается, что флэш начинается с 0x08000000, RAM с 0x20000000, а таблица векторов с 0? Где же она физически находится?

[KRS]

Попробую сформулировать вопрос проще.
Как получается, что флэш начинается с 0x08000000, RAM с 0x20000000, а таблица векторов с 0? Где же она физически находится?

Таблица векторов начинается с VTOR, по умолчанию он 0.
А вот на адрес 0 может быть отмаплено или ОЗУ или FLASH, в зависимости от ног которые тип старта определяют ( обычно флеш)
Что бы отлаживаться в озу, я в стартап скрипте отладчика устанавливаю VTOR на ОЗУ.

[aaarrr]

Как получается, что флэш начинается с 0x08000000, RAM с 0x20000000, а таблица векторов с 0? Где же она физически находится?

Ответ, как ни странно, находится в разделе 2.4 мануала:

Depending on the selected boot mode main Flash memory, System memory or SRAM is
accessible as follows:
● Boot from main Flash memory: the main Flash memory is aliased in the boot memory
space (0x0000 0000), but still accessible from its original memory space (0x800 0000).
In other words, the Flash memory contents can be accessed starting from address
0x0000 0000 or 0x800 0000.
● Boot from System memory: the System memory is aliased in the boot memory space
(0x0000 0000), but still accessible from its original memory space (0x1FFF F000).
● Boot from the embedded SRAM: SRAM is accessible only at address 0x2000 0000.

Скажите, а какой, собственно, смысл грузиться из SRAM?

[KRS]

Скажите, а какой, собственно, смысл грузиться из SRAM?

Хороший вопрос
IMHO ноги растут от предыдущих чипов, где это было с внешней памяти.

[ViKo]

Ответ, как ни странно, находится в разделе 2.4 мануала:


Скажите, а какой, собственно, смысл грузиться из SRAM?

За ссылку в мануал спасибо, это я проглядел...
А грузиться из RAM - в первую очередь хочу разобраться в механизме. А во вторую - жалко флэш насиловать - чуть что-то изменил в программе, заходишь в отладку - опять зашивай!

[KRS]

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

Вы что ноги будете перепаивать? Или там джамперы есть?
Что бы под отладчиком грузиться из ОЗУ - нужен правильный скрипт, который VTOR ставит. И все отлично работает.

[ViKo]

Вы что ноги будете перепаивать? Или там джамперы есть?
Что бы под отладчиком грузиться из ОЗУ - нужен правильный скрипт, который VTOR ставит. И все отлично работает.

Выдайте свой скрипт, если не жалко.
Джамперы есть, а как же.
Дальнейшие размышления привели к следующим выводам.
Загрузка из флэш или систем понятна - выставил джамперы, сбросился, скакнул в адрес 0x0, прочитал, куда назначить стек, скакнул в 0x4, прочитал и перешел на адрес.
Можно сразу задать, что микроконтроллер имеет память по нулевым адресам.
А при загрузке из ОЗУ на нулевые адреса ничего не отображается. Т.е. по нулевым адресам ничего нет. Как тогда прочитать вектор сброса? В отладчике это можно сделать предварительно, настроив VTOR 0xE000ED08 (кстати, а это где описано? с ходу не нашел).

[ViKo]

И еще один вывод получился. Если я загружаюсь из флэш, установив перемычки в (0,0), то я могу доступиться к флэш по нулевым адресам и по 0x08000000. А также я могу доступиться и в систем память (загрузчик) по адресам 0x1ffff000.

[KRS]

Выдайте свой скрипт, если не жалко.

Для IAR

Код

execUserReset( )
{
    __message "RAM START";
    __writeMemory32(0x20000000,0xE000ED08,"Memory");
}

[ViKo]

У Keil есть чуть более "хитрый" файл ini

Код

FUNC void Setup (void) {
  SP = _RDWORD(0x20000000);  // Setup Stack Pointer
  PC = _RDWORD(0x20000004);  // Setup Program Counter
  _WDWORD(0xE000ED08, 0x20000000);   // Setup Vector Table Offset Register
}

LOAD RAM\Blinky.axf INCREMENTAL  // Download
Setup();    // Setup for Running
G ,main     // Выполнить программу до main

Blinky.axf, понятно, должен быть скомпилирован для RAM.

[_Макс]

Скажите, а какой, собственно, смысл грузиться из SRAM?

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

Сообщение отредактировал _Макс - Jun 11 2010, 19:24

[aaarrr]

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

Зато объем меньше и скорость исполнения программы ниже.

Во-вторых Flash имеет конечное количество циклов перезаписи.

10K - это уже ограничение не столько на число загрузок программы, сколько на число модификаций флеш со стороны самой программы.

[ViKo]

Обнаружил непонятное явление - в Keil при отладке программы в RAM невозможно пользоваться симулятором. На первой же команде выскакивает HardFault.

[-JonnS-]

Наверно надо добавить в RAM.INI строку:
xPSR = 0x1000000;
Подробнее здесь

[ViKo]

Наверно надо добавить в RAM.INI строку:
xPSR = 0x1000000;
Подробнее здесь

Спасибо, помогло.
Теперь новая напасть вылезла. Не находится main функция в минимально простеньком проекте.

Код

  LOAD Keil_Minimal.axf incremental // Download
  Setup();                              // Setup for Running
  GO ,main
______^
*** error 34, line 26: undefined identifier

Хотя main в проекте есть, и по командам симулятор доходит и до нее.

[-JonnS-]

Возможно что надо еще разписать и периферию в ini файле:

Код

MAP 0x40000000, 0x40023400 read write      // Peripferial

Вобщем лучше отключить "go main" запустить симуляцию, смотреть по асм.
Прилагаю свой ram.ini

Ps
Добавить в "Option for Target"->"C/C++"->"Define"

Код

VECT_TAB_SRAM

Сообщение отредактировал -JonnS- - Feb 14 2011, 20:23

Прикрепленные файлы

 RAM.rar ( 583 байт ) Кол-во скачиваний: 70

 

[ViKo]

Прилагаю свой ram.ini
Добавить в "Option for Target"->"C/C++"->"Define"

У меня, практически, такой же файл upd Такой, да не совсем. Посмотрите на мои 2 и 3 строки. По-моему, у вас ошибка.

Код

FUNC void Setup(void) {
  SP = _RDWORD(0x20000000);          // Setup Stack Pointer
  PC = _RDWORD(0x20000004);          // Setup Program Counter
  _WDWORD(0xE000ED08, 0x20000000);   // Setup Vector Table Offset Register
  xPSR = 0x1000000;
}
//  RESET  
//  MAP 0x64000000, 0x6407ffff read write
//  MAP 0x6c000000, 0x6c03ffff read write
//  MAP
  LOAD Keil_Minimal.axf incremental // Download
  Setup();                              // Setup for Running
  G , main

А периферию я не использую, выкинул все. Может, перестарался Вот весь файл с майн

Код

#include "stm32f10x.h"
uint32_t Cnt;
int32_t main(void)
{
  while (1) {
    Cnt++;
  }
}

А "Define" что? Ага, нашел. Нет, у меня такого нет. Работает и так. У меня: STM32F10X_HD

upd2 И с Go разобрался - нужно писать G, а не GO. Исправил в файле, все работает! (ну и лох же я)

[Alex_1811]

Поделитесь рабочим проектом где есть отладка в ОЗУ. Очч нужно.
Начинаю разбираться с переферией и жалко после каждого шага шить флеш.
У меня камень STM32F105VC. Програмлю в uVision 4.20.

Сообщение отредактировал Alex_1811 - Jun 6 2011, 12:08

[skripach]

и жалко после каждого шага шить флеш

Флешку жалеть не надо! Шейте не стесняйтесь jtag'ом или чем вы там шьете её не убить.

[ViKo]

Поделитесь рабочим проектом где есть отладка в ОЗУ.

Так, вроде, всё уже сказано.
В свойствах проекта указываете вместо адресов флэши адреса ОЗУ (половину, например), и адреса ОЗУ подкорректировать на оставшуюся часть. Потом при отладке должен выполниться показанный выше ini файл.
В-принципе, да, никакими отладками всех циклов перезаписи флэши не исчерпать.