#386 OpenOCD can't connect to Dialog DA1469x

[Maximilian Gerhardt]

Specifically, I have a custom DA14695 board, but it's the same with a USB DevKit. Chip datasheet see here. It's a Cortex-M33 and Cortex-M0+ coprocessor (runs Bluetooth stack). Each have their own SWDIO+SWDCLK signals. I'm only interested in connecting to the Cortex-M33 main processor right now.

Currently, the Dialog DA1469x is unsupported in OpenOCD. Only the proprietary JLinkExe can connect it. I want to be able to use OpenOCD and other debug adapters. So to get started with getting OpenOCD + JLink to work first without changing the debug adapter.

this however fails horribly with the error

Debug: 1132 515 jlink.c:2197 jlink_swd_run_queue(): SWD ack not OK: 7 JUNK
Error: 1133 517 adi_v5_swd.c:144 swd_connect(): Error connecting DP: cannot read IDR

While when using JLinkExe, it detects the chip just fine

Found SW-DP with ID 0x0BE12477
AP0: AHB-AP (IDR: 0x14770015)
Found Cortex-M33 r0p2, Little endian.

OpenOCD fails at one of the very first steps, which is in the SWD protocol to do a LINERESET followed by the JTAG->SWD switch sequence, a LINERESET again and reading out the IDCODE. Looking at the SWD signals with a logic analyzers and PulseView, I compared the different signals that OpenOCD and JLinkExe produced and found that JLinkExe does a few more LINERESETs as the first attempt of reading IDCode actually fails, without a JTAG->SWD sequence in between.

I'd also like to note that after using JLinkExe to connect, through some command sequence that I cannot reproduce anymore, openocd managed to connect using that config file. That's why I at least now -irlen 8 is right, it would not do that with -irlen 4. From there I coud do a "dap info".

Here attached are the PulseView session files which should have the signal trace (with SWD decoding) in it, from JLinkExe and OpenOCD, next to the config file and JLinkExe output (sadly there are no verbose logs there). The OpenOCD command I'm using is 'openocd -f interface/jlink.cfg -c "transport select swd" -s . -f dia.cfg -c "gdb_memory_map disable"'

I'd be happy for any pointer on how to get OpenOCD to talk to the Cortex-M33 successfully.

[Maximilian Gerhardt]

I've stitched together screenshots from PulseView to give a broad overview here. OpenOCD only gets NOREPLY in the red answer fields, JLinkExe gets NOREPLY, 7xERROR, NOREPLY, then OK. Of course it's best when you look at the traces in PulseView directly though.

[Maximilian Gerhardt]

And I guess it would also be a good idea to include the -d4 debug logs of OpenOCD.

[Paul Fertser]

Hi,

On Wed, Mar 15, 2023 at 02:30:07PM -0000, Maximilian Gerhardt wrote:

Currently, the Dialog DA1469x is unsupported in OpenOCD. Only the proprietary
JLinkExe can connect it. I want to be able to use OpenOCD and other debug
adapters.

Do you also hope to be able to flash this target? As that would
require developing a dedicated flash driver.

OpenOCD fails at one of the very first steps, which is in the SWD protocol to do
a LINERESET followed by the JTAG->SWD switch sequence, a LINERESET again and
reading out the IDCODE. Looking at the SWD signals with a logic analyzers and
PulseView, I compared the different signals that OpenOCD and JLinkExe produced
and found that JLinkExe does a few more LINERESETs as the first attempt of
reading IDCode actually fails, without a JTAG->SWD sequence in between.

That's quite a valueable clue. You can try tweaking
swd_connect_single() in src/target/adi_v5_swd.c to match the
behaviour, probably by adding swd_send_sequence(dap, LINE_RESET); or
changing swd_seq_jtag_to_swd[] in src/jtag/swd.h .

I'd also like to note that after using JLinkExe to connect, through some command
sequence that I cannot reproduce anymore, openocd managed to connect using that
config file. That's why I at least now -irlen 8 is right, it would not do that
with -irlen 4. From there I coud do a "dap info".

irlen is only meaningful in JTAG mode, not in SWD.

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

[Maximilian Gerhardt]

Okay I actually have to apologize, I used an old OpenOCD version that was with the distribution, and it did say OpenOCD 0.11.0. But it was from freaking 2021. I grabbed the latest git version, with libjaylink, compiled it mayself, and now the very same configuration file can connect to the chip with no changes!

$ ~/ocd/openocd/openocd_installed/usr/local/bin/openocd -f interface/jlink.cfg -c "transport select swd"  -s . -f dia.cfg -c "gdb_memory_map disable"  
Open On-Chip Debugger 0.12.0+dev-01082-gfc30feb51 (2023-03-15-16:12)
Licensed under GNU GPL v2
For bug reports, read
    http://openocd.org/doc/doxygen/bugs.html
swd
Info : DEPRECATED target event trace-config; use TPIU events {pre,post}-{enable,disable}
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : J-Link V11 compiled Jul 28 2021 10:07:38
Info : Hardware version: 11.00
Info : VTarget = 3.300 V
Info : clock speed 50 kHz
Info : SWD DPIDR 0x0be12477
Info : [da1469x.cpu] Cortex-M33 r0p2 processor detected
Info : [da1469x.cpu] target has 8 breakpoints, 4 watchpoints
Info : starting gdb server for da1469x.cpu on 3333
Info : Listening on port 3333 for gdb connections

I will have to check with GDB now if debugging works fine, and if it does, I will close this ticket.

But one thing that is weird is that two subsequent connect + disconnects makes it fail at the second connect with a

Debug: 292 152 arm_adi_v5.h:652 dap_dp_poll_register(): DAP: poll 4 timeout
Debug: 293 152 command.c:544 run_command(): Command 'dap init' failed with error code -5

but maybe that's another story.

[Antonio Borneo]

Good that it work now!
I see that your dia.cfg is inspired from some STM32Lxx. It has inside some STM32 specific initialization that is probably causing issues with your chip.
- Remove the lines related to the flash,
- check that the SRAM is at the specified physical address 0x20000000 in the command for work-area,
- remove the command mww specific for STM32 inside event examine-end,
- if you have connected the reset wire, think about updating the command "reset_config none".

[Maximilian Gerhardt]

Many thanks for the comments, indeed I removed the flash references and moved the workspace to end of ram minus 4 kByte (0x200... start was correct though).

I struggled quite a bit with then breakpoints properly working in GDB / VSCode+Cortex Debug, but at the end I found out it was trying to use software breakpoints (and failing ofc bc OpenOCD can't flash a break instruction into the flash without a driver), so I had to apply the trick to mark the flash address space as read-only in GDB, and mark everything else as accessible.

Adding a flash driver is a story for another day.

For the sake of anyone searching up OpenOCD + Dialog DA1469x, I provide the used OpenOCD config file and the launch.json for VSCode (Cortex-Debug extension) as attachments and will close the ticket.

Thanks again!

Edit: It seems I can't close tickets myself? You can mark the ticket as solved please :)