stm32x mass_erase 0
flash write_image $filename
jtag_khz 1000
reset run
shutdown
}
init
$ openocd.exe -f "openocd.cfg" -c "flash_image debug/main.elf"
best regards,
--
Thomas Kindler
___
Openocd-developmen
David Brownell wrote:
> On Monday 11 January 2010, Thomas Kindler wrote:
>> Joseph Yiu suggested this code to cause a hard-fault:
>>
>>__asm(
>> "movs r0, #1 \t\n" // unaligned ..
>> "ldm r0, {r1-r2} \t\n"
David Brownell wrote:
> On Monday 11 January 2010, Thomas Kindler wrote:
>>> To clarify: it behaves fine after adding that line,
>>> no wierdness?
>> Not really - I still have to do one additional system reset using the
>> push-button. But it's way be
Hi Freddie!
Freddie Chopin wrote:
> I've got snapshots of 0.4.0-rc1-dev compiled for 64-bit Windows systems,
> but I cannot test that (I use 32-bit Windows). I can produce releases of
> 64-bit versions (just like the "regular" releases on my website), but
> I'd like to test the executable, driv
David Brownell wrote:
> On Monday 11 January 2010, Thomas Kindler wrote:
>>> To clarify: it behaves fine after adding that line,
>>> no wierdness?
>> Not really - I still have to do one additional system reset using the
>> push-button. But it's way be
David Brownell wrote:
>>> If that's part of the issue, you might be able to
>>> work around it by updating DEMCR before shutting
>>> down. "cortex_m3 vector_catch none" maybe.
>> Well, it helps a bit. Adding "CoreDebug->DEMCR = 0;" to the start of my
>> program does the same.
>
> To clarify: it
David Brownell wrote:
> On Monday 11 January 2010, Thomas Kindler wrote:
>> How could this be fixed or explained?
>
> There's some curious voodoo in the Cortex-M3 code
> where it mucks with fault handling ... see in the
> cortex_m3_endreset_event() routine where it set
. The chip just won't
execute hard-faults until the next power-cycle.
How could this be fixed or explained?
Best regards,
Thomas Kindler
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Carsten Breuer wrote:
> Hi all,
>
Hi!
> after finding out, that malloc come back with NULL
> even on linux (where people says here, it don't),
It does, but it's a tricky topic. Please post your test program!
I've tried this one on Ubuntu 9.10 in VirtualBox:
#include
#include
#include
Carsten Breuer wrote:
>> Perhaps we should use something like:
>>
>> void *allocate_or_exit(size);
>
> I would also make some defines in types.h:
>
> #define malloc YOU_SHOULD_NEVER_EVER_USE_MALLOC
> #define calloc YOU_SHOULD_NEVER_EVER_USE_CALLOC
>
> With this, developers can't use malloc
> acc
Carsten Breuer wrote:
> Hi Thomas, hi all
>
>
>> On a normal, modern operating system, (reasonably sized) mallocs should
>> never fail, as the system will start thrashing and killing off processes
>> long before malloc() fails.
>
> Well, try:
>
> for (int idx = 0; idx < 255; idx++)
> {
> v
Carsten Breuer wrote:
> Is there any windows client that you can suggest?
> Something like TortoiseGIT?
Sure. TortoiseGit.
;)
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-dev
different story for the Zy1000, of course..)
best regards,
--
Thomas Kindler
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
uot;Getting
OpenOCD"-Topic still mentions SVN (and seems to be redundant, as there's
also a "Repository" topic).
Perhaps, it would be best to put the website in git, too?! It's getting
outdated so easily!
best regards,
--
Thomas Kindler
___
you try to remove (or comment out) the "reset_config" line in your
target/stm32.cfg?! That should fix your problem.
This is related to the double-reset problem I reported some time ago.
See my mail from 9.11.2009, and accompanying patc
Freddie Chopin wrote:
> Thomas Kindler pisze:
>> Hi!
>>
>> When single stepping on a STM32, I'm constantly caught in interrupt
>> handler code. This makes debugging almost impossible for non-trivial
>> programs with timer and other peripheral interru
-enable interrupts on run?
best regards,
--
Thomas Kindler
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Thomas Kindler wrote:
> David Brownell wrote:
>>> Perhaps we shouldn't link to ftd2xx.lib at all. Instead, OpenOCD could
>>> use LoadLibrary and GetProcAddress calls to load the .dll at runtime.
>>>
>>> Wouldn't this also solve the GPL problem?
Hi!
Now that the reset problem is solved for me, I'm trying to optimize my
eclipse setup for my STM32 target.
Basically, I'm using gnuarmeclipse.sf.net for project settings and
makefile generation, CodeSourcery Lite as the toolchain, and the
"Eclipse C/C++ GDB Hardware Debugging" Plug-In from
Hi!
As discussed, here's a patch for the double-reset problem on STM32.
I've tested downloading and debugging with GDB and Eclipse, and
everything seems to work fine.
This effectively sets reset_config to none. tsrt_only would also be ok,
but that's better left to a board configuration file.
David Brownell wrote:
>> Back to your question: I tried all of the four signal options, and
>> /basically/ all of them work. I can attach log files if needed.
>>
>> "none" and "trst_only" seem to be the best options -- only one reset,
>> or reset-and-immediate-halt, as expected.
>
> Said differen
David Brownell wrote:
>> Perhaps we shouldn't link to ftd2xx.lib at all. Instead, OpenOCD could
>> use LoadLibrary and GetProcAddress calls to load the .dll at runtime.
>>
>> Wouldn't this also solve the GPL problem?!
>
> No it wouldn't. We've been over that before.
>
Has the LoadLibrary/GetPr
David Brownell wrote:
>> Even "reset halt" will let the CPU run for some amount of time
>> (e.g. enough to print a Hello-World string to the serial port..).
>
> Now *that* is a bug. And one that I suspect is specific to STM32, or
> at least to your particular chip, since I've not observed it on
Using an Amontec JTAGkey-Tiny and STM32 (on cygwin), every time I do an
"reset", the chip actually resets twice.
The problem exists since I first used OpenOCD (< 0.1.0).
Even "reset halt" will let the CPU run for some amount of time (e.g.
enough to print a Hello-World string to the serial port
simon qian wrote:
> Try attached patch.
Works for me!
btw: the current git-master still has the problem.
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
David Brownell wrote:
> On Sunday 08 November 2009, Thomas Kindler wrote:
>> After three hours of fiddling around, I found out, that the windows
>> drivers have to be _installed_ on the system - The script will fail on a
>> system that hasn't seen the dongle. O
Hi!
I'm building binaries for ftd2xx from git using cygwin (w/o MinGW, so
it's not a cross-platform build). Everything worked fine on my main
computer, but on my notebook the configure script fails with
Cannot build & run test program using ftd2xx.lib
Without any additional debugging out
ust have to have an install.exe right on the official OpenOCD project
page.
If more people had tried the RCs, the problem might have shown up before
the release.
--
Thomas Kindler
___
Openocd-development mailing list
Openocd-development@lists.berlios.
td2xx.lib" to "i386/libftd2xx.a"
> and now the build and configure process is working.
How strange. I didn't rename my library, but could link just fine.
Could you try to run configure without 'CC="gcc -mno-cygwin"'?
Or perhaps there's a probl
n you try to copy the ftd2xx.dll to the openocd or windows system
directory?!
--
Thomas Kindler
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
happy weekend,
--
Thomas Kindler
Index: src/jtag/rlink/rlink.c
===
--- src/jtag/rlink/rlink.c (revision 1454)
+++ src/jtag/rlink/rlink.c (working copy)
@@ -523,7 +523,7 @@
/* Wait for DTC to finish running
;t that break support for smaller
CPUs with 10k or 6k of memory?
Greetings from Germany!
--
Thomas Kindler
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Spencer Oliver wrote:
>> I'm using a JTAGkey-Tiny to program my STM32F103VBT6 CPU, but
>> the flash performance seems to be _very_ low.. (around 6 kb/s).
> The write time will include the erase, this can be speeded up by using the
> mass erase, eg.
> stm32x mass_erase 0
> flash write_image $filen
Hi!
I'm using a JTAGkey-Tiny to program my STM32F103VBT6 CPU, but the flash
performance seems to be _very_ low.. (around 6 kb/s).
I already tried to enable the PLL and setting jtag_khz to 6000 (which
works), but it doesn't get any faster. Here's my openocd.cfg:
source [find board/stm32f10x_1
34 matches
Mail list logo
