Using OpenOCD with imx7/colibri

Technical Support
, , , ,
1

Hi !
I’m trying to debug some bare metal code running on imx7 with a colibri evaluation board, using a Bus Blaster v4.1a probe and openocd (freshly cloned from Public Git Hosting - openocd.git/summary 3737dd69e73816d186ba418d7b833462a8041079). We are running on the first cortex A7 and we don’t use the secondary A7 or the M4.

They do not provide an “out of the box” configuration for imx7 colibri combo, but there is a configuration for nxp imx7 sabre that I tried to use. The configuration seems “ok” as openocd doesn’t display any errors on connexion:

$ sudo build/bin/openocd -f tcl/interface/ftdi/dp_busblasg -f tcl/board/nxp_imx7sabre.cfg 
Open On-Chip Debugger 0.10.0+dev-00403-g3737dd6 (2018-04-23-09:42)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
Info : If you need SWD support, flash KT-Link buffer from https://github.com/bharrisau/busblaster
and use dp_busblaster_kt-link.cfg instead
adapter speed: 1000 kHz
trst_and_srst separate srst_gates_jtag trst_push_pull srst_push_pull connect_deassert_srst
adapter_nsrst_delay: 100
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : clock speed 1000 kHz
Info : JTAG tap: imx7.cpu tap/device found: 0x5ba00477 (mfg: 0x23b (ARM Ltd.), part: 0xba00, ver: 0x5)
Info : imx7.cpu_a7.0: hardware has 6 breakpoints, 4 watchpoints
Info : Listening on port 3333 for gdb connections
Info : Listening on port 3334 for gdb connections
Info : accepting 'gdb' connection on tcp/3333
Info : imx7.cpu_a7.0 rev 5, partnum c07, arch f, variant 0, implementor 41
Info : imx7.cpu_a7.0 cluster 0 core 0 multi core

However I don’t manage to reset the ship using the reset init command or modifying pc by hand, so I cannot do much.

Does anyone have any working configuration for imx7 / colibri / openocd ? Or any advice on how to address the issue / modify the configuration to have reset and break points working ?

Best,
V.

EDIT:
My openocd configuration is the following:

I invoke openocd with openocd -f tcl/interface/ftdi/dp_busblaster.cfg -f tcl/board/nxp_imx7sabre.cfg

From what I could gather from this morning, the setup is almost ok: I
can halt the cpu and perform some “step execution”, or change the value
of some registers, like pc.
Some other options don’t work correctly: I didn’t succeed in setting
some break points, and I have difficulties going through code that shuts
down the MMU.

However, the openocd “reset halt” command doesn’t seem to reset the
board: pc is not modified, VBAR/SCTLR are not modified either.

To test this, I halted the cpu during u-boot’s prompt, where I can use
step or change pc. There, I did two tests:

  • reset halt, then step: pc didn’t move
  • set pc to 0, reset halt, step: pc resumed the execution from the
    address 0, which is not mapped in the current MMU so a prefetch abort
    is triggered, in uboot’s VBAR. That’s why it seems that the reset
    didn’t happen correctly.

Any help is welcome :wink:

3

It looks like to properly reboot colibri imx7 you need srst line, unfortunately this line is not connected on colibri evaluation board.

with this config:

# reset configuration has TRST and SRST support
reset_config srst_only srst_push_pull
adapter_nsrst_assert_width 100
# need at least 100ms delay after SRST release for JTAG
adapter_nsrst_delay 10

and srst connected to reset_ext I can do:

imx7.cpu_a7.0: hardware has 6 breakpoints, 4 watchpoints
> halt
imx7.cpu_a7.0 rev 5, partnum c07, arch f, variant 0, implementor 41
imx7.cpu_a7.0 cluster 0 core 0 multi core
target halted in Thumb state due to debug-request, current mode: Supervisor
cpsr: 0x800000f3 pc: 0x8fd1aac8
imx7.cpu_a7.0 rev 5, partnum c07, arch f, variant 0, implementor 41
MMU: enabled, D-Cache: enabled, I-Cache: enabled
> reset halt
JTAG tap: imx7.dap tap/device found: 0x5ba00477 (mfg: 0x23b (ARM Ltd.), part: 0xba00, ver: 0x5)
Debug regions are unpowered, an unexpected reset might have happened
JTAG-DP STICKY ERROR
imx7.cpu_a7.0: ran after reset and before halt ...
target halted in Thumb state due to debug-request, current mode: Supervisor
cpsr: 0x400000f3 pc: 0x00000270
imx7.cpu_a7.0 rev 5, partnum c07, arch f, variant 0, implementor 41
MMU: disabled, D-Cache: disabled, I-Cache: enabled
> resume
> halt
target halted in Thumb state due to debug-request, current mode: Supervisor
cpsr: 0x800000f3 pc: 0x8fd1ab5c
imx7.cpu_a7.0 rev 5, partnum c07, arch f, variant 0, implementor 41
MMU: enabled, D-Cache: enabled, I-Cache: enabled
>

I’ve tried with segger jlink and busblaster v3c with kt-link software.

4

Dear dominik.tx, this seems quite promising, I’ll check if I can reproduce this on my end.
However, since I’m a bit of a novice with JTAG and hardware setup, could you be a bit more precise on how to “connect srst to reset_ext” ? What do I need to do to achieve that ?

EDIT: from the datasheet, I think you meant to connect reset_ext (Power Control Header X4, pin 6 Reset_ext) to JTAG_SYSRESET (JTAG to Host X13, pin 15). Is that so ? In that case, I’m not sure how to connect both pins as they are quite far appart. Do you have any suggestions on how to do so ?

5

you need to connect reset_ext (Power Control Header X4, pin 6 Reset_ext) to SRST of your JTAG.

6

Ok, I think I got it. I now am able to reset the core, but I don’t stop as early as you. However it should be enough for my purpose, thanks !

7

You can try tweaking adapter_nsrst_delay 10 to halt a bit faster, but it’s really hit and miss.