joncs
Posts: 31
Joined: Mon Nov 25, 2019 11:52 pm

openocd, jtag, fyi

Sun Feb 28, 2021 12:56 am

Today openocd stopped working with my rpi3b+. I never found the reason. Same openocd 0.10.0 binary, same config files, same rpi as always. It's been working for at least a year. So I suppose some other change occurred in the linux system that caused the breakage.

Anyway, the problem was "fixed" by compiling openocd 0.11.0 rc2 and installing. Now everything works again.

Some of the error messages I got: "Invalid command name DAP", and "Interface does not support any transport?"

This is just a note for posterity. If anyone knows what the problem was I wouldn't mind having the answer.

valc
Posts: 60
Joined: Mon Oct 21, 2019 10:17 pm

Re: openocd, jtag, fyi

Mon Mar 01, 2021 9:34 am

When you work with JTAG do you have to manually turn raspberry pi on and off?
I have to , because otherwise it does not reset it's internal states and has strange consequences.
Is there any good reset workflow described anywhere?

I've tried to reset the whole thing via calling the watchdog code, but it does not seem to work
when device is being debugged by JTAG.

joncs
Posts: 31
Joined: Mon Nov 25, 2019 11:52 pm

Re: openocd, jtag, fyi

Mon Mar 01, 2021 5:30 pm

Yes, I have to turn it on and off. Very annoying.

I too have tried the watchdog timer with mixed results. I'm using a FT232H board and openocd and I find that for best results I have to do this 5 second dance whenever I want to reset:

1. kill openocd
2. power off the RPi
3. unplug the usb cable,
4. power on the RPi,
5. plug in the usb cable.
6. restart openocd

That way it seems the RPi, the FTDI thingy, the /dev/ttyUSB devices, and the openocd server are all back on the same page.

There must be a better way but I don't know what it is.

valc
Posts: 60
Joined: Mon Oct 21, 2019 10:17 pm

Re: openocd, jtag, fyi

Mon Mar 01, 2021 8:25 pm

Good.)
Now i know someone else is experiencing the same problems as I do.

I perform the same steps except that I don't need to unplug the USB cable from my JTAG debugger.
Which IS OLIMEX based on FTDI2232H.

But I hate doing the power off / power each time. I'm thinking of actually adding some power key, maybe some atmega should control raspberry pi's power, so I could run a script that sends a USB command to atmega to turn the power off , then back on and at the same time this same script kills and reopens openocd, something like that)

cleverca22
Posts: 4345
Joined: Sat Aug 18, 2012 2:33 pm

Re: openocd, jtag, fyi

Mon Mar 01, 2021 8:27 pm

you can wire the SRST (system reset) of your jtag adapter to the RUN pin of the pi (its main reset)

but be aware, hitting RUN will cause the arm jtag to stop responding for a few seconds (until bootcode.bin and start(4).elf have fully booted)

joncs
Posts: 31
Joined: Mon Nov 25, 2019 11:52 pm

Re: openocd, jtag, fyi

Mon Mar 01, 2021 9:29 pm

Good news (for me anyway). I tried again the reset via watchdog from inside jtag and it worked! Here is my version of the reset code for RPi 3B+. Based off stuff in David Welch's repo, based on Linux kernel, ...

Code: Select all

	.global sys_reset

	.equ PM_BASE, 0x3f100000	
	.equ PM_WDOG, PM_BASE + 0x24
	.equ PM_RSTC, PM_BASE + 0x1c
	.equ PM_PASSWORD, 0x5a000000
	.equ PM_RSTC_WRCFG_FULL_RESET, 0x00000020

	// Sets a watchdog timer for a short period and goes into
	// a loop. After the brief wait the timer forces a reset.

	// This is a pretty hard reboot. It stops short of power cycling.
	// But ram is lost, the processor is reset. Goes back to the gpu
	// boot rom. Reloads bootcode.bin. etc.
	
	.text
sys_reset:
	ldr x1, =PM_WDOG
	ldr w0, =(PM_PASSWORD | 20000)  // number has to do with time pause before reset.
	str w0, [x1]
	ldr x1, =PM_RSTC
	ldr w0, =(PM_PASSWORD | PM_RSTC_WRCFG_FULL_RESET)
	str w0, [x1]
	
hang:	b hang

To use it I do this in openocd:

Code: Select all

> reg pc 0x80150  (or whichever address it ends up at)
> resume
I get 10 seconds of STICKY ERRORs and then it gets back in sync.

Working might depend on my upgrade to 0.11.0-rc2. I don't know. It has failed in the past. Hope this helps.

cleverca22
Posts: 4345
Joined: Sat Aug 18, 2012 2:33 pm

Re: openocd, jtag, fyi

Tue Mar 02, 2021 8:50 am

thats a purely software method of triggering the full SoC reset, same end result as pulling RUN low for a moment

sean.lawless
Posts: 60
Joined: Thu Jun 06, 2019 6:07 pm

Re: openocd, jtag, fyi

Tue Mar 02, 2021 6:16 pm

There is a C code version of the watchdog reset here (see SystemReboot() function at end):
https://github.com/sean-lawless/compute ... pi/board.c

If your application or bootloader calls SystemReboot(), then OpenOCD typically recovers once the Pi is up and running again. Long term soft resets (and/or bumps of the JTAG wires if GPIO) can require an OpenOCD restart.

valc
Posts: 60
Joined: Mon Oct 21, 2019 10:17 pm

Re: openocd, jtag, fyi

Tue Mar 02, 2021 10:02 pm

Great. Also confirm that this code works. I've actually had this void reboot() function , but I've had a typo in a password value.

valc
Posts: 60
Joined: Mon Oct 21, 2019 10:17 pm

Re: openocd, jtag, fyi

Mon Mar 08, 2021 11:59 am

You can reboot the PI from openocd like that:

In my repo folder I have an openocd.cfg file, that I've added into my command line with some more defined helper functions.
Now that I know that reboot is working - I was thinking it would be cool to write to the registers straight from
telnet. Here is a simple openocd function for that

Code: Select all

proc pi_reboot {} {
  targets pi.0
  halt
  mww 0x3f100024 0x5a000001
  mww 0x3f10001c 0x5a000020
}
mww - write machine word to address, but it will only work if you first halt the current core, so
I also do these 2 lines for that:
targets pi.0 - selects the core number 0, you probably have defined some other name instead of "pi.0"
halt - stops the core obviously

dwelch67
Posts: 1006
Joined: Sat May 26, 2012 5:32 pm

Re: openocd, jtag, fyi

Wed Mar 10, 2021 12:35 am

I just bought a new usb hub and now they have ones with power buttons per port, works great you can power cycle the board with that button. Not sure how fast they wear out, but get a 7 port and that will last a while.

As you know from my repos I solder a reset button between run and ground and normally just use that instead of unplugging the cable.

David

joncs
Posts: 31
Joined: Mon Nov 25, 2019 11:52 pm

Re: openocd, jtag, fyi

Wed Mar 10, 2021 2:58 am

Per port power button seems like a step in the right direction. I'll get one and try it out. For now, after this thread (thanks all), I am pretty happy with the software reboot. It does what I expect >90% of the time. I only power cycle once or twice a day now!

That word "solder" concerns me. I've always been more a software/math guy. I have visions of a dozen burning boards at my feet, three blistered and bandaged fingers, and finally one properly connected switch. But maybe time to bite the bullet and learn to solder and measure voltages etc. Can't be that bad can it???

valc
Posts: 60
Joined: Mon Oct 21, 2019 10:17 pm

Re: openocd, jtag, fyi

Wed Mar 10, 2021 5:15 am

For this purpose I have soldered this high-end device from some leftover parts. The top part is some micro-usb adapter that's easy for soldering and below is just a standard usb port component. Super-easy to solder and no need to do solder experiments with the board.
But openocd jtag way is much nicer, because it can be intergrated into code upload scripts that just do the work themselves you just hit "upload"
pi_adapter_1.jpg
pi_adapter_1.jpg (112.31 KiB) Viewed 1340 times
pi_adapter_0.jpg
pi_adapter_0.jpg (118.95 KiB) Viewed 1340 times

kpwashere
Posts: 7
Joined: Wed Jun 05, 2019 8:43 pm

Re: openocd, jtag, fyi

Mon Jul 26, 2021 10:39 pm

I can confirm, this works a treat! Thanks.

Also, here are some good concise references as there are lots of bits here and there, these ones are very concise.

https://sysprogs.com/VisualKernel/tutor ... jtagsetup/

https://yeah.nah.nz/embedded/pi-jtag-u-boot/



Adjusted for the pi zero: define this command in your config

Code: Select all

proc pi_reboot {} {
  targets rspi.arm
  halt
  mww 0x20100024 0x5a000001
  mww 0x2010001c 0x5a000020
}

Return to “Bare metal, Assembly language”