STM32 новичку в ARM что к чему

Andrew Martin

С точки зрения процессора подойдёт и 4-байтное выравнивание для кода. Но некоторые дизассемблеры/отладчики (например Keil) путаются.

Код:

        bl      _delay_ms
        b       @r

        align   4
_delay_ms:

        push    {r1, r2, r3}
        ldr     r1, [_stk_base]

в Кейле:

Код:

0x000000AC F000F802  BL.W     _delay_ms (0x000000B4)
0x000000B0 E7F8         B        0x000000A4
0x000000B2 FFFFB40E  DCD      0xB40EFFFF
0x000000B6 4919        LDR      r1,[pc,#100]  ; @0x0000011C

Как сами видите, ваш push кейловский дизасм не опознал, как и метку _delay_ms

А в параметрах секции лучше задавать выравнивание 4, просто потому что родной комплект ARMASM/ARMLINK так делает. Хотя можно и 2 - тоже работает :))

Реклама

Alexey_N

Задал для кода - 2, фасм делает 21 проход :shock:

, когда 4 - 6 проходов. objdump нормально распознает все функции, правда их тело не всегда дизассемблирует, представляя его в виде набора байт, а не инструкций.

Код:

00000154 <_gpio_reset_bits>:
 154:   f8dfb5a0    .word   0xf8dfb5a0
 158:   68fd7424    .word   0x68fd7424
 15c:   60fd43b5    .word   0x60fd43b5
 160:   ffffbda0    .word   0xffffbda0

Реклама

Andrew Martin

Исходник тот же? Если нет - выкладывайте.

Alexey_N

Исходник другой, в котором я пытаюсь разобраться в работе с spi и tft экраном.

Реклама

Выбираем индустриальные и медицинские источники питания MEAN WELL в открытом исполнении

Использование модульных источников питания открытого типа широко распространено в современных устройствах. Присущие им компактность, гибкость в интеграции и высокая эффективность делают их отличным решением для систем промышленной автоматизации, телекоммуникационного оборудования, медицинской техники, устройств «умного дома» и прочих приложений. Рассмотрим подробнее характеристики и особенности трех самых популярных вариантов AC/DC-преобразователей MW открытого типа, подходящих для применения в промышленных устройствах - серий EPS, EPP и RPS представленных на Meanwell.market.

Подробнее>>

Andrew Martin

У меня получилось вот что (при выравнивании кода 2)

Код:

Disassembly of section .text:

00000000 <_entry_point-0x40>:
BFD: Dwarf Error: mangled line number section.
   0:   5000         str   r0, [r0, r0]
   2:   2000         movs   r0, #0
   4:   0041         lsls   r1, r0, #1
   6:   0000         movs   r0, r0
   8:   00e7         lsls   r7, r4, #3
   a:   0000         movs   r0, r0
   c:   00e9         lsls   r1, r5, #3
   e:   0000         movs   r0, r0
  10:   00ef         lsls   r7, r5, #3
  12:   0000         movs   r0, r0
  14:   00f1         lsls   r1, r6, #3
  16:   0000         movs   r0, r0
  18:   00f3         lsls   r3, r6, #3
   ...
  3a:   0000         movs   r0, r0
  3c:   00f5         lsls   r5, r6, #3
   ...

00000040 <_entry_point>:
_entry_point():
  40:   4932         ldr   r1, [pc, #200]   ; (10c <_flash_acr>)
  42:   6808         ldr   r0, [r1, #0]
  44:   f040 0012    orr.w   r0, r0, #18
  48:   6008         str   r0, [r1, #0]
  4a:   4f2f         ldr   r7, [pc, #188]   ; (108 <_rcc_base>)
  4c:   6838         ldr   r0, [r7, #0]
  4e:   f040 5080    orr.w   r0, r0, #268435456   ; 0x10000000
  52:   f440 3080    orr.w   r0, r0, #65536   ; 0x10000
  56:   6038         str   r0, [r7, #0]
  58:   6838         ldr   r0, [r7, #0]
  5a:   f410 3f00    tst.w   r0, #131072   ; 0x20000
  5e:   d0fb         beq.n   58 <_entry_point+0x18>
  60:   6878         ldr   r0, [r7, #4]
  62:   f440 5010    orr.w   r0, r0, #9216   ; 0x2400
  66:   f440 10e8    orr.w   r0, r0, #1900544   ; 0x1d0000
  6a:   6078         str   r0, [r7, #4]
  6c:   6838         ldr   r0, [r7, #0]
  6e:   f040 7080    orr.w   r0, r0, #16777216   ; 0x1000000
  72:   6038         str   r0, [r7, #0]
  74:   6838         ldr   r0, [r7, #0]
  76:   f010 7f00    tst.w   r0, #33554432   ; 0x2000000
  7a:   d0fb         beq.n   74 <_entry_point+0x34>
  7c:   6878         ldr   r0, [r7, #4]
  7e:   f040 0002    orr.w   r0, r0, #2
  82:   6078         str   r0, [r7, #4]
  84:   6878         ldr   r0, [r7, #4]
  86:   f010 0f08    tst.w   r0, #8
  8a:   d0fb         beq.n   84 <_entry_point+0x44>
  8c:   69b8         ldr   r0, [r7, #24]
  8e:   f040 0008    orr.w   r0, r0, #8
  92:   61b8         str   r0, [r7, #24]
  94:   4f20         ldr   r7, [pc, #128]   ; (118 <_gpiob_base>)
  96:   4821         ldr   r0, [pc, #132]   ; (11c <_gpiob_bits>)
  98:   6038         str   r0, [r7, #0]
  9a:   f44f 70fa    mov.w   r0, #500   ; 0x1f4
  9e:   bfe4         itt   al
  a0:   2200         moval   r2, #0
  a2:   2303         moval   r3, #3
  a4:   60fb         str   r3, [r7, #12]
  a6:   f000 f804    bl   b2 <_delay_ms>
  aa:   60fa         str   r2, [r7, #12]
  ac:   f000 f801    bl   b2 <_delay_ms>
  b0:   e7f8         b.n   a4 <_entry_point+0x64>

000000b2 <_delay_ms>:
_delay_ms():
  b2:   b40e         push   {r1, r2, r3}
  b4:   4916         ldr   r1, [pc, #88]   ; (110 <_stk_base>)
  b6:   ea82 0202    eor.w   r2, r2, r2
  ba:   600a         str   r2, [r1, #0]
  bc:   608a         str   r2, [r1, #8]
  be:   4b11         ldr   r3, [pc, #68]   ; (104 <_dd_tick>)
  c0:   601a         str   r2, [r3, #0]
  c2:   4a14         ldr   r2, [pc, #80]   ; (114 <_stk_init>)
  c4:   604a         str   r2, [r1, #4]
  c6:   f04f 0207    mov.w   r2, #7
  ca:   600a         str   r2, [r1, #0]
  cc:   680a         ldr   r2, [r1, #0]
  ce:   f412 3f80    tst.w   r2, #65536   ; 0x10000
  d2:   d0fb         beq.n   cc <_delay_ms+0x1a>
  d4:   4b0b         ldr   r3, [pc, #44]   ; (104 <_dd_tick>)
  d6:   681a         ldr   r2, [r3, #0]
  d8:   4282         cmp   r2, r0
  da:   d3f7         bcc.n   cc <_delay_ms+0x1a>
  dc:   ea82 0202    eor.w   r2, r2, r2
  e0:   600a         str   r2, [r1, #0]
  e2:   bc0e         pop   {r1, r2, r3}
  e4:   4770         bx   lr

000000e6 <_def_handler>:
_def_handler():
  e6:   e7fe         b.n   e6 <_def_handler>

000000e8 <_hrd_handler>:
_hrd_handler():
  e8:   4b0d         ldr   r3, [pc, #52]   ; (120 <_hfsr_reg>)
  ea:   6818         ldr   r0, [r3, #0]
  ec:   e7fc         b.n   e8 <_hrd_handler>

000000ee <_mm_handler>:
_mm_handler():
  ee:   e7fe         b.n   ee <_mm_handler>

000000f0 <_bus_handler>:
_bus_handler():
  f0:   e7fe         b.n   f0 <_bus_handler>

000000f2 <_usg_handler>:
_usg_handler():
  f2:   e7fe         b.n   f2 <_usg_handler>

000000f4 <_sti_handler>:
_sti_handler():
  f4:   b490         push   {r4, r7}
  f6:   4f03         ldr   r7, [pc, #12]   ; (104 <_dd_tick>)
  f8:   683c         ldr   r4, [r7, #0]
  fa:   3401         adds   r4, #1
  fc:   603c         str   r4, [r7, #0]
  fe:   bc90         pop   {r4, r7}
 100:   4770         bx   lr
 102:   ffff 0000    vaddl.u<illegal width 64>   q8, d15, d0

00000104 <_dd_tick>:
 104:   0000         movs   r0, r0
 106:   2000         movs   r0, #0

00000108 <_rcc_base>:
 108:   1000         asrs   r0, r0, #32
 10a:   4002         ands   r2, r0

0000010c <_flash_acr>:
 10c:   2000         movs   r0, #0
 10e:   4002         ands   r2, r0

00000110 <_stk_base>:
 110:   e010         b.n   134 <_hfsr_reg+0x14>
 112:   e000         b.n   116 <_stk_init+0x2>

00000114 <_stk_init>:
 114:   1940         adds   r0, r0, r5
 116:   0001         movs   r1, r0

00000118 <_gpiob_base>:
 118:   0c00         lsrs   r0, r0, #16
 11a:   4001         ands   r1, r0

0000011c <_gpiob_bits>:
 11c:   4433         add   r3, r6
 11e:   4444         add   r4, r8

00000120 <_hfsr_reg>:
 120:   ed2c e000    stc   0, cr14, [ip, #-0]

Реклама

Alexey_N

Это чем и с какими ключами?

Реклама

Распродажа паяльного оборудования ATTEN!
Паяльные станции, паяльники и аксессуары по самой выгодной цене.

По промокоду radiokot скидка 10%

Andrew Martin

arm-none-eabi-objdump.exe -m arm -l --disassembler-options=force-thumb -D main103.axf

Alexey_N

а я указывал

Код:

arm-none-eabi-objdump.exe -t -d -m arm7tdmi --disassembler-options=force-thumb -w -j .text -j .data main103

, может в -m дело ...

Andrew Martin

Может быть. Странно, работая с кортексами, указывать arm7tdmi.

Реклама

Alexey_N

А что надо указывать? cortex-m3 вроде как не arm в прямом смысле, у него же только thumb-2 набор инструкций как я понял ...
Указал -m arm, листинг дизассемблера практически не изменился (или я не заметил).

baghear

Добрый день, возник такой вопрос если в main объявляю порядка 15 локальных переменных и запускаю программу, данные, хранящиеся в переменных портятся(что-то их перезаписывает).
Думал стек разросся, понаблюдал за ним до переполнения стека еще далеко, если правильно понимаю то в map файле стек ограничен двумя адресами

Код:

STACK                                    0x20000480   Section     1024  startup_stm32f10x_hd.o(STACK)
    Stack_Mem                                0x20000480   Data        1024  startup_stm32f10x_hd.o(STACK)
    __initial_sp                             0x20000880   Data           0  startup_stm32f10x_hd.o(STACK)

Может где-то рассуждения ошибочны?
Почему такое может происходить?
Если переменные объявить как static, или глобально то программа начинает нормально работать и данные не портятся.

baghear

Добрый день, подскажите пожалуйста можно ли узнать, адреса границ каждого из стеков?

scorpi_0n

А оно нужно? Сомневаетесь в стеке просто увеличьте его. Если пользуетесь кучей то и кучу заодно.
Судя по вашему предыдущему сообщению дело не в стеке. Почитайте про квалификаторы область видимости и время жизни переменных. В вашем случае перестарался оптимизатор. Какую-то переменную (переменные) понадобится объявить как volatile чтобы оптимизатор не сильно своевольничал.

Pnjom-Penb

scorpi_0n писал(а):

Почитайте про квалификаторы область видимости и время жизни переменных. В вашем случае перестарался оптимизатор.

Т.к. проблемные переменные объявлены в main'е, время их жизни - от включения и до выключения. Какие режимы оптимизации могут тут помешать?

scorpi_0n

Зависит от политики оптимизатора.
Прочитайте внимательно сам вопрос.

Цитата:

если в main объявляю порядка 15 локальных переменных и запускаю программу, данные, хранящиеся в переменных портятся(что-то их перезаписывает).

И как бы само решение.

Цитата:

Если переменные объявить как static, или глобально то программа начинает нормально работать и данные не портятся.

Глобальные вроде тоже живут от включения и до выключения. Но оптимизатор почему-то решил что в одном случае можно напортачить а в другом нет. Возможно потому что main типа тоже функция.

Pnjom-Penb

scorpi_0n писал(а):

Глобальные вроде тоже живут от включения и до выключения.

Да, это так, но они живут не на стеке.

scorpi_0n писал(а):

Но оптимизатор почему-то решил что в одном случае можно напортачить а в другом нет.

Это не оптимизатор решил, а стек и куча наложились друг на друга. А как только эти переменные объявляются статическими, им эта чехарда уже не грозит. Я бы попробовал сначала самое простое решение - увеличение стека(*). И это выше уже советовали. Если чехарда прекратится при достаточном стеке, то уже дальше можно выяснять, когда, где и как это происходит. Или не выяснять, просто оставив найденный безопасный размер стека. У IAR'а был хороший документ на эту тему, но это не самый простой труд, отслеживание таких проблем. Проще иметь запас.

(*) Если конечно в программе нет ошибок типа рекурсии с неверным условием выхода. :)))

scorpi_0n

Pnjom-Penb писал(а):

Это не оптимизатор решил, а стек и куча наложились друг на друга.

Не факт. По крайней мере уверяют что

Цитата:

Думал стек разросся, понаблюдал за ним до переполнения стека еще далеко

.
А так да. Не зная что там к чему советовать тяжеловато. Можно на проблемном участке и в дизасме полазить посмотреть что там творится.

Pnjom-Penb

scorpi_0n писал(а):

По крайней мере уверяют что ...

Я хотел спросить, как было установлено, что стека достаточно, но увидев в качестве пояснения только пару строк из мапа, не стал расспрашивать.

scorpi_0n писал(а):

Можно на проблемном участке и в дизасме полазить посмотреть что там творится.

Разумеется. Но сначала я бы попробовал более простое и короткое решение, а уж потом, в зависимости от результата...

baghear

То что стек не разросся установленно было так, перед выполнением программы он заполнялся шаблоном СССССС и потом мониторился во вкладке memory, по адресу указанному в map файле.

Размер стека увеличивал не помогло.

То же думаю что локальные переменные хранятся в стеке, от и до жизни программы, но дело в том что стека то, два, может один налазит на другой?

scorpi_0n

baghear писал(а):

Размер стека увеличивал не помогло.

Значит быстрее всего дело не в стеке или мало увеличили.

Цитата:

То же думаю что локальные переменные хранятся в стеке, от и до жизни программы

Да не факт. Если компилятор посчитает какой-то кусок ненужным он его запросто выбросит вместе с переменной.
Прерывания есть? Есть переменные которые изменяются в майне и в прерывании?

STM32 новичку в ARM что к чему

Кто сейчас на форуме