Debugging a SuperH4 target (Anritsu MS2721B)

[brainstorm]

While attempting repair of an Anritsu MS2721B 6GHz "portable" spectrum analyzer, I mapped out the JTAG pinout of its main SH4 (SH7750R) MCU on the board.

For context, the unit was working before but stopped booting up, so now I'm trying to figure out where exactly is the device halting within the (early) boot sequence.

Then I went for Glasgow to confirm the JTAG pinout and indeed, those pins are well identified:

(glasgow) rvalls@m1 glasgow % glasgow run jtag-pinout --port A --pins-jtag 1,3,5,6 -f 250 -V 1.8
I: g.device.hardware: building bitstream ID 32f2f979fe52e87384b67000968b34fa
I: g.cli: running handler for applet 'jtag-pinout'
I: g.applet.interface.jtag_pinout: port(s) A voltage set to 1.8 V
I: g.applet.interface.jtag_pinout: detecting pull resistors
I: g.applet.interface.jtag_pinout: pull-H: A1, A3, A5, A6
I: g.applet.interface.jtag_pinout: detecting TCK, TMS, and TDO
I: g.applet.interface.jtag_pinout: shifted 10 out of IR with TCK=A1 TMS=A5 TDO=A3
I: g.applet.interface.jtag_pinout: detecting TDI
I: g.applet.interface.jtag_pinout: shifted 32-bit IR with TCK=A1 TMS=A5 TDI=A6 TDO=A3
I: g.applet.interface.jtag_pinout: JTAG interface without reset detected
I: g.applet.interface.jtag_pinout: use `jtag-probe -V 1.8 --pin-tck 1 --pin-tms 5 --pin-tdi 6 --pin-tdo 3` as arguments

And they also spit some TAP info:

(glasgow) rvalls@m1 glasgow % glasgow run jtag-probe -V 1.8 --pin-tck 1 --pin-tms 5 --pin-tdi 6 --pin-tdo 3 scan
I: g.device.hardware: building bitstream ID a441e52aea68aafca8d02fa0007c27cf
I: g.cli: running handler for applet 'jtag-probe'
I: g.applet.interface.jtag_probe: port(s) A, B voltage set to 1.8 V
I: g.applet.interface.jtag_probe: shifted 1-bit DR=<0>
I: g.applet.interface.jtag_probe: shifted 32-bit IR=<10111111111111111111111111111111>
I: g.applet.interface.jtag_probe: discovered 1 TAPs
I: g.applet.interface.jtag_probe: TAP #0: IR[32] BYPASS

And even attempted to establish some JTAG bitbanged session for OpenOCD, similar to my previous attempts with an ESP32S2:

% glasgow run jtag-openocd -V 1.8 --pin-tck 1 --pin-tms 5 --pin-tdi 6 --pin-tdo 3 -f 100 -V 3.3 tcp:localhost:2222
I: g.device.hardware: building bitstream ID c850b1822f53f5fa7fc5e4ec24e21c87
I: g.cli: running handler for applet 'jtag-openocd'
I: g.applet.interface.jtag_openocd: port(s) A, B voltage set to 3.3 V
I: g.applet.interface.jtag_openocd: socket: listening at tcp:localhost:2222
I: g.applet.interface.jtag_openocd: socket: new connection from [::1]:58608

% openocd -c 'interface remote_bitbang; remote_bitbang_port 2222'
Open On-Chip Debugger 0.11.0+dev-00471-gcaa169813 (2021-11-20-01:35)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
DEPRECATED! use 'adapter driver' not 'interface'
Info : only one transport option; autoselect 'jtag'
DEPRECATED! use 'remote_bitbang port' not 'remote_bitbang_port'
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections
Info : Initializing remote_bitbang driver
Info : Connecting to localhost:2222
Info : remote_bitbang driver initialized
Info : This adapter doesn't support configurable speed
Warn : There are no enabled taps.  AUTO PROBING MIGHT NOT WORK!!
Info : TAP auto0.tap does not have valid IDCODE (idcode=0xfffffffe)
Warn : AUTO auto0.tap - use "jtag newtap auto0 tap -irlen 2 -expected-id 0x00000000"
Warn : gdb services need one or more targets defined

But then after scanning OpenOCD for suitable targets, I couldn't find any SuperH4 related ones. So I went back to the datasheet linked above and sections 20 and 21 describe what seems to be a customization (extension?) of JTAG called "H-UDI" (and its debugging support called "UBC").

Also there seem to be some 12-y.o dead end threads on renesasrulz.com regarding BSDL availability for those targets.

Is there somebody experienced with this target within this community? Is there any prior art of OSS tooling for SH4 that somebody can point me to?

[whitequark]

I've looked Section 21 of the manual you've referenced. It doesn't quite provide enough information to build a complete debugger. Look at this diagram:

The peripheral module bus is what you'd actually use to stop the core and examine its state. To do this, you need to issue memory reads and writes on that bus. But there's no described way to do this. If I had to guess, there are undocumented SDIR bits that set transaction width and type and strobe accesses, though there could be other ways to do this.

Regarding BSDL files, those can be written from scratch using Table 21.3 and Section 21.2.1, if you need them.

[brainstorm]

I emailed a few of the J-core devs yesterday and here's a nice piece of info about those special SH4 JTAG debuggers:

I didn't find any documentation regarding JTAG for SH4. I basically
bought one of these: https://www.apnet.co.jp/product/superh/xf.html

I did investigate a bit on my own, and discover that this JTAG is a bit
complicated. First this the JTAG does is to upload a binary blob into
the SH4 (is called ASE memory). This provides specific/custom
functionality that the probe uses later on (like for example cache
misses ratio calculator). The point is that once you get one of these
you don't really need to reverse engineer anything, it just works like a
charm.

[freemin7]

Have you heard back from them?

[brainstorm]

Yes, we had a good discussion with them, referred to a couple of folks at Renesas, but after following those Renesas replied that they are not interested in non-paying customers :/

[L0caler]

Can you ask them to give info about the XrossFinder hardware?

[neuschaefer]

Something that someone with a debugger such as the XrossFinder could do, would be to trace a debug session: i.e. record both the JTAG traffic and the interactive session (debugger console) while trying out a bunch of different actions (stop/continue the core, read/write GPRs/FPRs/etc., read/write memory, set the program counter, ...)

I have taken a similar approach for PowerPC, and it's been quite useful.

[whitequark]

Yeah. We could even make an applet for analyzing JTAG.

[brainstorm]

Happy to sponsor https://apnet.co.jp/product/superh/ap-sh4-1a.html dev board to elucidate H-UDI and have as much as possible supported on Glasgow as discussed over IRC.

Feel free to reach out to brainstorm at nopcode dot org for logistics, no rush ;)

[mtaalas]

Did this ever pan out? :)
Trying to reverse engineer a piece of SH3 hardware and came to the same wall of debuggers costing 1000€+/piece.

[brainstorm]

Not yet, but hopefully at some point in the future :)

I think that a very sensible summary that matches my personal situation (and possibly others) w.r.t to this particular project and time commitments is this from Catherine:

Please stay patient and keep in mind that hardware is made by people who have limited capacity and sometimes need to recover from extreme events.

If you want to show appreciation or help with Catherine's living costs, she has a personal Patreon. These donations will not impact the progress of the project since the limiting factor is health first and time second, but they are very much appreciated.

My available time and disposable income has changed quite a bit since I was tinkering and wrote all this. I'd love to work on it and see it unfold, but I've also have to be realistic about other life priorities, time and sources of income to sustain myself and others :)

[dossalab]

I had some experience debugging STi7105 with ST40 Micro Toolset, I think parts of this toolchain are available somewhere on the internet (you know whom to ask, wink-wink) The adapter is just a regular FT2232 mini module with changed device name and VID:PID pair....
It's laggy and aging though so I'd wish there was some FLOSS solution.
I sometimes work on this target so if there's some interest I can assist or document stuff that I'm doing.

[brainstorm]

Yes please! Document and capture (traces) as much as possible, I'd also like to see FLOSS support for SuperH... it's interesting that talks about this arch keep popping up on HN after so long.

[L0caler]

Ive been reasearching on this the last couple days. Im interested in finding a debugger for Casio Calculators with SuperH SH4 CPU.
If the Jtag interface is detected on Glasgow i can hopefully also use BlueTag with Pi Pico to figure out the pins on my calculator.

Appearently there has been a debugger for the Sega Dreamcast 25 years ago. So there is a chance that i can get it to work on a calculator https://www.sega-dc.de/dreamcast/Dreamcast_Debug_Handler

There is a japanese website that sold their own Flashers and debuggers. Thir device XrossFinder has a driver that has a few FTDI entries. Like it says FTDIBUS.INF. It could be an FTDI with a modified firmware. Or maybe the FTDI is used to communicate with the debugger. Idk
They also have a firmware updater download were the firmware could probably be extracted.
The corresponding flashing software can flash and read out firmware over H-UDI with the XrossFinder. Its license check can easily be bypassed. Maybe its also possible to use their debugging software.

I also extracted the files from the official E10A Debugger update and High Performance Embedded Workshop software update. There are drivers and a program e10aset.exe. That program is appearently used to switch modes and set up the debugger for different CPUs. But its loading a 109 kb E1adp.mot file (which i dont know yet what arch it is, its not SH4 assembly). I hope it has something to do with the device firmware.

If someone is interested i can send files.

[xssfox]

Just a random scattering of notes from trying to figure this out myself for a SH7724.

STMicro also licenced the SH4 arch under the name st40 - which also uses H-UDI although in some docs they've dropped the "H". Someone has made a fork of urjtag (https://github.com/jekkos/urjtag-st7xxx) which has partial support for the ST40. I tried this with dirtyjtag (did have to backport dirtyjtag support into the st7xxx fork) along with changing the dirtyjtag setup to push pull (though I don't know if this is right) for the CS_RESET pin - which is being used for the ASEBRK IO. This didn't really work for me (not really surprised).

The st7xxx fork requires a sh4stdi.mc2 file which can be found in the stlinux cdrom (https://archive.org/details/stlinux-2.4-sh-4) under updates/RPMS/sh4/stlinux24-cross-sh4-shdebug-7.6-14.i386.rpm and I believe the offset is 0051e300

I have no idea if the stlinux sh4stdi.mc2 is suitable for the renesas sh7724 in anyway - I just thought I'd try it as a long shot.

Apparently the SH7724 is in the SH7780 series, and there is a BSDL for the SH7780 however I don't think this lines up very well. It's suspect BSR is still possible on the SH7724 even without using H-UDI - but not sure- I see stuff changing when using the scan command when I hit the reset button on my board under test however this could just be random bits? Renesas forums imply that if there is no BSDL supplied in the docs it doesn't support it. So, not sure?

For reference, my desired outcome is either jmp'ing the cpu to a memory location or reading/writing flash, as a fuckup with u-boot has resulted in every command in u-boot returning "Unknown command - try 'help'"

[xssfox]

(alternatively reading or writing NOR flash directly or indirectly would work as well)

[xssfox]

Also willing to put down $400 AUD to help with time or hardware to make an opensource solution to debug these devices