Am 22.07.2011 15:10, schrieb Tomek CEDRO:
On Fri, Jul 22, 2011 at 9:59 AM, Peter Horn wrote:
Besides the RLink I also have an Olimex ARM-USB-OCD adpater. On Windows,
stepping with the Olimex is considerably faster than with the RLink. On
Linux both adapters are on par. I'm Using the same
Am 22.07.2011 20:02, schrieb Andreas Fritiofson:
Your RLink reports the same firmware version as my STM32Primer does. If
that means they are identical, I should be able to reproduce, but I
can't. Maybe it depends on the version of libusb?
I'm using OpenSuse 11.4. Here's what the package manager
Am 22.07.2011 13:36, schrieb Andreas Fritiofson:
I don't see how this error could be caused by my patches. If I'm not
mistaken, none of them have run at this point. It fails during init, and
that code is unchanged with the exception of some indentation fixes and
AFAICT they're OK.
Can you rever
Am 22.07.2011 11:42, schrieb Andreas Fritiofson:
Stepping is still slow on Windows.
Stepping speed is not affected much by these patches since it depends
largely on latency, not throughput. These patches fixes a throughput
problem. Cortex-M3 stepping is really dependent on latency because,
Am 19.07.2011 22:43, schrieb Peter Horn:
Hi Andreas
I have access to a standalone Rlink, an Olimex STM32-P103 board and
a Raisonance REva STM32 connectivity board which has an onboard
Rlink.
I've applied your patches and built OpenOCD on Linux with success. A
quick test revealed no pro
Hi Andreas
I have access to a standalone Rlink, an Olimex STM32-P103 board and a
Raisonance REva STM32 connectivity board which has an onboard Rlink.
I've applied your patches and built OpenOCD on Linux with success. A
quick test revealed no problems but the test program I've used is too
sma
Am 24.06.2011 21:52, schrieb Spencer Oliver:
On Jun 24, 2011 10:32 AM, "Øyvind Harboe" mailto:oyvind.har...@zylin.com>> wrote:
>
> Anyone have any objections against this patch?
>
> Did anyone else but Andreas Fritiofson review it in detail?
>
I am back at work next week and would like to
Dear Andreas
Am 18.06.2011 20:29, schrieb Andreas Fritiofson:
I guess there's no way around requiring setting a breakpoint at the
current pc to force any pending isr to run?
That's the only way I've found. On the other hand, GDB also sets a
breakpoint when using the 'continue' target command
ys in the background without disturbing the flow of
debugging. No gdb hooks are required.
The 'auto' option is the default, since it's believed that handling
interrupts in this way is suitable for most users.
The principle used for interrupt handling could probably be used fo
