This is what valgrind reports:
SIR 6 TDI (02) ;
RUNTEST 10 TCK;
Error: SVF: can not move to RUN/IDLE
valgrind: m_mallocfree.c:225 (mk_plain_bszB): Assertion 'bszB != 0' failed.
valgrind: This is probably caused by your program erroneously writing past the
end of a heap block and corrupting heap
On Mon, Mar 28, 2011 at 12:14 AM, Andrew Leech wrote:
> On Mon, Mar 28, 2011 at 8:28 AM, Øyvind Harboe
> wrote:
>> I tried this with a big enough buffer on a real device and it
>> segfaulted.
>>
>
> Wasn't most/all of the required code for dynamic buffer resizing
> already present in the code bu
On Mon, Mar 28, 2011 at 8:28 AM, Øyvind Harboe wrote:
> I tried this with a big enough buffer on a real device and it
> segfaulted.
>
Wasn't most/all of the required code for dynamic buffer resizing
already present in the code but commented out with #if 0 #else #end
lines? It sounds like this mig
Hmm, this looks like a case of WOMM, because given we are both testing
against the same file (the one you attached), and are both using the
git master, we should both/neither get this crash.
Looks like one of the buffers is becoming corrupt somehow, yet they are
all malloc'ing correctly.
Given it
This is the crash I see:
gdb --args openocd -c "interface dummy" -c init -c "svf nil foo.svf"
...
Error: tdo check error at line 33
Error: read = 0x0, want = 0xF2618093, mask = 0xFFF
Error: fail to run command at line 4799
Error: tdo check error at line 33
Error: read = 0x0, want = 0xF2618093
Please submit a patch:
cd openocd
git add .
git commit --author="Olivier Schonken "
git format-patch HEAD^
Thanks!
--
Øyvind Harboe
Can Zylin Consulting help on your project?
US toll free 1-866-980-3434 / International +47 51 87 40 27
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScal
I tried this with a big enough buffer on a real device and it
segfaulted.
--
Øyvind Harboe
Can Zylin Consulting help on your project?
US toll free 1-866-980-3434 / International +47 51 87 40 27
http://www.zylin.com/zy1000.html
ARM7 ARM9 ARM11 XScale Cortex
JTAG debugger and flash programmer
Your svf file does fail with my patch. I had to increase it from 8x the
normal buffer size to 32x the normal buffer size, before it stopped
reporting buffer-to-small errors.
Then I simply get the:
Error: tdo check error at line 33
Error: read = 0x0, want = 0xF2618093, mask = 0xFFF
Error: fail
I am using openOCD with production version of SAM3, I have found that
openocd does not recognize the cidr because of the increase in version
number. The easy fix is the following (also shown in the code below)...
Do an AND operation on cidr and 0xFFE0 to make comparison succeed when
device i
Noted with Xilinx svf files, (once my other patch is applied to let it
read the whole line), programming is _very_ slow.
I have adjusted usb_blaster.c to allow it to send a larger buffer all at
once when written (see attached patch), but this is not the main issue.
(Only tested with a CY7C68013A b
Hmm, well I can report that that patch alone let me successfully program
my FPGA.
> https://lists.berlios.de/pipermail/openocd-development/2011-February/018217.html
I am unable to download the attachment here, tar reports it isn't an
archive, so not sure what changes were made to try to emulate a
Hi Ali,
the buffer size is only part of what ails the svf parser for Xilinx.
Even increasing the buffer size can make it crash. If you'd like to
have a look at the problem, you can try this:
https://lists.berlios.de/pipermail/openocd-development/2011-February/018217.html
--
Øyvind Harboe
Can
12 matches
Mail list logo
