On Monday 25 May 2009, Nicolas Pitre wrote:
> On Sat, 23 May 2009, David Brownell wrote:
>
> > I see messages about needing to increase some GDB timeout/interval. But
> > that's foolishness, since I'm not even working with GDB when they start
> > spamming me.
>
> This is indeed really irritating
On Sat, 23 May 2009, David Brownell wrote:
> I see messages about needing to increase some GDB timeout/interval. But
> that's foolishness, since I'm not even working with GDB when they start
> spamming me.
This is indeed really irritating.
What about those messages being displayed only when a g
On Sat, May 23, 2009 at 8:49 AM, Dylan Reid wrote:
> static int jlink_get_version_info(void)
>
> The crazy thing is that sometimes this works. Often enough to be
> usable actually. I added a check to jlink_usb_read and it makes it
> fail every time. I attached the patch as I think it is the rig
I´ll try out the trunk when I get back into the office. Here is the
patch that I forgot to attach. I think regardless of whether the
trunk works this patch is a good idea just to be safe.
On Sun, May 24, 2009 at 12:29 AM, Zach Welch wrote:
> On Sat, 2009-05-23 at 21:06 -0700, David Brownell w
On Sat, 2009-05-23 at 21:06 -0700, David Brownell wrote:
> On Saturday 23 May 2009, Zach Welch wrote:
> >
> > > Considering that USB bulk transfers are "best effort" and might easily
> > > be delayed by concurrent activity to a USB disk or webcam ... a single
> > > second seems absurdly short. Ev
On Saturday 23 May 2009, Zach Welch wrote:
>
> > Considering that USB bulk transfers are "best effort" and might easily
> > be delayed by concurrent activity to a USB disk or webcam ... a single
> > second seems absurdly short. Even if the device were guaranteed to be
> > able to respond that qui
On Sat, 2009-05-23 at 03:57 -0700, David Brownell wrote:
> > >> I am also thinking that the USB timeout value may be extended a bit
> > >> longer.
> > >> Right now it is 1000ms. Should be ok. But may not be ok for people
> > >> using VM or similar.
> > >
> > > The problem with this is that it slo
On Fri, 2009-05-22 at 17:59 -0400, Dylan Reid wrote:
> I am just updated to svn 1881 to use with my STM32 and jlink(yellow
> v6.0). I had been using 1183, which worked every time, but was
> unbearably slow. Revision 1881 is lightning fast compared with the
> old revision. I am however seeing a f
On Sat, May 23, 2009 at 6:57 PM, David Brownell wrote:
>> >> I am also thinking that the USB timeout value may be extended a bit
>> >> longer.
>> >> Right now it is 1000ms. Should be ok. But may not be ok for people
>> >> using VM or similar.
>> >
>> > The problem with this is that it slows down
> >> I am also thinking that the USB timeout value may be extended a bit longer.
> >> Right now it is 1000ms. Should be ok. But may not be ok for people
> >> using VM or similar.
> >
> > The problem with this is that it slows down the failure process when
> > something is actually broken. I think
On Sat, May 23, 2009 at 10:14 AM, Zach Welch wrote:
> On Sat, 2009-05-23 at 09:54 +0800, Xiaofan Chen wrote:
> [snip]
>> I am also thinking that the USB timeout value may be extended a bit longer.
>> Right now it is 1000ms. Should be ok. But may not be ok for people
>> using VM or similar.
>
> The
On Sat, 2009-05-23 at 09:54 +0800, Xiaofan Chen wrote:
[snip]
> I am also thinking that the USB timeout value may be extended a bit longer.
> Right now it is 1000ms. Should be ok. But may not be ok for people
> using VM or similar.
The problem with this is that it slows down the failure process wh
On Sat, May 23, 2009 at 8:49 AM, Dylan Reid wrote:
> Something strikes me as pretty broken here. Maybe I am seeing ghosts.
>
> I put in a few prints to see what was going on, then got confused and
> ran from the debugger. This is what I found:
>
>
> static int jlink_get_version_info(void)
> {
>
On Sat, May 23, 2009 at 5:59 AM, Dylan Reid wrote:
> $ sudo /usr/local/gnu-arm/bin/openocd -f
> ../GNUTools/openOCD/newLPM.cfg -c init -c "sleep 200" -f
> flashAll.script -c "reset run" -c "shutdown"
> Open On-Chip Debugger 0.2.0-in-development (2009-05-22-09:47) svn:1881
>
>
> BUGS? Read http://s
Something strikes me as pretty broken here. Maybe I am seeing ghosts.
I put in a few prints to see what was going on, then got confused and
ran from the debugger. This is what I found:
static int jlink_get_version_info(void)
{
int result;
int len;
u32 jlink_caps, jlink_max
Try this again to the whole list.
Here is the trace. I'm taking a quick look at it right now. I am
guessing that having jlink_jtag_handle = 0 is the problem, just trying
to figure out how that happened.
Dylan
(gdb) run -f ../GNUTools/openOCD/newLPM.cfg -c init -c "sleep 200" -f
flashAll.script
For the segfault, can you run it under gdb and get a backtrace?
Rick
On May 22, 2009, at 2:59 PM, Dylan Reid wrote:
I am just updated to svn 1881 to use with my STM32 and jlink(yellow
v6.0). I had been using 1183, which worked every time, but was
unbearably slow. Revision 1881 is lightning
I am just updated to svn 1881 to use with my STM32 and jlink(yellow
v6.0). I had been using 1183, which worked every time, but was
unbearably slow. Revision 1881 is lightning fast compared with the
old revision. I am however seeing a few issues.
It takes 5 or six tries to get my program to down
18 matches
Mail list logo
