Skip to content
This repository has been archived by the owner on Sep 28, 2019. It is now read-only.

can detect board with st-util, but can't connect board with openocd #7

Closed
mintisan opened this issue Mar 5, 2016 · 1 comment
Closed

can detect board with st-util, but can't connect board with openocd #7

mintisan opened this issue Mar 5, 2016 · 1 comment
Labels
duplicate question

Comments

@mintisan
Copy link

mintisan commented Mar 5, 2016

As title says, I can detect my STM32F401-Nucleo board with st-utils from stlink, but can't connect board with openocd.
I don't know whether I need to config others or not.

1.Setup stlink v2, and I can detect my STM32F401-Nucleo as below:

➜  bin st-util
2016-03-05T22:20:04 INFO src/stlink-common.c: Loading device parameters....
2016-03-05T22:20:04 INFO src/stlink-common.c: Device connected is: F4 device (Dynamic Efficency), id 0x10006433
2016-03-05T22:20:04 INFO src/stlink-common.c: SRAM size: 0x18000 bytes (96 KiB), Flash: 0x80000 bytes (512 KiB) in pages of 16384 bytes
2016-03-05T22:20:04 INFO gdbserver/gdb-server.c: Chip ID is 00000433, Core ID is  2ba01477.
2016-03-05T22:20:04 INFO gdbserver/gdb-server.c: Target voltage is 3265 mV.
2016-03-05T22:20:04 INFO gdbserver/gdb-server.c: Listening at *:4242...

2.but I can't connect my board with openocd, error is below:

➜  bin pwd
/Applications/GNU ARM Eclipse/OpenOCD/0.10.0-201601101000-dev/bin
➜  bin ./openocd -f board/stm32f4discovery.cfg
GNU ARM Eclipse 64-bits Open On-Chip Debugger 0.10.0-dev-00287-g85cec24 (2016-01-10-12:03)
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
none separate
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
Error: open failed
in procedure 'init'
in procedure 'ocd_bouncer'

➜  bin

my Dev-environment is:

Board : STM32F401RE Nucleo
OS X EI Caption : 10.11 (15A284)
iTerm2 : Build 2.1.4
OpenOCD : 0.10.0-201601101000-dev
ST-Link V2 : https://github.com/texane/stlink
@ilg-ul
Copy link
Contributor

ilg-ul commented Mar 5, 2016

duplicate: https://www.element14.com/community/message/176244/l/can-detect-board-with-st-util-but-cant-connect-board-with-openocd#176244

@ilg-ul ilg-ul closed this as completed Oct 29, 2016
ilg-ul pushed a commit that referenced this issue Jun 5, 2017
@timsifive
Merge pull request #7 from sifive/temp_verify_blank_check
e31dd22 
riscv: implement skeletons for Memory Blank Check and CRC.
ilg-ul pushed a commit that referenced this issue May 12, 2018
@tom-van
helper/types: cast to uint32_t,uint16_t to avoid UB by shifting int t…
d4ef54c 
…oo far

Without this, we have some types promoted to `int` when they need to be
`unsigned int`.

Here's some ubsan output hitting this:

Unfortunately, what happens is that things get promoted to `int`, but
need to be `unsigned int`. Here's the ubsan output:

src/helper/types.h:126:65: runtime error: left shift of 255 by 24 places cannot be represented in type 'int'
    #0 0x55978a612060 in le_to_h_u32 src/helper/types.h:126
    #1 0x55978a61ff9e in stlink_usb_read_reg src/jtag/drivers/stlink_usb.c:1539
    #2 0x55978a8cfd45 in adapter_load_core_reg_u32 src/target/hla_target.c:67
    #3 0x55978a9f48e3 in armv7m_read_core_reg src/target/armv7m.c:236
    #4 0x55978a8d24fc in adapter_load_context src/target/hla_target.c:372
    #5 0x55978a8d261b in adapter_debug_entry src/target/hla_target.c:396
    #6 0x55978a8d3123 in adapter_poll src/target/hla_target.c:457
    #7 0x55978a528357 in target_poll src/target/target.c:535
    #8 0x55978a539fd4 in target_wait_state src/target/target.c:2914
    #9 0x55978a556e20 in jim_target_wait_state src/target/target.c:5256
    #10 0x55978a5cca62 in command_unknown src/helper/command.c:1030
    #11 0x55978aaed894 in JimInvokeCommand /home/cody/d/openocd-code/jimtcl/jim.c:10364

Change-Id: I24f6abfd26b6980100657397d69c84f2b80a005a
Signed-off-by: Cody P Schafer <[email protected]>
Reviewed-on: http://openocd.zylin.com/4455
Reviewed-by: Tomas Vanek <[email protected]>
Tested-by: jenkins
Reviewed-by: Christopher Head <[email protected]>
@faisal-shah faisal-shah mentioned this issue Jun 14, 2018
Closed
ilg-ul pushed a commit that referenced this issue Apr 8, 2019
@borneoa @thinkfat
arm_opcode: fix encoding of ARMv5 breakpoint instruction
45b4998 
The encoding of BKPT instruction is 0xE12###7#, where the four '#'
characters should be replaced by the 16 bits immediate value.
The macro uses an incorrect shift amount, thus the immediate value
is not properly coded and bits 20~23 of the opcode could get
corrupted.

Fixed by using the proper shift amount.

Change-Id: I32db8224ab57aad6d3b002f92f9f259056593675
Signed-off-by: Antonio Borneo <[email protected]>
Reviewed-on: http://openocd.zylin.com/4854
Tested-by: jenkins
Reviewed-by: Matthias Welwarsky <[email protected]>
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
duplicate question
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@ilg-ul @mintisan