And here (at `zapb_`'s request) is the output from swapping `load` and `monitor
tpiu ...` order:
This worked fine: itm output was observed, etc.
gdb:
```
(gdb) target extended-remote :3333
Remote debugging using :3333
0x20000010 in ?? ()
(gdb) load
Loading section .vector_table, size 0x1f8 lma 0x8000000
Loading section .text, size 0x1518 lma 0x80001f8
Loading section .init_array, size 0x8 lma 0x8001710
Loading section .fini_array, size 0x4 lma 0x8001718
Loading section .rodata, size 0x4d4 lma 0x800171c
Loading section .data, size 0x434 lma 0x8001bf0
Loading section .build_info, size 0x40 lma 0x8002024
Loading section .note.gnu.build-id, size 0x24 lma 0x8002064
Loading section .build_info_suffix, size 0x4 lma 0x8002088
Loading section .ram_func, size 0x38 lma 0x800208c
Start address 0x8000238, load size 8388
Transfer rate: 8 KB/sec, 838 bytes/write.
(gdb) monitor tpiu config internal itm.fifo uart off 216000000
Can not obtain 30000000 trace port frequency from 216000000 TRACECLKIN
frequency, using 27000000 instead
(gdb) c
Continuing.
shutdown command invoked
Remote connection closed
(gdb)
```
Attachments:
-
[jlink-swd-stm32f7x-gdb-load-tpiu-ok.txt](https://sourceforge.net/p/openocd/tickets/_discuss/thread/6f40c90d/9808/attachment/jlink-swd-stm32f7x-gdb-load-tpiu-ok.txt)
(258.7 kB; text/plain)
---
** [tickets:#184] jlink: failure after `load` when `tpiu` is used to enable
tracing**
**Status:** new
**Milestone:** 0.9.0
**Created:** Fri Apr 27, 2018 05:33 PM UTC by Cody Schafer
**Last Updated:** Wed Aug 22, 2018 06:56 PM UTC
**Owner:** nobody
**Attachments:**
-
[openocd.log](https://sourceforge.net/p/openocd/tickets/184/attachment/openocd.log)
(359.8 kB; text/x-log)
Log output attached. openocd is from today's master with a few patches to fix
undefined shifts applied.
I'm targeting a stm32f777bit board with a cortex debug+etm header. I'm using a
j-link plus (more details in log). I'm using a "J-Link adapter CortexM" to
connect the jlink to the board. gdb used is `arm-none-eabi-gdb 8.1-2` from arch
linux.
Using the gdb command `load` prior to `tpiu` works, but trying to `load` after
`tpiu` fails. Full commands below.
Reproduction steps:
1. run `openocd -f interface/jlink.cfg -c 'interface swd' -f
target/stm32f7x.cfg`
2. run `arm-none-eabi-gdb binary.elf`
3. In gdb, run:
`
target extended-remote :3333
monitor reset init
load
`
4. openocd appears to load the binary successfully.
5. In gdb, run:
`
monitor tpiu config internal itm.fifo uart off 216000000
load
`
6. openocd begins emitting errors (as seen in the log). The "Can not obtain..."
line is emitted after using the `tpiu` command. The `Padding image` starts
output of the load command.
Additional notes:
- `binary.elf` contains code with clocks the processor to 216MHz and
occasionally prints to ITM.
- normally, the gdbinit contains:
```
target extended-remote :3333
monitor reset init
monitor tpiu config internal itm.fifo uart off 216000000
monitor itm port 0 on
load
step
```
- using the above invocation with a st-link v2 works without issue (` openocd
-f interface/stlink.cfg -f target/stm32f7x.cfg`)
---
Sent from sourceforge.net because openocd-devel@lists.sourceforge.net is
subscribed to https://sourceforge.net/p/openocd/tickets/
To unsubscribe from further messages, a project admin can change settings at
https://sourceforge.net/p/openocd/admin/tickets/options. Or, if this is a
mailing list, you can unsubscribe from the mailing list.------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel
