[_Maks 0]

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

 

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

 

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

[skripach 5]

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

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

[Dron_Gus 2]

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

[aaarrr 63]

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

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

[_Maks 0]

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

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

[skripach 5]

Сам не пробовал но...

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

  // 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);

[_Maks 0]

Сам не пробовал но...

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

  // 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 0]

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

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

[_Maks 0]

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

[aaarrr 63]

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

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

[msalov 0]

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

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

[_Maks 0]

У меня по адресу 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 1]

Пытаюсь запускать программу из 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 1]

Попробую сформулировать вопрос проще.

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

[KRS 0]

Попробую сформулировать вопрос проще.

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

Таблица векторов начинается с VTOR, по умолчанию он 0.

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

Что бы отлаживаться в озу, я в стартап скрипте отладчика устанавливаю VTOR на ОЗУ.