Reset pin stuck low (OpenOCD)

This site is best viewed in a modern browser with JavaScript enabled.

Reset pin stuck low (OpenOCD)

xyz123

For few days I am trying to debug STMicro based ARMs with openOCD. The issue is that I can not halt the core. The JTAG communication itself is fine.
So finally I looked at the JTAG connector pins. It appears that RESET_N pin gets stuck low. Well, when the power is applied first time it is HIGH. After I connect to the TUMPA with just the following script it goes low and stays low no matter what I do afterwards:
interface ft2232
ft2232_device_desc "TIAO USB Multi-Protocol Adapter"
ft2232_layout jtagkey
ft2232_vid_pid 0x0403 0x8A98
Most likely it is an operator error. However I am running out of ideas what I might be doing wrong.
I am about to start HW debugging. Having TUMPA schematic would be extremely helpful. Is there a way to get one? Unfortunately this link has only layout, no schematic:
http://www.tiaowiki.com/w/TIAO_USB_Multi_Protocol_Adapter_User%27s_Manual
Thanks.

xyz123

Well, did more hardware debugging. Here is what I did with TUMPA connected to the target board:
1. Apply power to the target board. Reset line is high;
2. Apply power to TUMPA. Reset is still high;
3. Press RESET button on target board. reset goes low and stays low even when button is released.
When I do the same with JTAG cable not connected reset line follows the Reset button state (does not get stuck)
It all points to the LVC16T245 buffer (made by TI) on TUMPA board. This chip has so-called bus-hold feature on all IOs. As a result 10K pull-ups on target board is not enough to pull line high once it is low. Most boards have weak pull-ups (from OLIMEX for instance). Hence JTAG will have problems with these boards. Tomorrow I will replace pull-ups with 1K and see if it fixes my problem.
Meanwhile, I am surprised that nobody else reported such an issue. Unless other boards were manufactured with buffers from other manufacturer. Fairchild is the only one that makes it without bus hold.

xyz123

OK, it is not bus-hold. When I disable buffer reset line always returns to VCC.
Is there a way to get a schematic for the board?
Thanks

poya22

jtag section schematic only
http://www.mediafire.com/?clsxcptzgh8b9cz
EDIT by volkan-k on June 29, 2013;

The schematic you have is not the official one, someone reverse-engineered it. It only contains major connections. TUMPA has caps on all power sources, USB pins are ESD protected etc.

xyz123

Thanks!
It all sounds like TUMPA issue. I borrowed J-LINK and using Jlink commander was able successfully halt the core. Reset stayed high. So this is normal operation.
I did verified TUMPA for connections/shorts in the reset area. All seems fine. Pin 21 of FTDI chip stays low all the time regardless of commands issued by the openocd. Now it makes me wonder if pin 21 was not assigned as a reset. Can someone from TIAO guys verify it? This line is microcontroller debugger specific and is not part of the JTAG which has its own reset. This might explain why nobody else saw it.
Is it possible that this issue is somewhat related to no-COM port issue with FTDI chip? Can I use FT_Prog to verify it? Can I backup EEPROM content with FT_Prog? Or any other idea?
Thanks.

poya22

R7 add to schematic
http://www.mediafire.com/?zv158nnx1gv0cy2

xyz123

Thanks, poya22.
Well, it seems that IOs are mapped wrong.
I setup the target as usual and started issuing RESET commands. And probed pin after pin. Pin #27 of FTDI chip would be high but dipped slightly when reset was issued. This pin supposed to be an input to sense TRST. So I lifted pin 32 of the buffer to stop driving pin 27. And now pin 27 goes low each time I issue a reset command. I'm sure other IOs are also connected wrong. So IO connections do not appear to be compatible with OpenOCD.

xyz123

After examining the OpenOCD source code the JtagKey profile drives GPIOHs. TUMPA board has GPIOLs wired for this function. To make the matter worse Amontec's jtagkey provides two independent enables for SRST and TRST. Tumpa does not.
As far as I can see the cleanest way to fix it would be to create new profile and build new openocd.
Has anyone had any luck running TUMPA with openocd to debug ARM micro-controllers?

xyz123

Rebuilt OpenOCD with new TIAO profile and it appears to be working now. At least I can halt the CPU. I just do not understand how TUMPA is advertized as supporting OpenOCD as it is.

[deleted]

xyz123 wrote: Rebuilt OpenOCD with new TIAO profile and it appears to be working now.

Thank you for the feedback. Great to hear that its working. Can you please share the code with the community?

ao2

xyz123 wrote: Rebuilt OpenOCD with new TIAO profile and it appears to be working now. At least I can halt the CPU.

xyz123 will you send a patch with the new profile to OpenOCD, or would you at lest post it here?

I just do not understand how TUMPA is advertized as supporting OpenOCD as it is.

I am not an expert in JTAG but is it possible that the TUMPA was tested just in a flashing scenario with OpenOCD and not in a debug scenario?

xyz123

The patch will be sent to OpenOCD development team. I am more than upset with TUMPA. I do not think TUMPA was tested in debug mode with OpenOCD at all.
Edit:
And warning for OpenOCD users - you might burn the buffer or FT2232H chip. Due to outputs driving each other.

[deleted]

Dear xyz123,
I do NOT work for TIAO Corp. But I'm very sorry for your bad experiences with TUMPA as another TUMPA user/developer.
I am able to publish any patches/config file/custom profile on SourceForge.net for other TUMPA users if you are interested to help other TUMPA users.
You are always welcome to post on this forum / send Private Message to me / e-mail anything to : volkan-k at users.sourceforge.net

[deleted]

Paul Fertser, an OpenOCD user, prepared a new proper config based on schematics for TUMPA. A big thank you goes out to Paul Fertser for his contributions. Sharing here for other TUMPA & OpenOCD users.

Paul Fertser wrote:To try this patch just fetch the specific commit (the link is on the Gerrit's web interface, you do not need to register there to simply download code) and configure with --enable-ftdi , specify "-f interface/ftdi/tumpa.cfg" on the OpenOCD command line.
-- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!

http://sourceforge.net/mailarchive/forum.php?thread_name=20130608153129.CD8DD242BE%40openocd.zylin.com&forum_name=openocd-devel wrote:Subject: : 10cb57c ftdi: config for TUMPA
From: gerrit@openocd.zylin.com
Date: 08.06.2013 18:31
To: openocd-devel@lists.sourceforge.net
This is an automated email from Gerrit.
Paul Fertser (fercerpav@...) just uploaded a new patch set to Gerrit, which you can find at http://openocd.zylin.com/1438
-- gerrit
commit 10cb57c9ecca7069d6474ab7d1be17212fb9dbe9
Author: Paul Fertser <fercerpav@...>
Date: Sat Jun 8 19:15:48 2013 +0400
ftdi: config for TUMPA

Add a config file for TIAO USB Multi-Protocol Adapter.

Based on schematics from http://www.mediafire.com/?zv158nnx1gv0cy2

Cc: Volkan K <volkan-k@...>
Change-Id: I0dfd93b0b1e558e4ccd7c94c005c099947ec94df
Signed-off-by: Paul Fertser <fercerpav@....>
diff --git a/tcl/interface/ftdi/tumpa.cfg b/tcl/interface/ftdi/tumpa.cfg
new file mode 100644
index 0000000..412dd95
--- /dev/null
+++ b/tcl/interface/ftdi/tumpa.cfg
@@ -0,0 +1,15 @@
+#
+# TIAO USB Multi-Protocol Adapter (TUMPA)
+#
+# http://www.diygadget.com/tiao-usb-multi-protocol-adapter-jtag-spi-i2c-serial.html
+#
+
+interface ftdi
+ftdi_device_desc "TIAO USB Multi-Protocol Adapter (TUMPA)"
+ftdi_vid_pid 0x0403 0x8a98
+
+ftdi_layout_init 0x0838 0x087b
+ftdi_layout_signal nTRST -data 0x0020
+ftdi_layout_signal nSRST -data 0x0010
+
+reset_config srst_push_pull
--

irc://chat.freenode.net/openocd wrote:<PaulFertser> Volkan-K: the schematics are really strange btw. SRST handling is imho wrong (only allowing pushpull is an uncool thing to do) and vtarget led is connected in a rather weird fashion, apparently it can be controlled by the host independently but only when that jumper is not connected, else you can end up short-curcuiting the ftdi chip...
<Volkan-K> so it is not same as jtagkey ?
<PaulFertser> Yep, not the same as jtagkey, there're considerable differences. It sort of worked probably because default reset_config is none so many users end up not using srst and trst at all.
<Volkan-K> quoting from xyz123: "warning for OpenOCD users - you might burn the buffer or FT2232H chip. Due to outputs driving each other."
<PaulFertser> Hopefully with my config that's not possible.
<PaulFertser>
<Volkan-K> what is push-pull
<PaulFertser> It's when you have a pin either pulling to Vcc or to GND strongly.
<PaulFertser> Usually srst is done in an open drain way to allow coexistance of multiple independent reset sources (that would override a weak pullup).
<PaulFertser> It's like a push-button (open drain) vs switch (push-pull)
<PaulFertser> Some boards have a hardware reset button. So if your adapter has push-pull srst and you push that button, bang, buffer's strong output is shorted to ground (by the button).
<PaulFertser> Other boards have additional external power supervisor that can pull reset low to avoid damaging flash when a board is under-volted.