On Sun, Jun 2, 2013 at 3:07 PM, Jörg Fischer <tur...@gmx.de> wrote:
> Hi,
> Am 02.06.2013 06:57, schrieb Stuart Longland (VK4MSL):
> > I'm just trying to debug a problem that has cropped up out of the blue.
> > I have a couple of STM32F103VE-based microcontrollers which I'm
> > programming using a Olimex ARM-USB-TINY-H JTAG programmer.
> >
> > Host environment is Open On-Chip Debugger 0.7.0-dev-00080-g59c051c-dirty
> > (2013-01-25-19:17), from the Gentoo ebuild.
> >
> > I'm invoking openocd with the following:
> >> openocd -f interface/olimex-arm-usb-tiny-h.cfg -f target/stm32f1x.cfg
>
It probably won't help with your problem, but my standard reply to people
who are still using the old, flawed "ft2232" adapter driver is to suggest
to switch to the new "ftdi" driver instead. Assuming that OpenOCD was built
with --enable-ftdi, it should be a simple matter of using the similarly
named interface config file from the ftdi subfolder instead, i.e openocd -f
interface/ftdi/olimex-arm-usb-tiny-h.cfg ... in your case.
> >
> > which up until now has worked fine, I've been able to telnet in to port
> > 4444, and flash my devices, even hook up gdb. I was doing some
> > debugging today, no problems flashing the devices until suddenly, it
> > stopped halting the device. No configuration files had been changed.
>
> Do you use Sleep or low power modes? Did you mess with the clock?
Usually, it won't even find the TAPs if the core is in low power mode.
> >> in procedure 'reset'
> >
> > Turning up debugging I get:
> > [..skipped..]
> >> Debug: 398 74782 cortex_m.c:974 cortex_m3_assert_reset():
> target->state: reset
> >> Debug: 399 74788 cortex_m.c:1065 cortex_m3_assert_reset(): Using
> Cortex-M3 SYSRESETREQ
> >> Debug: 400 74790 cortex_m.c:597 cortex_m3_halt(): target->state: reset
> >> [...]
> >
> > Is there any way, using openocd, to determine if it's something wrong
> > with the targets (all three seem to have failed, and all were working
> > earlier), or if the JTAG device has failed?
>
> Have you connected the SRST line? Then you could try:
> "reset_config srst_only separate"
>
I agree that it sounds like an SRST problem. I know that some versions of
the Olimex dongles suffers from a design fault causing the reset line to be
pulled down slightly (or even clamped) even when not asserted. On an STM32
this typically causes the level on the pin to be below the guaranteed high
level. Depending on a lot of factors (processor batch, temperature, Vdd
level, ...) this could be interpreted as an asserted reset or not. If the
reset pin is not properly released, you'll get symptoms like you describe.
Measure the SRST voltage and make sure it's at Vdd level. Also check any
other circuitry you may have connected to the SRST pin. If you find a
problem with the dongle, you may simply disconnect the reset line since in
many cases you can manage without it (and the default is to not use it
anyway).
> Using a low JTAG clock might also be helpful:
> "adapter_khz 10"
>
Unless there are electrical problems, the STM32 will reliably start up with
1 MHz since it defaults to the 8 MHz RC at reset.
/Andreas
------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
_______________________________________________
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel
