On Thu, May 10, 2012 at 1:51 AM, Xiaofan Chen <[email protected]> wrote:
> On Thu, May 10, 2012 at 5:48 AM, Andreas Fritiofson
> <[email protected]> wrote:
>>> Can you try the attached luminary.cfg to see if you can at
>>> least read the idcode?
>>
>> In any case, it doesn't explain the hanging you mentioned. Did you
>> manage to get a debug log when it hanged?
>
> If I use the latest luminar.cfg, the first run generated the
> segfault, the 2nd run will hang, same hang for later run
>
> If I use the previous luminar.cfg, the first run generated the
> error, the 2nd run will hang, same hang for later run.
>
> After the hang, I can run the git version of openocd to
> get it back to the normal state.
>
>> There are a lot of variables here: OS, libusb version, adapter,
>> target. The following configuration seems to be very stable for me:
>>
>> Ubuntu 10.04
>> Libusb 1.0.6 (in Ubuntu repo)
>
> That is very old libusb and buggy. You may want to
> update to 1.0.9.
>
>> Jtagkey-Tiny, Olimex ARM-USB-OCD and Olimex ARM-USB-OCD-H
>> STM32F100 and STM32F103
>>
>> If you or anyone can test configurations with only one or two
>> differences at a time it would be very helpful to locate the
>> problem(s).
>
> I will test under Linux as well (Ubuntu 12.04).
>
I've now tested at work with the following configuration:
Windows XP (OpenOCD cross-compiled on Ubuntu 12.04 with bundled mingw-w64)
Libusb 1.0.9
Olimex ARM-USB-OCD-H with WinUSB driver installed using Zadig
STM32F103
This works fine with the performance test script I posted earlier. Results:
$ bin/openocd.exe
Open On-Chip Debugger 0.6.0-dev-00550-g38d2298 (2012-05-04-11:51)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
1000 kHz
adapter_nsrst_delay: 100
jtag_ntrst_delay: 100
cortex_m3 reset_config sysresetreq
Info : clock speed 1000 kHz
Info : JTAG tap: stm32f1x.cpu tap/device found: 0x3ba00477 (mfg:
0x23b, part: 0xba00, ver: 0x3)
Info : JTAG tap: stm32f1x.bs tap/device found: 0x16410041 (mfg: 0x020,
part: 0x6410, ver: 0x1)
Info : stm32f1x.cpu: hardware has 6 breakpoints, 4 watchpoints
1000 kHz
Info : JTAG tap: stm32f1x.cpu tap/device found: 0x3ba00477 (mfg:
0x23b, part: 0xba00, ver: 0x3)
Info : JTAG tap: stm32f1x.bs tap/device found: 0x16410041 (mfg: 0x020,
part: 0x6410, ver: 0x1)
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 00000000 pc: 0xd5657ab0 msp: 0xd96c7fa4
8000 kHz
Info : device id = 0x20036410
Info : flash size = 64kbytes
stm32x mass erase complete
wrote 65536 bytes from file test.bin in 1.812535s (35.310 KiB/s)
verified 65536 bytes in 0.171878s (372.357 KiB/s)
dumped 65536 bytes in 0.187504s (341.326 KiB/s)
20480 bytes written at address 0x20000000
downloaded 20480 bytes in 0.046875s (426.667 KiB/s)
shutdown command invoked
I wish I could find a configuration that didn't work.
Regarding the segfault, I think there's a bug somewhere in the
handling of signals that are requested to be tri-stated even though
they are specified as push-pull only. You can try to make sure that
reset_config includes srst_push_pull, because srst isn't open drain in
your eval board. I'll investigate more later.
/Andreas
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
OpenOCD-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openocd-devel
