Hi Jörg and Andreas,
On 03/06/13 08:33, Andreas Fritiofson wrote:
> On Sun, Jun 2, 2013 at 3:07 PM, Jörg Fischer <tur...@gmx.de
> <mailto: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.

Is that using the proprietary library from FTDI themselves or is there
another one I missed?  I'll use proprietary stuff if I have to, but I'd
really like to avoid it where possible as the other driver has worked
fine up until now.

>     >
>     > 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.

No sleep modes at this point.  I might consider setting something up
later but to my knowledge, there is no low power mode being invoked at
this time.

>     >> 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).

Ahh okay, so possibly environment related.  I wasn't aware of the design
fault on the Olimex dongles.  I'll make a note to check this next
weekend when I'm tinkering with the device.

For the record, the device I'm programming is one of these:
http://www.cutedigi.com/development-tools/arm-cortex-development-board/arm-cortex-m3-mini-stm32-dev-board-2-4-tft-lcd-touchscreen.html

I'll have a look at the schematic later and see if SRST is connected.

>     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.

I've been leaving at the defaults so far.  As I say, it has been working
rather well.  After a little tweaking when I first got the dongle,
things seemed to just work.  Just that it stopped working out of the blue.

OpenOCD has been a great asset, and I do appreciate your efforts in its
maintenance and support.

I'll investigate this weekend and see where I get.
-- 
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
  ...it's backed up on a tape somewhere.

------------------------------------------------------------------------------
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

Reply via email to