Menu
▾
▴
openocd-devel
|
From: Lorenzo C. <lor...@eu...> - 2016-05-31 09:51:27
|
Hello,
i would like to flash the STM32F7 via openocd using J-TAG port.
I just downloaded and installed the latest version from Git repo.
There is some ( errors? ) warnings when scan the J-TAG chain.
Here is the short log of the J-TAG chain scan:
Debug: 306 8 mpsse.c:772 mpsse_set_frequency(): actually 600000 Hz
Debug: 307 8 core.c:1598 adapter_khz_to_speed(): convert khz to
interface specific speed value
Debug: 308 8 core.c:1601 adapter_khz_to_speed(): have interface set up
Info : 309 8 core.c:1386 adapter_init(): clock speed 600 kHz
Debug: 310 8 openocd.c:135 handle_init_command(): Debug Adapter init
complete
Debug: 311 8 command.c:143 script_debug(): command - ocd_command
ocd_command type ocd_transport init
Debug: 312 8 command.c:143 script_debug(): command - ocd_transport
ocd_transport init
Debug: 314 8 transport.c:239 handle_transport_init(): handle_transport_init
Debug: 315 8 core.c:729 jtag_add_reset(): SRST line released
Debug: 316 8 core.c:753 jtag_add_reset(): TRST line released
Debug: 317 8 core.c:327 jtag_call_event_callbacks(): jtag event: TAP reset
Debug: 318 212 command.c:143 script_debug(): command - ocd_command
ocd_command type ocd_jtag arp_init
Debug: 319 212 command.c:143 script_debug(): command - ocd_jtag ocd_jtag
arp_init
Debug: 320 212 core.c:1399 jtag_init_inner(): Init JTAG chain
Debug: 321 212 core.c:327 jtag_call_event_callbacks(): jtag event: TAP reset
Debug: 322 212 core.c:1060 jtag_examine_chain(): DR scan interrogation
for IDCODE/BYPASS
Debug: 323 212 core.c:327 jtag_call_event_callbacks(): jtag event: TAP reset
Info : 324 213 core.c:959 jtag_examine_chain_display(): JTAG tap:
stm32f7x.cpu tap/device found: 0x5ba00477 (mfg: 0x23b (ARM Ltd.), part:
0xba00, ver: 0x5)
Info : 325 213 core.c:959 jtag_examine_chain_display(): JTAG tap:
stm32f7x.bs tap/device found: 0x06449041 (mfg: 0x020
(STMicroelectronics), part: 0x6449, ver: 0x0)
Warn : 326 213 core.c:959 jtag_examine_chain_display(): JTAG tap:
stm32f7x.bs UNEXPECTED: 0x06449041 (mfg: 0x020
(STMicroelectronics), part: 0x6449, ver: 0x0)
Error: 327 213 core.c:959 jtag_examine_chain_display(): JTAG tap:
stm32f7x.bs expected 1 of 1: 0x06449071 (mfg: 0x038 (UTMC), part:
0x6449, ver: 0x0)
Error: 328 213 core.c:1444 jtag_init_inner(): Trying to use configured
scan chain anyway...
Debug: 329 213 core.c:1190 jtag_validate_ircapture(): IR capture
validation scan
Debug: 330 213 core.c:1248 jtag_validate_ircapture(): stm32f7x.cpu: IR
capture 0x01
Debug: 331 214 core.c:1248 jtag_validate_ircapture(): stm32f7x.bs: IR
capture 0x01
Warn : 332 214 core.c:1467 jtag_init_inner(): Bypassing JTAG setup
events due to errors
Debug: 333 214 openocd.c:148 handle_init_command(): Examining targets...
Debug: 334 214 target.c:1499 target_call_event_callbacks(): target event
21 (examine-start)
But when it tries to flash the application it bails out with the
following error:
Debug: 335 214 arm_adi_v5.c:603 dap_dp_init():
Debug: 336 214 arm_adi_v5.c:636 dap_dp_init(): DAP: wait CDBGPWRUPACK
Debug: 337 214 arm_adi_v5.h:428 dap_dp_poll_register(): DAP: poll 4,
mask 0x20000000, value 0x20000000
Debug: 338 215 arm_adi_v5.c:643 dap_dp_init(): DAP: wait CSYSPWRUPACK
Debug: 339 215 arm_adi_v5.h:428 dap_dp_poll_register(): DAP: poll 4,
mask 0x80000000, value 0x80000000
Debug: 340 217 arm_adi_v5.c:787 dap_find_ap(): Found AHB-AP at AP index:
0 (IDR=0x74770001)
Debug: 341 218 arm_adi_v5.c:714 mem_ap_init(): MEM_AP Packed Transfers:
enabled
Debug: 342 218 arm_adi_v5.c:725 mem_ap_init(): MEM_AP CFG: large data 0,
long address 0, big-endian 0
Debug: 343 218 target.c:2224 target_read_u32(): address: 0xe000ed00,
value: 0x410fc271
Debug: 344 218 cortex_m.c:1923 cortex_m_examine(): Cortex-M7 r0p1
processor detected
Warn : 345 218 cortex_m.c:1929 cortex_m_examine(): Silicon bug: single
stepping will enter pending exception handler!
Debug: 346 218 cortex_m.c:1931 cortex_m_examine(): cpuid: 0x410fc271
Debug: 347 218 target.c:2312 target_write_u32(): address: 0xe000edfc,
value: 0x01000000
Debug: 348 219 target.c:2224 target_read_u32(): address: 0xe0002000,
value: 0x10000081
Debug: 349 219 target.c:2312 target_write_u32(): address: 0xe0002008,
value: 0x00000000
Debug: 350 220 target.c:2312 target_write_u32(): address: 0xe000200c,
value: 0x00000000
Debug: 351 221 target.c:2312 target_write_u32(): address: 0xe0002010,
value: 0x00000000
Debug: 352 221 target.c:2312 target_write_u32(): address: 0xe0002014,
value: 0x00000000
Debug: 353 222 target.c:2312 target_write_u32(): address: 0xe0002018,
value: 0x00000000
Debug: 354 222 target.c:2312 target_write_u32(): address: 0xe000201c,
value: 0x00000000
Debug: 355 223 target.c:2312 target_write_u32(): address: 0xe0002020,
value: 0x00000000
Debug: 356 223 target.c:2312 target_write_u32(): address: 0xe0002024,
value: 0x00000000
Debug: 357 224 cortex_m.c:2005 cortex_m_examine(): FPB fpcr 0x10000081,
numcode 8, numlit 0
Debug: 358 224 target.c:2224 target_read_u32(): address: 0xe0001000,
value: 0x40000001
Debug: 359 224 target.c:2312 target_write_u32(): address: 0xe0001028,
value: 0x00000000
Debug: 360 225 target.c:2312 target_write_u32(): address: 0xe0001038,
value: 0x00000000
Debug: 361 225 target.c:2312 target_write_u32(): address: 0xe0001048,
value: 0x00000000
Debug: 362 226 target.c:2312 target_write_u32(): address: 0xe0001058,
value: 0x00000000
Debug: 363 226 cortex_m.c:1842 cortex_m_dwt_setup(): DWT dwtcr
0x40000001, comp 4, watch/trigger
Info : 364 226 cortex_m.c:2015 cortex_m_examine(): stm32f7x.cpu:
hardware has 8 breakpoints, 4 watchpoints
Debug: 365 226 target.c:1499 target_call_event_callbacks(): target event
22 (examine-end)
Debug: 366 226 target.c:4254 target_handle_event(): target: (0)
stm32f7x.cpu (cortex_m) event: 22 (examine-end) action:
# DBGMCU_CR |= DBG_STANDBY | DBG_STOP | DBG_SLEEP
mmw 0xE0042004 0x00000007 0
# Stop watchdog counters during halt
# DBGMCU_APB1_FZ |= DBG_IWDG_STOP | DBG_WWDG_STOP
mmw 0xE0042008 0x00001800 0
Debug: 367 227 command.c:143 script_debug(): command - ocd_command
ocd_command type ocd_mww 0xE0042004 7
Debug: 368 227 command.c:143 script_debug(): command - mww ocd_mww
0xE0042004 7
Error: 369 228 cortex_m.c:504 cortex_m_poll(): stm32f7x.cpu -- clearing
lockup after double fault
Debug: 370 229 target.c:1499 target_call_event_callbacks(): target event
0 (gdb-halt)
Debug: 3783 3557 target.c:2224 target_read_u32(): address: 0x20000050,
value: 0x20000054
Debug: 3784 3557 target.c:934 target_run_flash_async_algorithm(): offs
0x0 count 0x20000 wp 0x20000054 rp 0x20000054
Debug: 3785 3557 target.c:2015 target_write_buffer(): writing buffer of
16374 byte at 0x20000054
Info : 3786 3920 adi_v5_jtag.c:481 jtagdp_overrun_check(): DAP
transaction stalled (WAIT) - slowing down
Debug: 3788 4492 target.c:2312 target_write_u32(): address: 0x2000004c,
value: 0x2000404a
Debug: 3789 4493 target.c:2224 target_read_u32(): address: 0x20000050,
value: 0x20000054
Debug: 3790 4493 target.c:934 target_run_flash_async_algorithm(): offs
0x3ff6 count 0x1e005 wp 0x2000404a rp 0x20000054
Debug: 3791 4504 target.c:2224 target_read_u32(): address: 0x20000050,
value: 0x20000054
Debug: 3792 4504 target.c:934 target_run_flash_async_algorithm(): offs
0x3ff6 count 0x1e005 wp 0x2000404a rp 0x20000054
Debug: 3793 4515 target.c:2224 target_read_u32(): address: 0x20000050,
value: 0x20000054
Debug: 3794 4515 target.c:934 target_run_flash_async_algorithm(): offs
0x3ff6 count 0x1e005 wp 0x2000404a rp 0x20000054
Debug: 3796 4526 target.c:2224 target_read_u32(): address: 0x20000050,
value: 0x20000054
Debug: 3797 4526 target.c:934 target_run_flash_async_algorithm(): offs
0x3ff6 count 0x1e005 wp 0x2000404a rp 0x20000054
Debug: 3798 4537 target.c:2224 target_read_u32(): address: 0x20000050,
value: 0x20000054
Debug: 3799 4537 target.c:934 target_run_flash_async_algorithm(): offs
0x3ff6 count 0x1e005 wp 0x2000404a rp 0x20000054
ebug: 4802 10098 target.c:934 target_run_flash_async_algorithm(): offs
0x3ff6 count 0x1e005 wp 0x2000404a rp 0x20000054
Error: 4803 10108 target.c:968 target_run_flash_async_algorithm():
timeout waiting for algorithm, a target reset is recommended
Error: 4804 10109 stm32f2x.c:596 stm32x_write_block(): error executing
stm32x flash write algorithm
Error: 4805 10109 stm32f2x.c:604 stm32x_write_block(): flash write
failed = 00000040
Debug: 4806 10109 target.c:2312 target_write_u32(): address: 0x40023c0c,
value: 0x00000040
Debug: 4807 10110 target.c:1828 target_free_working_area_restore():
freed 16384 bytes of working area at address 0x2000004c
Debug: 4808 10110 target.c:1622 print_wa_layout(): *
0x20000000-0x2000004b (76 bytes)
Debug: 4809 10110 target.c:1622 print_wa_layout(): 0x2000004c-0x2003ffff
(262068 bytes)
Debug: 4810 10110 target.c:1828 target_free_working_area_restore():
freed 76 bytes of working area at address 0x20000000
Debug: 4811 10110 target.c:1622 print_wa_layout(): 0x20000000-0x2003ffff
(262144 bytes)
Error: 4812 10110 core.c:91 flash_driver_write(): error writing to flash
at address 0x08000000 at offset 0x00000000
Debug: 4813 10110 command.c:626 run_command(): Command failed with error
code -4
User : 4814 10110 command.c:687 command_run_line():
I see the same issue in the mailing list:
https://sourceforge.net/p/openocd/mailman/message/34621407/
Here is the full log:
http://pastebin.com/3ubK6JXs
Thank you in advance for any help/clue/hint you will give me.
Lorenzo
--
*Lorenzo Corti* | Ricerca e Sviluppo
*Eurek s.r.l. *Via Celletta 8/b | 40026 Imola (BO) - Italy | +39 *0542
609120*
lor...@eu... <mailto:lor...@eu...> | www.eurek.it
<http://www.eurek.it/>
|
|
From: Lorenzo C. <lor...@eu...> - 2016-05-31 12:16:27
|
Il 31/05/2016 13:41, Uwe Bonnes ha scritto: >>>>>> "Lorenzo" == Lorenzo Corti <lor...@eu...> writes: > Lorenzo> Hello, i would like to flash the STM32F7 via openocd using > Lorenzo> J-TAG port. I just downloaded and installed the latest version > Lorenzo> from Git repo. There is some ( errors? ) warnings when scan > Lorenzo> the J-TAG chain. > You should be more concise: > - What Chip The chip is STM32F746NGH6 > - What board and other members in the JTAG chain. Custom board based on the discovery STM32 and no other JTAG chain. We have FLASH NOR SPI N25Q128A13EF840E by Numonyx and external SDRAM MT48LC4M32B2B5-6A IT:L > - What adapter JTAG compatible with AMONTEC JTAG key > - What configuration # This is an STM32F7 discovery board with a single STM32F756NGH6 chip. # http://www.st.com/web/catalog/tools/FM116/SC959/SS1532/LN1848/PF261641 # This is for using the onboard STLINK/V2-1 #source [find interface/stlink-v2-1.cfg] #transport select hla_swd #transport select jtag # increase working area to 256KB set WORKAREASIZE 0x40000 source [find target/stm32f7x.cfg] adapter_khz 600 and command line : openocd -f interface/ftdi/jtagkey.cfg -f /home/lorenzo/Progetti/EcceGui/demo/myboard_EK390.cfg -c "init; targets; reset halt; wait_halt; poll; flash write_image erase unlock Debug-EK390-0/FirmwareEK390_caffe.elf; flash erase_check 0; reset run; shutdown" Thank you for any help you will give to me Lorenzo -- *Lorenzo Corti* | Ricerca e Sviluppo *Eurek s.r.l. *Via Celletta 8/b | 40026 Imola (BO) - Italy | +39 *0542 609120* lor...@eu... <mailto:lor...@eu...> | www.eurek.it <http://www.eurek.it/> |
|
From: Lorenzo C. <lor...@eu...> - 2016-06-14 11:39:27
|
Il 01/06/2016 10:48, Uwe Bonnes ha scritto: >>>>>> "Lorenzo" == Lorenzo Corti <lor...@eu...> writes: > Lorenzo> Il 31/05/2016 17:14, Uwe Bonnes ha scritto: "Lorenzo" == > Lorenzo> Lorenzo Corti <lor...@eu...> writes: > > Lorenzo> ... Now the problem is flashing algo for the internal > Lorenzo> flash... > > Lorenzo> Did you try to "load" in gdb? > > Lorenzo> Here is the gdb log: > > Lorenzo> (gdb) load Debug-EK390-0/FirmwareEK390_caffe.elf Loading > Lorenzo> section .external_flash, size 0xad54b4 lma > Lorenzo> 0x90000000 > > 0x90000000 is no address of internal flash. So you need an extra loader for > external flash. I have not done that yet. tried to program the internal flash with command: openocd -d -f interface/ftdi/jtagkey.cfg -f /home/lorenzo/Progetti/EcceGui/demo/myboard_EK390.cfg -c "init; targets; reset halt; wait_halt; poll; flash write_image erase unlock Debug-EK390-0/LCDTest.elf; flash erase_check 0; reset run; shutdown" and the result failed: http://pastebin.com/Qkab3azU -- *Lorenzo Corti* | Ricerca e Sviluppo *Eurek s.r.l. *Via Celletta 8/b | 40026 Imola (BO) - Italy | +39 *0542 609120* lor...@eu... <mailto:lor...@eu...> | www.eurek.it <http://www.eurek.it/> |
|
From: Uwe B. <bo...@el...> - 2016-06-14 11:49:13
|
Hello, does you ELF file load with another programmer? It the linker script all right? Can you send me the Elf File in private mail? Or perhaps the outout from "arm-none-eabi-readelf -a ....elf" Bye -- Uwe Bonnes bo...@el... Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 1623569 ------- Fax. 06151 1623305 --------- |
|
From: Lorenzo C. <lor...@eu...> - 2016-06-14 14:00:41
|
Il 14/06/2016 13:48, Uwe Bonnes ha scritto:
> Hello,
>
> does you ELF file load with another programmer? It the linker script all
> right? Can you send me the Elf File in private mail? Or perhaps the outout
> from "arm-none-eabi-readelf -a ....elf"
>
> Bye
Hello,
I tried with STlink and the result is:
openocd -f interface/stlink-v2-1.cfg -f
/home/lorenzo/Progetti/EcceGui/demo/myboard_EK390.cfg -c "init; targets;
reset halt; wait_halt; poll; flash write_image erase unlock
Debug-EK390-0/LCDTest.elf; flash erase_check 0; reset run; shutdown"
Open On-Chip Debugger 0.10.0-dev-00321-gd4b7cbf (2016-05-31-10:18)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "hla_swd". To
override use 'transport select <transport>'.
Info : The selected transport took over low-level target control. The
results might differ compared to plain JTAG/SWD
adapter speed: 2000 kHz
adapter_nsrst_delay: 100
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
adapter speed: 600 kHz
Info : Unable to match requested speed 600 kHz, using 480 kHz
Info : Unable to match requested speed 600 kHz, using 480 kHz
Info : clock speed 480 kHz
Info : STLINK v2 JTAG v24 API v2 SWIM v11 VID 0x0483 PID 0x374B
Info : using stlink api v2
Info : Target voltage: 3.253755
Warn : Silicon bug: single stepping will enter pending exception handler!
Info : stm32f7x.cpu: hardware has 8 breakpoints, 4 watchpoints
TargetName Type Endian TapName State
-- ------------------ ---------- ------ ------------------ ------------
0* stm32f7x.cpu hla_target little stm32f7x.cpu running
stm32f7x.cpu: target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0xfffffffe msp: 0xfffffffc
background polling: on
TAP: stm32f7x.cpu (enabled)
stm32f7x.cpu: target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0xfffffffe msp: 0xfffffffc
auto erase enabled
auto unlock enabled
Info : device id = 0x10016449
Info : flash size = 1024kbytes
Error: timed out while waiting for target halted
stm32f7x.cpu: target state: halted
target halted due to debug-request, current mode: Handler HardFault
xPSR: 0x01000003 pc: 0xfffffffe msp: 0xffffffd8
Error: error waiting for target flash write algorithm
Error: error writing to flash at address 0x08000000 at offset 0x00000000
make: *** [progflash] Errore 1
Instead i have programmed it with success with DFU protocol dfu-util -d
0483:df11 -c 1 -i 0 -a 0 -s 0x08000000 -D LCDtest.bin
--
*Lorenzo Corti* | Ricerca e Sviluppo
*Eurek s.r.l. *Via Celletta 8/b | 40026 Imola (BO) - Italy | +39 *0542
609120*
lor...@eu... <mailto:lor...@eu...> | www.eurek.it
<http://www.eurek.it/>
|
|
From: Lorenzo C. <lor...@eu...> - 2016-06-14 14:54:21
|
Il 14/06/2016 16:16, Uwe Bonnes ha scritto: >>>>>> "Lorenzo" == Lorenzo Corti <lor...@eu...> writes: > Lorenzo> Hello, i send you the .elf file maked with > Lorenzo> arm-lancos-eabi-objcopy -O binary -R .external_flash -R > Lorenzo> .apptext Debug-EK390-0/LCDTest.elf Debug-EK390-0/ LCDTest.bin > > Hello, > > I will try to load to a F7(46) Discovery Board at home and will report. > > Bye With the following configuration: STM32 STLINK Utility under Windows8 , ST Link2.1 hardware, custom board EK390 : ok flash progammer. OpenOCD git Version Linux ubuntu 14.04, ST Link2.1 hardware, custom board EK390 : flash progammer doesn't work. OpenOCD git Version Linux ubuntu 14.04, JTAGKey hardware, custom board EK390: flash progammer doesn't work. OpenOCD git Version Linux ubuntu 14.04, ST Link2.1 hardware, STM32F7 discovery : ok flash progammer. We have see that openOCD has modified the option bytes. Any ideas? Thanks, Lorenzo -- *Lorenzo Corti* | Ricerca e Sviluppo *Eurek s.r.l. *Via Celletta 8/b | 40026 Imola (BO) - Italy | +39 *0542 609120* lor...@eu... <mailto:lor...@eu...> | www.eurek.it <http://www.eurek.it/> |
|
From: Lorenzo C. <lor...@eu...> - 2016-06-15 07:55:40
|
Il 14/06/2016 22:56, Uwe Bonnes ha scritto: > Running with GIT Head programming seems to work: >> arm-none-eabi-gdb LCDTest.elf > GNU gdb (GNU Tools for ARM Embedded Processors) 7.10.1.20160210-cvs > Copyright (C) 2015 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > <http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "--host=i686-linux-gnu --target=arm-none-eabi". > Type "show configuration" for configuration details. > For bug reporting instructions, please see: > <http://www.gnu.org/software/gdb/bugs/>. > Find the GDB manual and other documentation resources online at: > <http://www.gnu.org/software/gdb/documentation/>. > For help, type "help". > Type "apropos word" to search for commands related to "word"... > Reading symbols from LCDTest.elf...done. > (gdb) tar ext :3333 > Remote debugging using :3333 > Reset_Handler () > at > /home/lorenzo/Progetti/EcceGui/src/platform_FreeRTOS/stm32/stm32f7/startup_stm32f7xx.c:347 > 347 > /home/lorenzo/Progetti/EcceGui/src/platform_FreeRTOS/stm32/stm32f7/startup_stm32f7xx.c: > Datei oder Verzeichnis nicht gefunden. > (gdb) load > Loading section .text, size 0x2d5d4 lma 0x8000000 > Loading section .data, size 0x608 lma 0x802d5d4 > Start address 0x802d4c4, load size 187356 > Transfer rate: 35 KB/sec, 12490 bytes/write. > > >> git remote -v > origin git://git.code.sf.net/p/openocd/code (fetch) > origin git://git.code.sf.net/p/openocd/code (push) > review ssh://UB...@op...:29418/openocd.git (fetch) > review ssh://UB...@op...:29418/openocd.git (push) > > Cheers I would like to know how to fetch the head version you have from git, so i can check it out. Thank you. -- *Lorenzo Corti* | Ricerca e Sviluppo *Eurek s.r.l. *Via Celletta 8/b | 40026 Imola (BO) - Italy | +39 *0542 609120* lor...@eu... <mailto:lor...@eu...> | www.eurek.it <http://www.eurek.it/> |
|
From: Lorenzo C. <lor...@eu...> - 2016-06-15 08:15:20
|
Il 14/06/2016 22:56, Uwe Bonnes ha scritto: > Running with GIT Head programming seems to work: >> arm-none-eabi-gdb LCDTest.elf > GNU gdb (GNU Tools for ARM Embedded Processors) 7.10.1.20160210-cvs > Copyright (C) 2015 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > <http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "--host=i686-linux-gnu --target=arm-none-eabi". > Type "show configuration" for configuration details. > For bug reporting instructions, please see: > <http://www.gnu.org/software/gdb/bugs/>. > Find the GDB manual and other documentation resources online at: > <http://www.gnu.org/software/gdb/documentation/>. > For help, type "help". > Type "apropos word" to search for commands related to "word"... > Reading symbols from LCDTest.elf...done. > (gdb) tar ext :3333 > Remote debugging using :3333 > Reset_Handler () > at > /home/lorenzo/Progetti/EcceGui/src/platform_FreeRTOS/stm32/stm32f7/startup_stm32f7xx.c:347 > 347 > /home/lorenzo/Progetti/EcceGui/src/platform_FreeRTOS/stm32/stm32f7/startup_stm32f7xx.c: > Datei oder Verzeichnis nicht gefunden. > (gdb) load > Loading section .text, size 0x2d5d4 lma 0x8000000 > Loading section .data, size 0x608 lma 0x802d5d4 > Start address 0x802d4c4, load size 187356 > Transfer rate: 35 KB/sec, 12490 bytes/write. > > >> git remote -v > origin git://git.code.sf.net/p/openocd/code (fetch) > origin git://git.code.sf.net/p/openocd/code (push) > review ssh://UB...@op...:29418/openocd.git (fetch) > review ssh://UB...@op...:29418/openocd.git (push) > > Cheers Hello, I tried with the GDB debugger and seems to work. How is possible, instead, that the command write flash of openOCD doesn't work? -- *Lorenzo Corti* | Ricerca e Sviluppo *Eurek s.r.l. *Via Celletta 8/b | 40026 Imola (BO) - Italy | +39 *0542 609120* lor...@eu... <mailto:lor...@eu...> | www.eurek.it <http://www.eurek.it/> |
|
From: Andreas F. <and...@gm...> - 2016-06-15 08:26:58
|
On Wed, Jun 15, 2016 at 10:15 AM, Lorenzo Corti <lor...@eu...> wrote: > > > > Hello, > I tried with the GDB debugger and seems to work. > How is possible, instead, that the command write flash of openOCD doesn't > work? > > Hi, When GDB loads, a default hook calls "reset init" to get the target into a well defined state and prepare clocks for faster programming. If you flash "manually", you should make sure to have called "reset init" yourself. Then it should be equivalent. /Andreas |
|
From: Lorenzo C. <lor...@eu...> - 2016-06-15 09:08:01
|
Il 15/06/2016 10:26, Andreas Fritiofson ha scritto:
>
>
> On Wed, Jun 15, 2016 at 10:15 AM, Lorenzo Corti <lor...@eu...
> <mailto:lor...@eu...>> wrote:
>
>
>
>
> Hello,
> I tried with the GDB debugger and seems to work.
> How is possible, instead, that the command write flash of openOCD
> doesn't work?
>
>
> Hi,
>
> When GDB loads, a default hook calls "reset init" to get the target
> into a well defined state and prepare clocks for faster programming.
> If you flash "manually", you should make sure to have called "reset
> init" yourself. Then it should be equivalent.
>
> /Andreas
Hello,
i tried with the stm32f7discovery board with the following command and
unsuccess:
openocd -f board/stm32f7discovery.cfg -c "init; targets; reset init;
wait_halt; poll; flash write_image erase unlock
Debug-MB1191B-0/LCDTest.elf; flash erase_check 0; reset run; shutdown"
Open On-Chip Debugger 0.10.0-dev-00321-gd4b7cbf (2016-05-31-10:18)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : The selected transport took over low-level target control. The
results might differ compared to plain JTAG/SWD
adapter speed: 2000 kHz
adapter_nsrst_delay: 100
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : clock speed 1800 kHz
Info : STLINK v2 JTAG v24 API v2 SWIM v11 VID 0x0483 PID 0x374B
Info : using stlink api v2
Info : Target voltage: 3.219934
Warn : Silicon bug: single stepping will enter pending exception handler!
Info : stm32f7x.cpu: hardware has 8 breakpoints, 4 watchpoints
TargetName Type Endian TapName State
-- ------------------ ---------- ------ ------------------ ------------
0* stm32f7x.cpu hla_target little stm32f7x.cpu halted
stm32f7x.cpu: target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0xfffffffe msp: 0xfffffffc
background polling: on
TAP: stm32f7x.cpu (enabled)
stm32f7x.cpu: target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0xfffffffe msp: 0xfffffffc
auto erase enabled
auto unlock enabled
Info : device id = 0x10016449
Info : flash size = 1024kbytes
Error: timed out while waiting for target halted
stm32f7x.cpu: target state: halted
target halted due to debug-request, current mode: Handler HardFault
xPSR: 0x01000003 pc: 0xfffffffe msp: 0xffffffd8
Error: error waiting for target flash write algorithm
Error: error writing to flash at address 0x08000000 at offset 0x00000000
--
*Lorenzo Corti* | Ricerca e Sviluppo
*Eurek s.r.l. *Via Celletta 8/b | 40026 Imola (BO) - Italy | +39 *0542
609120*
lor...@eu... <mailto:lor...@eu...> | www.eurek.it
<http://www.eurek.it/>
|
|
From: Lorenzo C. <lor...@eu...> - 2016-06-15 09:20:15
|
Il 15/06/2016 10:26, Andreas Fritiofson ha scritto:
>
>
> On Wed, Jun 15, 2016 at 10:15 AM, Lorenzo Corti <lor...@eu...
> <mailto:lor...@eu...>> wrote:
>
>
>
>
> Hello,
> I tried with the GDB debugger and seems to work.
> How is possible, instead, that the command write flash of openOCD
> doesn't work?
>
>
> Hi,
>
> When GDB loads, a default hook calls "reset init" to get the target
> into a well defined state and prepare clocks for faster programming.
> If you flash "manually", you should make sure to have called "reset
> init" yourself. Then it should be equivalent.
>
> /Andreas
When we luanch openOCD server with this script:
# default ports
telnet_port 4444
gdb_port 3333
tcl_port 6666
init
reset init
doens't work and the the result is:
Open On-Chip Debugger 0.10.0-dev-00321-gd4b7cbf (2016-05-31-10:18)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Warn : Interface already configured, ignoring
Error: already specified hl_layout stlink
Info : The selected transport took over low-level target control. The
results might differ compared to plain JTAG/SWD
adapter speed: 2000 kHz
adapter_nsrst_delay: 100
srst_only separate srst_nogate srst_open_drain connect_deassert_srst
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : clock speed 1800 kHz
Info : STLINK v2 JTAG v24 API v2 SWIM v11 VID 0x0483 PID 0x374B
Info : using stlink api v2
Info : Target voltage: 3.219934
Warn : Silicon bug: single stepping will enter pending exception handler!
Info : stm32f7x.cpu: hardware has 8 breakpoints, 4 watchpoints
stm32f7x.cpu: target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0xfffffffe msp: 0xfffffffc
Info : accepting 'gdb' connection on tcp/3333
Info : device id = 0x10016449
Info : flash size = 1024kbytes
requesting target halt and executing a soft reset
Error: Target stm32f7x.cpu does not support soft_reset_halt
stm32f7x.cpu: target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0xfffffffe msp: 0xfffffffc
Error: timed out while waiting for target halted
stm32f7x.cpu: target state: halted
target halted due to debug-request, current mode: Handler HardFault
xPSR: 0x01000003 pc: 0xfffffffe msp: 0xffffffd8
Error: error waiting for target flash write algorithm
Error: error writing to flash at address 0x08000000 at offset 0x00000000
stm32f7x.cpu: target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0xfffffffe msp: 0xfffffffc
--
*Lorenzo Corti* | Ricerca e Sviluppo
*Eurek s.r.l. *Via Celletta 8/b | 40026 Imola (BO) - Italy | +39 *0542
609120*
lor...@eu... <mailto:lor...@eu...> | www.eurek.it
<http://www.eurek.it/>
|
|
From: Andreas F. <and...@gm...> - 2016-06-15 09:45:56
|
In the latter case, you use some weird custom scripts containing the old soft_reset_halt command. None of the stock cortex_m configs contain that command. Make sure you're not sourcing some old scripts. The first case seems to use the stock configs only, good. But it still fails. Are you saying GDB can load with the same setup but not from command line? Didn't you say you had some corrupted option bytes on the target that failed programming? Have you restored them? Or do they keep getting corrupt? Especially the HW IWDG option can/will interfere with the flashing algorithm. I suspect the "unlock" argument if the option bytes get corrupted by OpenOCD. That step is not performed as part of GDB load. Perhaps write (un-)protection is not supported for the F7, Uwe? By the way, for flashing from the command line, use the "program" script. E.g. openocd -f board/stm32f7discovery.cfg -c "program Debug-MB1191B-0/LCDTest.elf verify reset exit" /Andreas |
|
From: Lorenzo C. <lor...@eu...> - 2016-06-15 14:44:32
|
Il 15/06/2016 11:45, Andreas Fritiofson ha scritto: > In the latter case, you use some weird custom scripts containing the > old soft_reset_halt command. None of the stock cortex_m configs > contain that command. Make sure you're not sourcing some old scripts. > > The first case seems to use the stock configs only, good. But it still > fails. Are you saying GDB can load with the same setup but not from > command line? > > Didn't you say you had some corrupted option bytes on the target that > failed programming? Have you restored them? Or do they keep getting > corrupt? Especially the HW IWDG option can/will interfere with the > flashing algorithm. I suspect the "unlock" argument if the option > bytes get corrupted by OpenOCD. That step is not performed as part of > GDB load. Perhaps write (un-)protection is not supported for the F7, Uwe? > > By the way, for flashing from the command line, use the "program" > script. E.g. > > openocd -f board/stm32f7discovery.cfg -c > "program Debug-MB1191B-0/LCDTest.elf verify reset exit" > > /Andreas The problem for not correct programmer was in effect caused by option bytes. We tried to flash STM32F7 discovery board with ST LINK using OpenOCD with the script 'program' and it works with Linux and in Windows with the STLink Utilities. The problem remains with OUR Board (EK390) BUT only in Linux using OpenOCD and STLink hardware. Using Windows and STLink Utlities our board is correctly programmed, so we can for sure assert that the hardware is good enough. With 'PROGRAM': > openocd -f board/stm32f7discovery.cfg -c "program > Debug-EK390-0/LCDTest.elf verify reset exit" > Open On-Chip Debugger 0.10.0-dev-00321-gd4b7cbf (2016-05-31-10:18) > Licensed under GNU GPL v2 > For bug reports, read > http://openocd.org/doc/doxygen/bugs.html > Info : The selected transport took over low-level target control. The > results might differ compared to plain JTAG/SWD > adapter speed: 2000 kHz > adapter_nsrst_delay: 100 > srst_only separate srst_nogate srst_open_drain connect_deassert_srst > Info : Unable to match requested speed 2000 kHz, using 1800 kHz > Info : Unable to match requested speed 2000 kHz, using 1800 kHz > Info : clock speed 1800 kHz > Info : STLINK v2 JTAG v24 API v2 SWIM v11 VID 0x0483 PID 0x374B > Info : using stlink api v2 > Info : Target voltage: 3.258498 > Warn : Silicon bug: single stepping will enter pending exception handler! > Info : stm32f7x.cpu: hardware has 8 breakpoints, 4 watchpoints > Error: timed out while waiting for target halted > TARGET: stm32f7x.cpu - Not halted > in procedure 'program' > in procedure 'reset' called at file "embedded:startup.tcl", line 478 > in procedure 'ocd_bouncer' > > ** Unable to reset target ** > shutdown command invoked With 'WRITE FLASH' but without 'UNLOCK': > openocd -f interface/stlink-v2-1.cfg -f > /home/lorenzo/Progetti/EcceGui/demo/myboard_EK390.cfg -c "init; > targets; reset init; poll; flash write_image erase > Debug-EK390-0/LCDTest.elf; flash erase_check 0; reset run; shutdown" > Open On-Chip Debugger 0.10.0-dev-00321-gd4b7cbf (2016-05-31-10:18) > Licensed under GNU GPL v2 > For bug reports, read > http://openocd.org/doc/doxygen/bugs.html > Info : auto-selecting first available session transport "hla_swd". To > override use 'transport select <transport>'. > Info : The selected transport took over low-level target control. The > results might differ compared to plain JTAG/SWD > adapter speed: 2000 kHz > adapter_nsrst_delay: 100 > srst_only separate srst_nogate srst_open_drain connect_deassert_srst > adapter speed: 600 kHz > Info : Unable to match requested speed 600 kHz, using 480 kHz > Info : Unable to match requested speed 600 kHz, using 480 kHz > Info : clock speed 480 kHz > Info : STLINK v2 JTAG v24 API v2 SWIM v11 VID 0x0483 PID 0x374B > Info : using stlink api v2 > Info : Target voltage: 3.258498 > Warn : Silicon bug: single stepping will enter pending exception handler! > Info : stm32f7x.cpu: hardware has 8 breakpoints, 4 watchpoints > TargetName Type Endian TapName State > -- ------------------ ---------- ------ ------------------ ------------ > 0* stm32f7x.cpu hla_target little stm32f7x.cpu running > Error: timed out while waiting for target halted > TARGET: stm32f7x.cpu - Not halted > in procedure 'reset' > in procedure 'ocd_bouncer' Any hint? -- *Lorenzo Corti* | Ricerca e Sviluppo *Eurek s.r.l. *Via Celletta 8/b | 40026 Imola (BO) - Italy | +39 *0542 609120* lor...@eu... <mailto:lor...@eu...> | www.eurek.it <http://www.eurek.it/> |
|
From: Tomas V. <to...@us...> - 2016-06-15 18:07:59
|
On 15.06.2016 16:44, Lorenzo Corti wrote: > > > Il 15/06/2016 11:45, Andreas Fritiofson ha scritto: >> In the latter case, you use some weird custom scripts containing the >> old soft_reset_halt command. None of the stock cortex_m configs >> contain that command. Make sure you're not sourcing some old scripts. >> >> The first case seems to use the stock configs only, good. But it >> still fails. Are you saying GDB can load with the same setup but not >> from command line? >> >> Didn't you say you had some corrupted option bytes on the target that >> failed programming? Have you restored them? Or do they keep getting >> corrupt? Especially the HW IWDG option can/will interfere with the >> flashing algorithm. I suspect the "unlock" argument if the option >> bytes get corrupted by OpenOCD. That step is not performed as part of >> GDB load. Perhaps write (un-)protection is not supported for the F7, Uwe? >> >> By the way, for flashing from the command line, use the "program" >> script. E.g. >> >> openocd -f board/stm32f7discovery.cfg -c >> "program Debug-MB1191B-0/LCDTest.elf verify reset exit" >> >> /Andreas > > > The problem for not correct programmer was in effect caused by option > bytes. > We tried to flash STM32F7 discovery board with ST LINK using OpenOCD > with the script 'program' and it works with Linux and in Windows with > the STLink Utilities. > The problem remains with OUR Board (EK390) BUT only in Linux using > OpenOCD and STLink hardware. Using Windows and STLink Utlities our > board is correctly programmed, so we can for sure assert that the > hardware is good enough. > > With 'PROGRAM': > >> openocd -f board/stm32f7discovery.cfg -c "program >> Debug-EK390-0/LCDTest.elf verify reset exit" >> Open On-Chip Debugger 0.10.0-dev-00321-gd4b7cbf (2016-05-31-10:18) >> Licensed under GNU GPL v2 >> For bug reports, read >> http://openocd.org/doc/doxygen/bugs.html >> Info : The selected transport took over low-level target control. The >> results might differ compared to plain JTAG/SWD >> adapter speed: 2000 kHz >> adapter_nsrst_delay: 100 >> srst_only separate srst_nogate srst_open_drain connect_deassert_srst >> Info : Unable to match requested speed 2000 kHz, using 1800 kHz >> Info : Unable to match requested speed 2000 kHz, using 1800 kHz >> Info : clock speed 1800 kHz >> Info : STLINK v2 JTAG v24 API v2 SWIM v11 VID 0x0483 PID 0x374B >> Info : using stlink api v2 >> Info : Target voltage: 3.258498 >> Warn : Silicon bug: single stepping will enter pending exception handler! >> Info : stm32f7x.cpu: hardware has 8 breakpoints, 4 watchpoints >> Error: timed out while waiting for target halted >> TARGET: stm32f7x.cpu - Not halted >> in procedure 'program' >> in procedure 'reset' called at file "embedded:startup.tcl", line 478 >> in procedure 'ocd_bouncer' >> >> ** Unable to reset target ** >> shutdown command invoked > > With 'WRITE FLASH' but without 'UNLOCK': > >> openocd -f interface/stlink-v2-1.cfg -f >> /home/lorenzo/Progetti/EcceGui/demo/myboard_EK390.cfg -c "init; >> targets; reset init; poll; flash write_image erase >> Debug-EK390-0/LCDTest.elf; flash erase_check 0; reset run; shutdown" >> Open On-Chip Debugger 0.10.0-dev-00321-gd4b7cbf (2016-05-31-10:18) >> Licensed under GNU GPL v2 >> For bug reports, read >> http://openocd.org/doc/doxygen/bugs.html >> Info : auto-selecting first available session transport "hla_swd". To >> override use 'transport select <transport>'. >> Info : The selected transport took over low-level target control. The >> results might differ compared to plain JTAG/SWD >> adapter speed: 2000 kHz >> adapter_nsrst_delay: 100 >> srst_only separate srst_nogate srst_open_drain connect_deassert_srst >> adapter speed: 600 kHz >> Info : Unable to match requested speed 600 kHz, using 480 kHz >> Info : Unable to match requested speed 600 kHz, using 480 kHz >> Info : clock speed 480 kHz >> Info : STLINK v2 JTAG v24 API v2 SWIM v11 VID 0x0483 PID 0x374B >> Info : using stlink api v2 >> Info : Target voltage: 3.258498 >> Warn : Silicon bug: single stepping will enter pending exception handler! >> Info : stm32f7x.cpu: hardware has 8 breakpoints, 4 watchpoints >> TargetName Type Endian TapName State >> -- ------------------ ---------- ------ ------------------ ------------ >> 0* stm32f7x.cpu hla_target little stm32f7x.cpu running >> Error: timed out while waiting for target halted >> TARGET: stm32f7x.cpu - Not halted >> in procedure 'reset' >> in procedure 'ocd_bouncer' > > > Any hint? > > -- Check reset signal to your board. Looks like reset is not connected at all/stuck at high or a pulse is prolonged by a capacitor. You can try "reset_config none" after including target/stm32f7x.cfg or experiment with longer adapter_nsrst_delay. I noticed that in target/stm32f7x.cfg is command "reset_config srst_only". It should be in board config, or is it essential for F7? |
|
From: Claudio L. <cla...@eu...> - 2016-06-16 10:38:05
|
On 15/06/2016 11:45, Andreas Fritiofson wrote: > Didn't you say you had some corrupted option bytes on the target that > failed programming? Have you restored them? Or do they keep getting > corrupt? Especially the HW IWDG option can/will interfere with the > flashing algorithm. I suspect the "unlock" argument if the option > bytes get corrupted by OpenOCD. That step is not performed as part of > GDB load. Perhaps write (un-)protection is not supported for the F7, Uwe? Yes, I can confirm that on stm32f746 both 'write_image flash erase unlock' and 'flash protect 0 0 last off' corrupt the option bytes (IWDG_STOP IWDG_STDBY and WWDG_SW) and further programming doesn't work anymore. > > By the way, for flashing from the command line, use the "program" > script. E.g. > > openocd -f board/stm32f7discovery.cfg -c > "program Debug-MB1191B-0/LCDTest.elf verify reset exit" > > /Andreas > Interesting, where I can find the program script? Cheers, Claudio Lanconelli |
|
From: Uwe B. <bo...@el...> - 2016-06-16 11:07:18
|
>>>>> "Claudio" == Claudio Lanconelli <cla...@eu...> writes:
Claudio> On 15/06/2016 11:45, Andreas Fritiofson wrote: Didn't you say
Claudio> you had some corrupted option bytes on the target that failed
Claudio> programming? Have you restored them? Or do they keep getting
Claudio> corrupt? Especially the HW IWDG option can/will interfere with
Claudio> the flashing algorithm. I suspect the "unlock" argument if the
Claudio> option bytes get corrupted by OpenOCD. That step is not
Claudio> performed as part of GDB load. Perhaps write (un-)protection is
Claudio> not supported for the F7, Uwe?
Claudio> Yes, I can confirm that on stm32f746 both 'write_image flash
Claudio> erase unlock' and 'flash protect 0 0 last off' corrupt the
Claudio> option bytes (IWDG_STOP IWDG_STDBY and WWDG_SW) and further
Claudio> programming doesn't work anymore.
So some contribution to fix that issue is welcome!
Claudio> By the way, for flashing from the command line, use the
Claudio> "program" script. E.g.
Claudio> openocd -f board/stm32f7discovery.cfg -c
Claudio> "program Debug-MB1191B-0/LCDTest.elf verify reset exit"
Claudio> /Andreas
Claudio> Interesting, where I can find the program script?
"-c " denotes an internal command, no script.
Bye
--
Uwe Bonnes bo...@el...
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 1623569 ------- Fax. 06151 1623305 ---------
|
|
From: Claudio L. <cla...@eu...> - 2016-06-17 11:14:54
|
On 16/06/2016 13:06, Uwe Bonnes wrote: > Claudio> Yes, I can confirm that on stm32f746 both 'write_image flash > Claudio> erase unlock' and 'flash protect 0 0 last off' corrupt the > Claudio> option bytes (IWDG_STOP IWDG_STDBY and WWDG_SW) and further > Claudio> programming doesn't work anymore. > > So some contribution to fix that issue is welcome! > Hi, I found this patch http://openocd.zylin.com/#/c/3123/2, but it doesn't solve the problem completely, so I fixed the file src/flash/nor/stm32f2x.c and now it works as expected. However I don't know how to use git & gerrit & co, so can you help me to make the patch and send it? Claudio |
|
From: Lorenzo C. <lor...@eu...> - 2016-06-16 13:24:46
|
Il 15/06/2016 19:49, Tomas Vanek ha scritto: > >> >> -- > Check reset signal to your board. Looks like reset is not connected at > all/stuck at high or a pulse is prolonged by a capacitor. > You can try "reset_config none" after including target/stm32f7x.cfg > or experiment with longer adapter_nsrst_delay. > > I noticed that in target/stm32f7x.cfg is command "reset_config srst_only". > It should be in board config, or is it essential for F7? > Yes, you were right. Using "reset_config none" does the trick. It works with STLink Hardware even in Linux with our custom board. Now, the biggest issue is: *how the hell is the jtag programming procedure is not working? WTF*? > openocd -f interface/ftdi/jtagkey.cfg -f > /home/lorenzo/Progetti/EcceGui/demo/myboard_EK390.cfg -c "program > Debug-EK390-0/LCDTest.elf verify reset exit" > Open On-Chip Debugger 0.10.0-dev-00321-gd4b7cbf (2016-05-31-10:18) > Licensed under GNU GPL v2 > For bug reports, read > http://openocd.org/doc/doxygen/bugs.html > adapter speed: 2000 kHz > adapter_nsrst_delay: 100 > jtag_ntrst_delay: 100 > srst_only separate srst_nogate srst_open_drain connect_deassert_srst > cortex_m reset_config sysresetreq > trst_and_srst separate srst_nogate trst_push_pull srst_open_drain > connect_deassert_srst > Info : clock speed 2000 kHz > Info : JTAG tap: stm32f7x.cpu tap/device found: 0x5ba00477 (mfg: 0x23b > (ARM Ltd.), part: 0xba00, ver: 0x5) > Info : JTAG tap: stm32f7x.bs tap/device found: 0x06449041 (mfg: 0x020 > (STMicroelectronics), part: 0x6449, ver: 0x0) > Warn : Silicon bug: single stepping will enter pending exception handler! > Info : stm32f7x.cpu: hardware has 8 breakpoints, 4 watchpoints > Info : JTAG tap: stm32f7x.cpu tap/device found: 0x5ba00477 (mfg: 0x23b > (ARM Ltd.), part: 0xba00, ver: 0x5) > Info : JTAG tap: stm32f7x.bs tap/device found: 0x06449041 (mfg: 0x020 > (STMicroelectronics), part: 0x6449, ver: 0x0) > stm32f7x.cpu: target state: halted > target halted due to debug-request, current mode: Thread > xPSR: 0x01000000 pc: 0x0802d4c4 msp: 0x20050000 > ** Programming Started ** > auto erase enabled > Info : device id = 0x10016449 > Info : flash size = 1024kbytes > Info : DAP transaction stalled (WAIT) - slowing down > Info : DAP transaction stalled (WAIT) - slowing down > Error: timeout waiting for algorithm, a target reset is recommended > Error: error executing stm32x flash write algorithm > Error: flash write failed = 00000040 > Error: error writing to flash at address 0x08000000 at offset 0x00000000 > ** Programming Failed ** > shutdown command invoked here is the full debug log: http://pastebin.com/Z31NdcrN Here is the configuration for jtag for our board: > transport select jtag > > set WORKAREASIZE 0x40000 > source [find target/stm32f7x.cfg] > > reset_config trst_and_srst srst_nogate Any help?? TIA -- *Lorenzo Corti* | Ricerca e Sviluppo *Eurek s.r.l. *Via Celletta 8/b | 40026 Imola (BO) - Italy | +39 *0542 609120* lor...@eu... <mailto:lor...@eu...> | www.eurek.it <http://www.eurek.it/> |
|
From: Andreas F. <and...@gm...> - 2016-06-16 13:42:24
|
On Thu, Jun 16, 2016 at 3:24 PM, Lorenzo Corti <lor...@eu...> wrote: > > > Now, the biggest issue is: *how the hell is the jtag programming procedure > is not working? WTF*? > The corrupted option bytes? Fix them and then avoid the write-protect features. Or better, fix the write-protection to not destroy the option bytes. /Andreas |
|
From: gianluca <gia...@eu...> - 2016-06-16 14:07:22
|
On 06/16/2016 03:42 PM, Andreas Fritiofson wrote: > > > On Thu, Jun 16, 2016 at 3:24 PM, Lorenzo Corti <lor...@eu... > <mailto:lor...@eu...>> wrote: > > > > Now, the biggest issue is: *how the hell is the jtag programming > procedure is not working? WTF*? > > > The corrupted option bytes? Fix them and then avoid the write-protect > features. Or better, fix the write-protection to not destroy the option > bytes. > But I am using the same command as in stlink, i.e.: -c "program ...." so I suppose that writing flash using stlink or using jtag has different approaches or they do not call the same functions in sequence. Is there a way, a command, just to avoid the changing of the option bytes??? Maybe the jtag function sequence with the 'program' command due differently if using stlink and the option byte there are not corrupted at all. Thank you, -- Eurek s.r.l. | Electronic Engineering | http://www.eurek.it via Celletta 8/B, 40026 Imola, Italy | Phone: +39-(0)542-609120 p.iva 00690621206 - c.f. 04020030377 | Fax: +39-(0)542-609212 |
Thanks for helping keep SourceForge clean.
X