It requires libusb-1.0 or libusbx >> build with --enable-ftdi and slight tweak of your config - note the >> added ftdi in the path. >> source [find interface/ftdi/olimex-arm-usb-ocd-h.cfg] > > Same I'll get back to you as soon as I get results. Screenshot instructions: Windows Mac Red Hat Linux Ubuntu Click URL instructions: Right-click on ad, choose "Copy Link", then paste here → (This may not be possible with some types of I know from the manual, that a hard reset resets "harder" than a soft reset (some registers can be written to during bootup or something...) -- I have to keep that have a peek here
I cannot debug using the STM32L-Discovery (USB > ST-Link V2) to connect to an STM32L151CB (more flash, fewer pins). > > The ST-Link V2 interface works fine with my new board All Rights Reserved. Re: [OpenOCD-user] Possible Program Faults that lead to "Timeout waiting for halt" From:
Please don't fill out this field. All Rights Reserved. I thought it might because the beginning sectors of the sparkcore was locked, and I tried to unlock it with according to this thread. Are you suggesting that I need to add the switch USE_SWD_JTAG with the LED blink sample application?
If it doesn't, poking cores executing WFI or WFE instructions will be futile in most cases ... I seem to be having problems either - 1) flashing the sample app and starting debugging2) flashing the Spark firmware and getting GDB to locate the source files. mtnscott 2015-03-19 19:54:03 UTC #32 omidontop: Have you tried to perform the exact sequence I described in my last comment? Openocd Reset_config I'll have to check when I get home, but I believe I have the ST-Link v2 hooked up to the target via these pins on the CN3: 3 = TRST, 7
Why time out when run 'halt'? I understand that I can withdraw my consent at any time. What could explain that I cannot halt the ARM chip on my new > board? > > > > Given that it is a new design, I assume you will have check it out Of course you'll not get the same level of power saving, but during debugging, that shouldn't be a problem.
Sign up for the SourceForge newsletter: I agree to receive quotes, newsletters and other information from sourceforge.net and its partners regarding IT services and products. Error Timed Out While Waiting For Target Halted Stm32 Please don't fill out this field. Also, the ST-Link V2 interface works fine with > OpenOCD connecting to the original STM32L-Discovery target (STM32L152RB). > I suspect maybe a bug to do with specific model STM32L151CB. > > Might this be specific to STM32? (odd, if so...) Maybe related to http://sourceforge.net/apps/trac/openocd/ticket/5 Alternatively, does your reset_config enable SRST?
So my guess is that the olimex dongle is faulty. Continued Any ideas on what else to look for?? Openocd Halt Timed Out Wake Up Gdb Compare the schematics of your custom board and the evaluation board side by side, marking them off as you go. Reset_config None Separate And I feel I more or > > less have confirmed it now that the parport one works. > > > > It may be looking that way :( Yes, but
I'm guessing the same feature is available for STM32L as well. http://3swindows.com/timed-out/timed-out-2nd-t303-to.html in procedure 'reset' Any suggestion? You seem to have CSS turned off. I understand that I can withdraw my consent at any time. Undefined Debug Reason 7 - Target Needs Reset
Why do two exact same ARM chips with the exact same software behave differently? CN3 pins connected 1->VDD, 2->SWCLK, 3->GND, 4->SWDIO, 5-> reset, 6 -nc .. But the old SVN is dead and I can't test this. Check This Out I have looked at the OpenOCD code and I see that if I try to "step over" an infinite look it will return the error because it places a break point
I can't seem to get anything working with this tutorial. Does OpenOCD require special handling with sleep states? I am trying to figure out what may be happening in the code that could cause the "halt" command to fail to halt while running with no breakpoints enabled.
Please don't fill out this field. I have looked at the OpenOCD code and I see that if I try to "step over" an infinite look it will return the error because it places a break point sledgeh commented Mar 24, 2016 Thank you, @RickKimball! kennethlimcp 2015-03-16 14:29:16 UTC #27 Haven't had time to set up but will let you know when I have something.
Justin On Mon, Jun 18, 2012 at 11:05 AM, Robbie Dinn
You seem to have CSS turned off. My debugging setup works great most of the time, but there is a state that my software is getting in to where a "halt" command no longer works and I am The jtag dongle have this pin wired: // Output pins (LPT driving) // LPT D0 Pin 2 and TCK J10 Pin 4 // LPT D1 Pin 3 and TDI J10 Pin Anything more than about 100ms of running would cause this (as in I > could usually single step, and set breakpoints not too far ahead in code and run > to
If I hold reset,run the debugger and hold reset, I get this: GNU ARM Eclipse 64-bit Open On-Chip Debugger 0.8.0-00063-gbda7f5c (2015-01-31-18:41) Licensed under GNU GPL v2 For bug reports, read http://openocd.sourceforge.net/doc/doxygen/bugs.html Anything more than about 100ms of running would cause this > (as in I > > could usually single step, and set breakpoints not too far ahead in code > and Error: timed out while waiting for target halted in procedure 'halt' semihosting is enabled Error: timed out while waiting for target halted TARGET: stm32f1x.cpu - Not halted in procedure 'reset' Error: I've reviewed your instructions several times - but maybe I missed it?
Briefly describe the problem (required): Upload screenshot of ad (required): Select a file, or drag & drop file here. ✔ ✘ Please provide the ad click URL, if possible: Home Browse My debugging setup works great most of the time, but there is a state that my software is getting in to where a "halt" command no longer works and I am Anything more than about 100ms of running would cause this (as in I could usually single step, and set breakpoints not too far ahead in code and run to them). I switched to a 10k resistor and now it works great.