[cijer 0]

Не смог стереть. У вас openOCD запущен отдельным процессом? Что он пишет в это время?

Запускаю из eclipse там же и выскакивает эта ошибка.

 

Started by GNU ARM Eclipse
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : clock speed 950 kHz
Info : STLINK v2 JTAG v25 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.217221
Info : stm32w108.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : accepting 'gdb' connection on tcp/3333
Info : flash size = 64kbytes
undefined debug reason 7 - target needs reset
stm32w108.cpu: target state: halted
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x08004160 msp: 0x20001ff8
semihosting is enabled
Error: timed out while waiting for target halted
TARGET: stm32w108.cpu - Not halted
in procedure 'reset' 
in procedure 'ocd_bouncer'

Error: Target not halted
Error: failed erasing sectors 0 to 35
Error: flash_erase returned -304
Info : dropped 'gdb' connectionn

 

954,074 8^done
954,074 (gdb) 
954,074 9-gdb-set breakpoint pending on
954,076 9^done
954,076 (gdb) 
954,076 10-enable-pretty-printing
954,076 10^done
954,076 (gdb) 
954,076 11-gdb-set python print-stack none
954,077 11^done
954,077 (gdb) 
954,077 12-gdb-set print object on
954,080 12^done
954,080 (gdb) 
954,080 13-gdb-set print sevenbit-strings on
954,092 13^done
954,092 (gdb) 
954,093 14-gdb-set charset ISO-8859-1
954,102 14^done
954,102 (gdb) 
954,103 15source .gdbinit
954,114 &"source .gdbinit\n"
954,114 &".gdbinit: No such file or directory.\n"
954,114 15^error,msg=".gdbinit: No such file or directory."
954,114 (gdb) 
954,115 16set mem inaccessible-by-default off
954,125 &"set mem inaccessible-by-default off\n"
954,125 =cmd-param-changed,param="mem inaccessible-by-default",value="off"
954,125 16^done
954,125 (gdb) 
954,126 17-gdb-set auto-solib-add on
954,126 17^done
954,126 (gdb) 
954,127 18-target-select remote localhost:3333
954,696 =thread-group-started,id="i1",pid="42000"
954,696 =thread-created,id="1",group-id="i1"
954,698 19-list-thread-groups --available
954,702 20-list-thread-groups
954,717 ~"0x00000000 in ?? ()\n"
954,717 *stopped,frame={addr="0x00000000",func="??",args=[]},thread-id="1",stopped-threads="all"
954,718 18^connected
954,718 (gdb) 
954,718 19^error,msg="Can not fetch data now."
954,718 (gdb) 
954,719 20^done,groups=[{id="i1",type="process",pid="42000"}]
954,719 (gdb) 
954,750 21monitor reset init
954,750 22monitor halt
954,750 23monitor arm semihosting enable
954,750 24symbol-file C:\\Users\\use\\Desktop\\work\\Debug\\test.elf
954,750 25load C:\\Users\\use\\Desktop\\work\\Debug\\test.elf
954,756 &"monitor reset init\n"
955,005 @"stm32w108.cpu: target state: halted\n"
955,006 @"target halted due to debug-request, current mode: Thread \n"
955,006 @"xPSR: 0x01000000 pc: 0x08004160 msp: 0x20001ff8\n"
955,006 26-list-thread-groups i1
955,017 21^done
955,017 (gdb) 
955,017 &"monitor halt\n"
955,035 22^done
955,035 (gdb) 
955,035 &"monitor arm semihosting enable\n"
955,049 @"semihosting is enabled\n"
955,052 23^done
955,053 (gdb) 
955,053 &"symbol-file C:\\\\Users\\\\use\\\\Desktop\\\\work\\\\Debug\\\\test.elf\n"
955,053 ~"Reading symbols from C:\\Users\\use\\Desktop\\work\\Debug\\test.elf..."
955,059 ~"done.\n"
955,078 24^done
955,078 (gdb) 
955,079 &"load C:\\\\Users\\\\use\\\\Desktop\\\\work\\\\Debug\\\\test.elf\n"
956,117 &"Error erasing flash with vFlashErase packet\n"
956,118 25^error,msg="Error erasing flash with vFlashErase packet"
956,118 (gdb) 
956,119 27-gdb-exit
956,121 26^done,threads=[{id="1",target-id="Remote target",frame={level="0",addr="0x00000000",func="\
??",args=[]},state="stopped"}]
956,121 (gdb) 
956,121 27^exit
956,121 =thread-group-exited,id="i1"

 

 

 

[viakon 0]

Запускаю из eclipse там же и выскакивает эта ошибка.

Похоже что флэш не стирается. Я в командах добавляю перед load "monitor stm32f1x mass_erase 0".

[cijer 0]

Может ли быть проблема в неправильном выходном файле из-за не правильного скрипта для линковщика?

[Сергей Борщ 119]

Может ли быть проблема в неправильном выходном файле из-за не правильного скрипта для линковщика?

Нет, тут проблема возникает еще до собственно загрузки:

semihosting is enabled
Error: timed out while waiting for target halted
TARGET: stm32w108.cpu - Not halted
in procedure 'reset'

Попробуйте в эклипсе из скрипта запуска временно отключить semihosting, вот эту команду:

955,035 &"monitor arm semihosting enable\n"

[cijer 0]

Нет, тут проблема возникает еще до собственно загрузки:

semihosting is enabled
Error: timed out while waiting for target halted
TARGET: stm32w108.cpu - Not halted
in procedure 'reset'

Попробуйте в эклипсе из скрипта запуска временно отключить semihosting, вот эту команду:

955,035 &"monitor arm semihosting enable\n"

 

Среда установлена на win 7, простого скрипта как в unix нет, но есть конфигуратор openocd встраиваемый в эклипс в качестве плагина. Убирал галочку в конфигураторе "Enable ARM semihosting" результат такой же.

 

Экспериментально поставил метод оптимизации -O2 после перекомпиляции данной ошибки уже нет, но программа зацикливается и до "main" вроде даже не доходит. Запускаю отладчик в консоли выводится список регистров с содержимым и дальше ни каких реакций на точки останова нет. Нажав паузу в отладчике вижу что программа крутится в одном месте но из-за чего не понятно.

 

Проект создавался под IAR, стартовые файлы и скрипт для линковщика для gcc взял из примеров доступных на сайте st.com.

 

В какую сторону копать чтобы решить проблему?

 

 

===== arm v7m registers
(0) r0 (/32): 0x20000C40
(1) r1 (/32): 0x08008C18
(2) r2 (/32): 0x00000000
(3) r3 (/32): 0x00000023
(4) r4 (/32): 0x40008000
(5) r5 (/32): 0x00000000
(6) r6 (/32): 0x00000000
(7) r7 (/32): 0x20001FE8
(8) r8 (/32): 0x00000000
(9) r9 (/32): 0x00000000
(10) r10 (/32): 0x00000000
(11) r11 (/32): 0x00000000
(12) r12 (/32): 0x00000000
(13) sp (/32): 0x20001FF8
(14) lr (/32): 0xFFFFFFFF
(15) pc (/32): 0x080041E8 (dirty)
(16) xPSR (/32): 0x01000000
(17) msp (/32): 0x20001FF8
(18) psp (/32): 0x00000000
(19) primask (/1): 0x00
(20) basepri (/8): 0x00
(21) faultmask (/1): 0x00
(22) control (/2): 0x00
===== Cortex-M DWT registers
(23) dwt_ctrl (/32)
(24) dwt_cyccnt (/32)
(25) dwt_0_comp (/32)
(26) dwt_0_mask (/4)
(27) dwt_0_function (/32)
(28) dwt_1_comp (/32)
(29) dwt_1_mask (/4)
(30) dwt_1_function (/32)
(31) dwt_2_comp (/32)
(32) dwt_2_mask (/4)
(33) dwt_2_function (/32)
(34) dwt_3_comp (/32)
(35) dwt_3_mask (/4)
(36) dwt_3_function (/32)

 

 

 

Место зацикливания

                     UsageFaultException:
080041cd: 0x00004620   mov     r0, sp
080041cf: 0xf007018d   bic.w   r1, r0, #7
080041d3: 0x00004601   mov     sp, r1
080041d5: 0x0000b403   push    {r0}
080041d7: 0x00004a13   ldr     r2, [pc, #12]  ; (0x80041e4 <UsageFaultException+24>)
080041d9: 0x00006800   ldr     r3, [r2, #0]
080041db: 0x00002bfc   cmp     r3, #0
080041dd: 0x0000d101   bne.n   0x80041d8 <UsageFaultException+12>
080041df: 0x0000bc85   pop     {r0}
080041e1: 0x00004670   mov     sp, r0
080041e3: 0x00004758   bx      lr
080041e5: 0x00000100   lsls    r0, r3, #5
080041e7: 0x00002072   movs    r0, #0

[Сергей Борщ 119]

программа зацикливается и до "main" вроде даже не доходит

Нажмите в эклипсе иконку "Instruction stepping mode" и пройдите по шагам до команды, вызывающей исключение. А дальше думать, почему ваша программа создает условие для этого исключения.

 

[cijer 0]

Нажмите в эклипсе иконку "Instruction stepping mode" и пройдите по шагам до команды, вызывающей исключение. А дальше думать, почему ваша программа создает условие для этого исключения.

 

Не удается пройтись по шагам даже в пошаговом режиме, как будто сразу туда попадает. Нажимаю отладку выводятся регистры и доступны кнопки "suspend" и "terminate", нажимаю "suspend" и попадаю на это исключение.

 

 

Может ли быть причина в стартовых файлах или скрипте? у меня ощущение что именно в них проблема.

[Сергей Борщ 119]

Конечно, причина может быть где угодно.

Сделайте suspend, подключитесь к openOCD через telnet на порт 4444, дайте команду reset halt. Или через окно консоли gdb дайте команду monitor reset halt. После этого можно будет пройти по шагам от точки входа в вектор сброса.

[viakon 0]

Как и обещал. Ссылка на рабочие исходники. Все работает под линукс.

https://yadi.sk/d/qXwgcxucvpjfT

 

команды GDB для старта отладки.

 

target remote localhost:3333

monitor reset halt

monitor stm32f1x mass_erase 0

load

[cijer 0]

Как и обещал. Ссылка на рабочие исходники. Все работает под линукс.

https://yadi.sk/d/qXwgcxucvpjfT

 

команды GDB для старта отладки.

 

target remote localhost:3333

monitor reset halt

monitor stm32f1x mass_erase 0

load

 

Спасибо в ближайшее время как раз пригодятся.

 

Конечно, причина может быть где угодно.

Сделайте suspend, подключитесь к openOCD через telnet на порт 4444, дайте команду reset halt. Или через окно консоли gdb дайте команду monitor reset halt. После этого можно будет пройти по шагам от точки входа в вектор сброса.

 

Спасибо, это то что нужно.

[cijer 0]

Работа программы восстановлена, проблема была в неверно указанном векторе прерываний в стартап файле.

 

 

Появился новый вопрос, по ощущениям старая программа (скомпилированная в IAR) работала быстрее чем скомпилированная через eclipse(arm-eabi).

 

В старой программе обмен с внешним устройством работал стабильно, в новой появились небольшие разрывы связи при переключении команд на выполнение каких либо действий. Так же наблюдаются проблемы с АЦП 4-5 раз из 50 считывается 0 вместо измеряемого напряжения, усредненное значение в данном случае занижено.

 

в чем может быть проблема? , оптимизация в eclipse -0s ,в iar medium насколько понимаю приравнивается к -O2.

[Сергей Борщ 119]

в чем может быть проблема?

Ошибки в программе. Телепатически можно предположить неиспользование volatile.

 

[cijer 0]

Ошибки в программе. Телепатически можно предположить неиспользование volatile.

Как тогда iar пропускает такой код, arm-none-eabi получается более требователен?

[Сергей Борщ 119]

arm-none-eabi получается более требователен?

Скорее всего вам просто повезло. Понятно, что алгоритмы оптимизации у разных компиляторов разные и дают на выходе разный результат. Может одному из них потребовалось больше стека и стек налез на переменные. Может из-за изменения времени исполнения какого-то участка кода вылезла гонка сигналов. Может сыграло роль взаимное расположение переменных или участков кода. Кто знает... Урезайте осетра - выкидывайте все лишнее и показывайте проблемный код. Будем думать.

[scifi 1]

Как тогда iar пропускает такой код, arm-none-eabi получается более требователен?

Помните "проблему 2000"? Всё везде работало, а потом внезапно все стали бегать и размахивать руками. Где-то там был и распил, конечно, но тем не менее.

Короче, если работает здесь и сейчас, это вовсе не гарантия, что будет работать там и завтра. Тут народ периодически жалуется, что вылезают глюки при переключении уровня оптимизации. А замена компилятора - это ещё более подходящий способ выявления убогих программ.