openocd-user — User support list for OpenOCD

Re: [OpenOCD-user] Problem when connecting to am2431 via open ocd with gdb and xds110

[Dominic R. <Dom...@gm...>]

Hi Martin,

Am 29/05/2024 um 12:01 schrieb Salko, MARTIN:
> Dear openocd users/developers.
>
> I have an issue with connecting to our product using the xds110 debuger,
> and openocd with gbd.
> I have openocd built using mingw-w64, from gitlab repository with
> following commit:
>
> 2c8376b - target/xtensa: avoid IHI for writes to non-executable memory
> (this is because support for ti am243x was added recently)
>
> I’m trying to connect to a running cpu, then reset it and run it again,
> I’d like to essentially do a step by step trace.

I'm not sure what you're trying to achieve is possible. Not due to
OpenOCD, but due to the way the AM24x works.

For all I know you can't debug these things from reset. There's a ROM
that is executing before you get a chance to take control. Typically
that ROM will load the bootloader, which then loads the application.

The ROM only accepts an image in x509 format that contains some
meta-data and is used for signature verification (in case of a fused
HS-SE device).

When working on bootloader stuff I'd put a while loop early in my code
and simply attach the debugger, then step out of the loop.

When working with application stuff you can put a "null" bootloader in
non-volatile memory that just sets up memory and the cores. You then
attach the debugger, load your application straight to RAM, and the
debug from there.

Maybe you could share a bit more about what problem you're trying to
solve, then I might be able to give you some hints on how to approach that.


Apart from that it'd be interesting how good "reset halt" is expected to
work these days with complex SoCs like the AM24x. My expectation is
"not", and what you're seeing then is just follow-up errors.


> This is an error I’m getting from open ocd, when gdb connects to the
> first core:
> oocd ('err', 'Error: JTAG-DP STICKY ERROR\r\n')
>
> oocd ('err', 'Error: Failed to read memory at 0xe000ed00\r\n')
>
> oocd ('err', 'Error executing event gdb-attach on target
> am243.cpu.sysctrl:\r\n')
>

Best Regards,

Dominic

[OpenOCD-user] Problem when connecting to am2431 via open ocd with gdb and xds110

[Salko, M. <mar...@si...>]

Dear openocd users/developers.

I have an issue with connecting to our product using the xds110 debuger, and openocd with gbd.
I have openocd built using mingw-w64, from gitlab repository with following commit:
2c8376b - target/xtensa: avoid IHI for writes to non-executable memory
(this is because support for ti am243x was added recently)

I'm trying to connect to a running cpu, then reset it and run it again, I'd like to essentially do a step by step trace.

This is an error I'm getting from open ocd, when gdb connects to the first core:
oocd ('err', 'Error: JTAG-DP STICKY ERROR\r\n')
oocd ('err', 'Error: Failed to read memory at 0xe000ed00\r\n')
oocd ('err', 'Error executing event gdb-attach on target am243.cpu.sysctrl:\r\n')

gdb connects using command: "target extended-remote localhost:3333"

>From the schematic we use 5 pin jtag with emu0/1 pins pulled up high, so I think design wise this is fine (debugging tools provided)

This is my board.cfg:

source [find interface/xds110.cfg]
transport select jtag
reset_config srst_only srst_push_pull
adapter srst delay 20
set SOC am243

source [find target/ti_k3.cfg]

adapter speed 250

gdb_port 3333
bindto 0.0.0.0

init
reset halt
wait_halt
sleep 100
poll

am243.cpu.main0_r5.0 arp_examine



>From reading the documentation on arms side, sticky DP is an abort condition? As far as CoreSight is concerned.
And there is a register to clear it, so maybe that is what I have to do, However I have no experience in  working directly with jtag or DP registers.
Any suggestions/help would be highly appreciated.

With best regards,

Martin.

Re: [OpenOCD-user] Exporting SVF File from OpenOCD

[Abdullah Y. <abd...@yo...>]

Hi Paul,

Thank you for your support.

Regards,

Abdullah YILDIZ
Design and Verification Team Member at YONGATEK Microelectronics


From: Paul Fertser <fer...@gm...>
Date: Tuesday, 30 April 2024 at 17:26
To: Abdullah YILDIZ <abd...@yo...>
Cc: ope...@li... <ope...@li...>
Subject: Re: [OpenOCD-user] Exporting SVF File from OpenOCD
Hi,

On Thu, Apr 25, 2024 at 12:39:49PM +0000, Abdullah YILDIZ wrote:
> I need to export all JTAG transactions to a file in SVF (i.e., Serial Vector
> Format) when I run a particular OpenOCD script.
>
> Is there any method to do this in OpenOCD?

Not really, no. You could probably just grab -d4 log and extract all
actions from it and convert to SVF with a simple script but you'll
have to ignore the returned data.

--
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fer...@gm...
Important Notice:

This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager immediately. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete all copies of this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. YONGATEK does not represent, warrant and/or guarantee that the integrity of this communication has been maintained, nor that it is free of any error, virus, interception or interference.

Re: [OpenOCD-user] Warn : ignoring character 0x47

[José G. de C. R. <jos...@pr...>]

On Sunday, May 5th, 2024 at 18:57, Ubaldo Tiberi <uba...@gm...> wrote: 

> If I run openocd on terminal with the right board/selection and I connect to it through with arm-none-eabi-gdb -ex "target extended-remote localhost:3333” everything works fine and I can happily debug my code.

What version of openocd are you using?

> However, if I run openocd on a terminal and I try to call gdb through some other tool (I am running Vimspector on Vim, but that apparently the same issue happens with VSCode as well, see below), I get a lot of warnings displayed on the openocd console like the following:
> Warn : ignoring character 0x47

A few coworkers of mine use gdb + VSCode + cortex-m extension (but they are on Windows) and I don't remember any of them
complaining about this. Once you tell me the version, I could check with them and try to reproduce it.

> I googled a bit and I found some people encountering the same issues although on different platforms. Here are some examples:
> 
> https://github.com/raspberrypi/openocd/issues/14
> https://esp32.com/viewtopic.php?t=26968
> https://www.esp32.com/viewtopic.php?t=16883

Just to make sure, both espressif and raspberry seem to use their own forks and I don't know how up to date it is.

Re: [OpenOCD-user] Warn : ignoring character 0x47

[Tommy M. <tom...@ho...>]

You probably need to capture and post the openocd -d3 verbose and GDB remote serial protocol logs for the working and non-working cases to aid with investigation/analysis.

[OpenOCD-user] Warn : ignoring character 0x47

[Ubaldo T. <uba...@gm...>]

Hi!

If I run openocd on terminal with the right board/selection and I connect to it through with arm-none-eabi-gdb -ex "target extended-remote localhost:3333” everything works fine and I can happily debug my code.

However, if I run openocd on a terminal and I try to call gdb through some other tool  (I am running  Vimspector on Vim, but that apparently the same issue happens with VSCode as well, see below), I get a lot of warnings displayed on the openocd console like the following:

Warn : ignoring character 0x47

and obviously nothing is working. 

I googled a bit and I found some people encountering the same issues although on different platforms. Here are some examples:

https://github.com/raspberrypi/openocd/issues/14
https://esp32.com/viewtopic.php?t=26968
https://www.esp32.com/viewtopic.php?t=16883

Does anybody know why that happens and how to solve it?

Best,
/Ubaldo

Re: [OpenOCD-user] Exporting SVF File from OpenOCD

[Paul F. <fer...@gm...>]

Hi,

On Thu, Apr 25, 2024 at 12:39:49PM +0000, Abdullah YILDIZ wrote:
> I need to export all JTAG transactions to a file in SVF (i.e., Serial Vector
> Format) when I run a particular OpenOCD script.
> 
> Is there any method to do this in OpenOCD?

Not really, no. You could probably just grab -d4 log and extract all
actions from it and convert to SVF with a simple script but you'll
have to ignore the returned data.

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fer...@gm...

Re: [OpenOCD-user] Anyone using STM32U5 with OpenOCD?

[Rob M. <Rob...@u-...>]

In case anyone was following my posts about OpenOCD and STM32U5, the problem turns out to be nothing to do with OpenOCD; I can make it happen with the STM32Cube Programmer also.

We set the SWD rate in our target code, always have done for STM32F4, but it seems that the same code with the STM32U5 on the NUCLEO-U575ZI-Q board causes the board to no longer connect to a debugger after it has been power-cycled; provided you don't power-cycle the board you can connect and disconnect to your hearts content, but after a power-cycle the STM32U5 needs to be recovered manually (connect its BOOT0 pin to VDD to make it boot from ROM, connect to it with the debugger under reset and erase all flash, then connect the BOOT0 pin back to GND again so that you can boot from flash) before it will connect to a debugger normally again.  Even if we set the SWD rate to the same as what we understand the default to be, 2MHz, the problem remains.

We have asked ST if the SWD rate-setting code needs to be different for STM32U5 or if this is some form of fundamental limitation of the debug arrangement on the NUCLEO-U575ZI-Q board.

Rob
-----Original Message-----
From: Paul Fertser <fer...@gm...>
Sent: Sunday, April 28, 2024 8:56 AM
To: wieniawski <wie...@ou...>
Cc: ope...@li...
Subject: Re: [OpenOCD-user] OpenOCD using FT232H board

**** This is an EXTERNAL email. It was sent from outside of u-blox. ****

Hi,

On Sun, Apr 28, 2024 at 11:20:59AM +0800, wieniawski wrote:
> I am trying to using OpenOCD using a FT232H board.

If you want to use it for SWD you either need an additional adapter (which would drive the output buffer depending on some additional
signal) or to use the "resistor hack" (or if you're sure your FT232H doesn't have any buffering that can be direct connection without a resistor even). You also need to source the additional config for the SWD adapter or the resistor hack.

There's no need to define TDO or TDI or SWDIO, those signals have fixed location on FTDI hardware and can't be changed.

--
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fer...@gm...


_______________________________________________
OpenOCD-user mailing list
Ope...@li...
https://lists.sourceforge.net/lists/listinfo/openocd-user

Re: [OpenOCD-user] OpenOCD using FT232H board

[Paul F. <fer...@gm...>]

Hi,

On Sun, Apr 28, 2024 at 11:20:59AM +0800, wieniawski wrote:
> I am trying to using OpenOCD using a FT232H board.

If you want to use it for SWD you either need an additional adapter
(which would drive the output buffer depending on some additional
signal) or to use the "resistor hack" (or if you're sure your FT232H
doesn't have any buffering that can be direct connection without a
resistor even). You also need to source the additional config for the
SWD adapter or the resistor hack.

There's no need to define TDO or TDI or SWDIO, those signals have
fixed location on FTDI hardware and can't be changed.

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fer...@gm...

[OpenOCD-user] OpenOCD using FT232H board

[wieniawski <wie...@ou...>]

<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<style>
    font{
        line-height: 1.6;
    }
    ul,ol{
        padding-left: 20px;
        list-style-position: inside;
    }
</style>
<div style="font-family:微软雅黑,Verdana,&quot;Microsoft Yahei&quot;,SimSun,sans-serif;font-size:14px; line-height:1.6;">
    <div>
    <div>
        <span>hi,
        </span>
    </div><div><span><br></span></div><div><span>I am trying to using OpenOCD using a FT232H board. (BTW, I am successfully using JLINK as the hardware&nbsp;adapter&nbsp;to connect to target STM32F407 board, so my software env and target board is OK).</span></div><div><span><br></span></div><div><span>and my command is</span></div><div><span>```bash</span></div><div><span>openocd -s d:/un-setup/OpenOCD/share/openocd/scripts/ -f interface/ftdi
</span><span style="line-height: 1.6;">/ft232h-module-swd.cfg -f target/stm32f4x.cfg</span></div><div><span>```</span></div><div><span><br></span></div><div><span>However, it turns out an error:</span></div><div><span>Error: Error connecting DP: cannot read IDR.</span></div><div><span><br></span></div><div><span>I guess that is due to an bus connection error between my FT232H board and target STM32F407 board.</span></div><div><span><br></span></div><div><span>I noticed that there are several lines in swd.cfg file:</span></div><div><span># Adafruit      FT232H    JTAG       SWD
</span></div><div><span># Name  Pin     Name      Func       Func
</span></div><div><span>#  D0   J1-3    ADBUS0    TCK        SWDCLK
</span></div><div><span>#  D1   J1-4    ADBUS1    TDO/DI     SWDIO
</span></div><div><span>#  D2   J1-5    ADBUS2    TDI/DO     SWDIO</span></div><div><span><br></span></div><div><span>Where, there are to SWDIO pin defined. And I tried both of these two pins connected to target MCU, same error happens.</span></div><div><span><br></span></div><div><span>Then I realized that SWDIO is a bi-direction pin. So I tried to uncomment there 2 lines in swd.cfg file</span></div><div><span>#ftdi layout_signal TDO -data 0x0002 -oe 0x0002
</span></div><div><span>#ftdi layout_signal TDI -data 0x0004</span></div><div><span><br></span></div><div><span>However, it came out same error again.</span></div><div><span><br></span></div><div><span>So I am guessing:</span></div><div><span><br></span></div><div><span>Do I need to short FT232H AD1 and AD2 together?</span></div><div>Or is there any extra short circuit like using TDO as the output enable signal to TDI?</div><div><br></div><div>Thx,</div><div><br></div><div><br></div>
    <div>
        <span>
            <br>
        </span>
    </div>
    <div id="ntes-pcmac-signature" style="font-family:'微软雅黑'">
        
        <div style="font-size:14px; padding: 0;  margin:0;">

        </div>
    </div>
</div><!--😀-->
</div>
</body>
</html>

[OpenOCD-user] Exporting SVF File from OpenOCD

[Abdullah Y. <abd...@yo...>]

Dear all,

I need to export all JTAG transactions to a file in SVF (i.e., Serial Vector Format) when I run a particular OpenOCD script.

Is there any method to do this in OpenOCD?

Regards,

Abdullah YILDIZ
Design and Verification Team Member at YONGATEK Microelectronics

Important Notice:

This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager immediately. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete all copies of this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. YONGATEK does not represent, warrant and/or guarantee that the integrity of this communication has been maintained, nor that it is free of any error, virus, interception or interference.

Re: [OpenOCD-user] Anyone using STM32U5 with OpenOCD?

[Elias P. <eli...@bs...>]

Hi,
I have a design with a custom RISC-V CPU in a Xilinx Alveo u280.


When using OpenOCD I can only see the FPGA device and not the JTAG 
device inside the RISC-V CPU:
These are the different commands I have used and the error I am getting 
is always the same.

Commands:
./src/openocd -c "debug_level 4" -c "adapter driver ftdi" -c "ftdi 
vid_pid 0x0403 0x6011" -c "transport select jtag" -c "ftdi layout_init 
0x0008 0x000b" -c "ftdi layout_signal nSRST -data 0x0020 -oe 0x0020" -c 
"jtag newtap auto0 tap -irlen 2 -expected-id 0x14b7d093" -c "jtag newtap 
op cpu -irlen 18 -expected-id 0xb1aaa07d"

./src/openocd -c "debug_level 4" -c "adapter driver ftdi" -c "ftdi 
vid_pid 0x0403 0x6011" -c "transport select jtag" -c "ftdi layout_init 
0x0008 0x000b" -c "ftdi layout_signal nSRST -data 0x0020 -oe 0x0020" -c 
"jtag newtap auto0 unknown0 -irlen 2 -expected-id 0x14b7d093" -c "jtag 
newtap op unknown1 -irlen 18 -expected-id 0xb1aaa07d"

./src/openocd -c "debug_level 4" -c "adapter driver ftdi" -c "ftdi 
vid_pid 0x0403 0x6011" -c "transport select jtag" -c "ftdi layout_init 
0x0008 0x000b" -c "ftdi layout_signal nSRST -data 0x0020 -oe 0x0020" -c 
"jtag newtap auto0 bs -irlen 2 -expected-id 0x14b7d093" -c "jtag newtap 
op bs -irlen 18 -expected-id 0xb1aaa07d"

Error:
ebug: 157 22 core.c:960 default_interface_jtag_execute_queue(): JTAG DR 
SCAN to DRPAUSE
Debug: 158 22 core.c:967 default_interface_jtag_execute_queue(): 96b 
out: ffffffffffffffffffffffff
Debug: 159 22 core.c:972 default_interface_jtag_execute_queue(): 96b  
in: ffffffffffffffff14b7d093
Debug: 160 22 core.c:978 default_interface_jtag_execute_queue(): JTAG 
TLR RESET to RESET
Info : 161 22 core.c:1133 jtag_examine_chain_display(): JTAG tap: 
auto0.tap tap/device found: 0x14b7d093 (mfg: 0x049 (Xilinx), part: 
0x4b7d, ver: 0x1)
Debug: 162 22 jep106.c:22 jep106_table_manufacturer(): BUG: Caller 
passed out-of-range JEP106 ID!
Info : 163 22 core.c:1133 jtag_examine_chain_display(): JTAG tap: 
op.unknown0 tap/device found: 0xffffffff (mfg: 0x7ff (<invalid>), part: 
0xffff, ver: 0xf)
Debug: 164 22 jep106.c:22 jep106_table_manufacturer(): BUG: Caller 
passed out-of-range JEP106 ID!
Warn : 165 22 core.c:1133 jtag_examine_chain_display(): JTAG tap: 
op.unknown0       UNEXPECTED: 0xffffffff (mfg: 0x7ff (<invalid>), part: 
0xffff, ver: 0xf)
Error: 166 22 core.c:1133 jtag_examine_chain_display(): JTAG tap: 
op.unknown0  expected 1 of 1: 0x01aaa07d (mfg: 0x03e (Oracle 
Corporation), part: 0x1aaa, ver: 0x0)

Nevetherlles, with the AMD/Xilinx tool XSCT I can recognize the whole 
JTAG chain:
xsct% connect
tcfchan#0
xsct%
targets
   1  xcu280_u55c
      2  BSCAN JTAG
      3  00000000
   4  b1aaa07d

I don´t know what else to try, any help will be appreciated.

Best,

Elias

-- 
===================================================================
Elias A. Perdomo Hourné             | E-mail: eli...@bs...
Research Engineer                   |
Barcelona Supercomputing Center     | URL: http://www.bsc.es
Plaça Eusebi Güell, 1-3             |
08034 Barcelona, Spain              | Phone:  +34 93 4117373
===================================================================

cid:par...@bs...

WARNING / LEGAL TEXT: This message is intended only for the use of the 
individual or entity to which it is addressed and may contain 
information which is privileged, confidential, proprietary, or exempt 
from disclosure under applicable law. If you are not the intended 
recipient or the person responsible for delivering the message to the 
intended recipient, you are strictly prohibited from disclosing, 
distributing, copying, or in any way using this message. If you have 
received this communication in error, please notify the sender and 
destroy and delete any copies you may have received.

http://www.bsc.es/disclaimer

Re: [OpenOCD-user] Anyone using STM32U5 with OpenOCD?

[Rob M. <Rob...@u-...>]

Note: I have been editing the local file paths in the logs to make them more readable, but I didn't do so in the last log in my excitement at having achieved a success case 😊.  Rest assured that the locations of the executables, configuration files and image files are the same in the success case as in the fail cases.

Rob
-----Original Message-----
From: Rob Meades 
Sent: Wednesday, April 24, 2024 12:54 AM
To: Paul Fertser <fer...@gm...>
Cc: Tommy Murphy <tom...@ho...>; ope...@li...
Subject: RE: [OpenOCD-user] Anyone using STM32U5 with OpenOCD?

In addition, I just managed to get one success case, verbose log attached; I've cut the boring middle out of it so that it doesn't require moderator approval (the fail-case logs I sent earlier are awaiting moderator approval since the attachment size became rather large).  This success case happened to be with stm32u5_CFGFILE2.cfg but I have had successes with the other configurations in the past, and failures with this one, so I can't say that's relevant.

Rob

Re: [OpenOCD-user] Anyone using STM32U5 with OpenOCD?

[Rob M. <Rob...@u-...>]

In addition, I just managed to get one success case, verbose log attached; I've cut the boring middle out of it so that it doesn't require moderator approval (the fail-case logs I sent earlier are awaiting moderator approval since the attachment size became rather large).  This success case happened to be with stm32u5_CFGFILE2.cfg but I have had successes with the other configurations in the past, and failures with this one, so I can't say that's relevant.

Rob
-----Original Message-----
From: Rob Meades 
Sent: Tuesday, April 23, 2024 10:44 PM
To: Paul Fertser <fer...@gm...>
Cc: Tommy Murphy <tom...@ho...>; ope...@li...
Subject: RE: [OpenOCD-user] Anyone using STM32U5 with OpenOCD?

Thanks for your support with all of this so far guys, really very useful indeed.  Find attached logs with debug level 3 for the following fail cases of flash downloads to my NUCLEO U575ZI-Q board:

0.  Using OpenOCD directly, original reset ("reset_config srst_only") : stm32u5_verbose_log_CFGFILE0.txt, stm32u5_CFGFILE0.cfg.
1.  As (0) but with reset modified to match the Zephyr west openocd.cfg file ("reset_config srst_only srst_nogate connect_assert_srst"): stm32u5_verbose_log_CFGFILE1.txt, stm32u5_CFGFILE1.cfg.
2.  As (1) but with the interface also modified to match the Zephyr west openocd.cfg file (i.e. interface/stlink-dap.cfg, transport select "dapdirect_swd"): stm32u5_verbose_log_CFGFILE2.txt, stm32u5_CFGFILE2.cfg.
3.  Zephyr west using OpenOCD "out of the box", unmodified by me, which used to work but is now failing 'cos the board is in that kind of mood it would seem: stm32u5_zephyr_west_verbose.txt.

All taken with OpenOCD 0.12.0-3, board power-cycled before each run.

Are there any clues in there as to what I might be doing wrong?  I've not been able to get a pass case again unfortunately.

Rob

Re: [OpenOCD-user] Anyone using STM32U5 with OpenOCD?

[Paul F. <fer...@gm...>]

On Tue, Apr 23, 2024 at 05:50:45PM +0000, Rob Meades wrote:
> Interesting: attached find the [non-debug I'm afraid] log output
> from a success case using OpenOCD with the Zephyr west tool, plus
> the openocd.cfg file it employs.

You can just manually change that openocd.cfg to add "debug_level 3"
in the beginning and that should give you full debug log for
comparison.

> However, if I power the board down entirely and modify the
> reset_config line in my own stm32u5.cfg file to be the same as this
> I still, unfortunately, get the problem.

Please show new debug log with this.

Normally target config doesn't specify reset config, it's part of
whole setup on the board+adapter level. Only
srst_gates_jtag/srst_nogate belongs to the target config, it tells
OpenOCD whether communication under reset works, luckily ST does the
right thing there so it should always be possible to attach to a
target with SRST asserted.

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fer...@gm...

Re: [OpenOCD-user] Anyone using STM32U5 with OpenOCD?

[Rob M. <Rob...@u-...>]

Interesting: attached find the [non-debug I'm afraid] log output from a success case using OpenOCD with the Zephyr west tool, plus the openocd.cfg file it employs.

In the openocd.cfg file it does indeed say:

# Reset configuration
# use hardware reset, connect under reset
# connect_assert_srst needed if low power mode application running (WFI...)
reset_config srst_only srst_nogate connect_assert_srst

However, if I power the board down entirely and modify the reset_config line in my own stm32u5.cfg file to be the same as this I still, unfortunately, get the problem.

There's something I'm missing here...

Rob
-----Original Message-----
From: Paul Fertser <fer...@gm...>
Sent: Tuesday, April 23, 2024 6:45 PM
To: Rob Meades <Rob...@u-...>
Cc: Tommy Murphy <tom...@ho...>; ope...@li...
Subject: Re: [OpenOCD-user] Anyone using STM32U5 with OpenOCD?

**** This is an EXTERNAL email. It was sent from outside of u-blox. ****

On Tue, Apr 23, 2024 at 08:37:50PM +0300, Paul Fertser wrote:
> On Tue, Apr 23, 2024 at 04:00:34PM +0000, Rob Meades wrote:
> > Thanks for the swift response: verbose OpenOCD output attached.  The
> > odd thing is that this worked fine when OpenOCD was driven only by
> > Zephyr's west tool,
>
> Is it possible it was using "reset_config srst_only
> connect_assert_srst"?

Indeed it was
...

--
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fer...@gm...

Re: [OpenOCD-user] Anyone using STM32U5 with OpenOCD?

[Paul F. <fer...@gm...>]

On Tue, Apr 23, 2024 at 08:37:50PM +0300, Paul Fertser wrote:
> On Tue, Apr 23, 2024 at 04:00:34PM +0000, Rob Meades wrote:
> > Thanks for the swift response: verbose OpenOCD output attached.  The odd thing
> > is that this worked fine when OpenOCD was driven only by Zephyr’s
> > west tool,
> 
> Is it possible it was using "reset_config srst_only
> connect_assert_srst"?

Indeed it was
https://github.com/zephyrproject-rtos/zephyr/blob/main/boards/st/nucleo_u575zi_q/support/openocd.cfg#L20

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fer...@gm...

Re: [OpenOCD-user] Anyone using STM32U5 with OpenOCD?

[Liviu I. <il...@li...>]

> On 23 Apr 2024, at 19:00, Rob Meades <Rob...@u-...> wrote:
> 
> I’ve looked at OpenOCD versions and there are no functional changes in v0.12.0-3 so I think that the version we are using, v0.12.0-2, should be the latest,

I don't know what do you mean by 'are no functional changes', v0.12.0-3 uses the source code from Apr 1st: 

- https://xpack.github.io/blog/2024/04/02/openocd-v0-12-0-3-released/#compliance


Liviu

Re: [OpenOCD-user] Anyone using STM32U5 with OpenOCD?

[Paul F. <fer...@gm...>]

Hi Rob,

On Tue, Apr 23, 2024 at 04:00:34PM +0000, Rob Meades wrote:
> Thanks for the swift response: verbose OpenOCD output attached.  The odd thing
> is that this worked fine when OpenOCD was driven only by Zephyr’s
> west tool,

Is it possible it was using "reset_config srst_only
connect_assert_srst"?

Because if your target firmware sleeps or probably muxes SWD away
that might make connection less predictable. I need to take a closer
look to your logs with that tool to say more.

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fer...@gm...

Re: [OpenOCD-user] Anyone using STM32U5 with OpenOCD?

[Rob M. <Rob...@u-...>]

Understood: unfortunately moving to 0.12.0-3 has not helped.

Rob
-----Original Message-----
From: Liviu Ionescu <il...@li...> 
Sent: Tuesday, April 23, 2024 6:01 PM
To: Rob Meades <Rob...@u-...>
Cc: Tommy Murphy <tom...@ho...>; ope...@li...
Subject: Re: [OpenOCD-user] Anyone using STM32U5 with OpenOCD?

[You don't often get email from il...@li.... Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]

**** This is an EXTERNAL email. It was sent from outside of u-blox. ****

> On 23 Apr 2024, at 19:50, Rob Meades <Rob...@u-...> wrote:
>
> I guess they don't mean that there have been no functional changes since the previous release, they mean that _they_ have made no functional changes to the OpenOCD original release.

It means that the xPack release has no functional changes compared to the original upstream project, i.e. it uses exactly the original source code.

Liviu

Re: [OpenOCD-user] Anyone using STM32U5 with OpenOCD?

[Liviu I. <il...@li...>]

> On 23 Apr 2024, at 19:50, Rob Meades <Rob...@u-...> wrote:
> 
> I guess they don't mean that there have been no functional changes since the previous release, they mean that _they_ have made no functional changes to the OpenOCD original release.

It means that the xPack release has no functional changes compared to the original upstream project, i.e. it uses exactly the original source code.

Liviu

Re: [OpenOCD-user] Anyone using STM32U5 with OpenOCD?

[Rob M. <Rob...@u-...>]

Ah, sorry, I misunderstood the xPack website when it said, under "Changes", "There are no functional changes."

I guess they don't mean that there have been no functional changes since the previous release, they mean that _they_ have made no functional changes to the OpenOCD original release.

I will try the latest.

Rob

Re: [OpenOCD-user] Anyone using STM32U5 with OpenOCD?

[Rob M. <Rob...@u-...>]

Thanks for the swift response: verbose OpenOCD output attached.  The odd thing is that this worked fine when OpenOCD was driven only by Zephyr's west tool, the failure mode has only begun happening when we use OpenOCD directly ourselves, no HW changes.  Once the problem occurs Zephyr's west tool is equally unable to download to the board, so it seems like something is becoming "stuck" on the board itself.

I've looked at OpenOCD versions and there are no functional changes in v0.12.0-3 so I think that the version we are using, v0.12.0-2, should be the latest, and it is also the same binary we used by Zephyr.

The Zephyr world has its own per-board OpenOCD config file, of course, and the command-line used by Zephyr's west tool is a little more complex:

openocd -s /home/rob/zephyr/boards/arm/nucleo_u575zi_q/support '-c set _ZEPHYR_BOARD_SERIAL 003E004C3532510F31333430' -f /home/rob/zephyr/boards/arm/nucleo_u575zi_q/support/openocd.cfg -c 'gdb_report_data_abort enable' '-c init' '-c targets' -c 'reset init' -c 'flash write_image erase /home/rob/stm32u5.hex' -c 'reset run' -c shutdown

Rob
From: Tommy Murphy <tom...@ho...>
Sent: Tuesday, April 23, 2024 4:50 PM
To: Rob Meades <Rob...@u-...>; ope...@li...
Subject: Re: Anyone using STM32U5 with OpenOCD?

**** This is an EXTERNAL email. It was sent from outside of u-blox. ****
Sporadic connection/instability issues can often be caused by things like poor (or too long) wiring between the host PC/probe/target, unreliable power to the probe/target, clocking/timing issues etc.
So these are all things that might be worth eliminating as relevant factors.

Also - if you can capture and post a verbose (openocd -d3) log for a failure case it may help to identify problems.

And if you're not already doing so you might want to build and use the very latest OpenOCD from the repo rather than using some older version from an OS software repository or other download source.

Re: [OpenOCD-user] Anyone using STM32U5 with OpenOCD?

[Tommy M. <tom...@ho...>]

Sporadic connection/instability issues can often be caused by things like poor (or too long) wiring between the host PC/probe/target, unreliable power to the probe/target, clocking/timing issues etc.
So these are all things that might be worth eliminating as relevant factors.

Also - if you can capture and post a verbose (openocd -d3) log for a failure case it may help to identify problems.

And if you're not already doing so you might want to build and use the very latest OpenOCD from the repo rather than using some older version from an OS software repository or other download source.

[OpenOCD-user] Anyone using STM32U5 with OpenOCD?

[Rob M. <Rob...@u-...>]

Is anyone here using STM32U5 (on a NUCLEO-U575ZI-Q board, so via the ST DAP on that board) with OpenOCD (v0.12.0-2) reliably?

We've been using OpenOCD with it for a while, driven through Zephyr's "west" tool, but we have just begun using OpenOCD directly instead and find that, every so often, OpenOCD is unable to connect to the target and stays that way (across power-cycles of the board) until eventually, after repeated tries, it begins working again.  We do nothing particularly obvious to cause the problem, or to fix it for that matter.

OpenOCD command line is:

openocd -f /home/rob/cfg/stm32u5.cfg -c "gdb_port disabled" -c "tcl_port disabled" -c "telnet_port disabled" -c "adapter serial 003E004C3532510F31333430" -c "program /home/rob/stm32u5.elf reset" -c "exit"

...stm32u5.cfg is attached.

In all cases OpenOCD finds the DAP:

Info : STLINK V3J12M3 (API v3) VID:PID 0483:374E
Info : Target voltage: 3.291200

...but is unable to identify the STM32U5 itself, messages like:

Warn : target stm32u5x.cpu examination failed

...or:

Error: [STM32U575ZITxQ.cpu] Could not find MEM-AP to control the core

...or just:

Error: init mode failed (unable to connect to the target)

...are emitted.  We are not using secure images, just boring non-secure stuff.

I've tried asking about this on the ST and Zephyr support forums but no answers there.

Rob