Sensitive matter etc, but, is there a linux alternative to openocd ?
I’ve been trying to keep up to date with the svn, and updating regularly etc, I even found and posted changes but really, it’s just not stable enough, and it’s not getting any better (on the contrary) at least for Stellaris.
I feel lucky when the flash works, and thats OK when it’s only my desk but now I must start thinking about production and I need something that is a bit more predictable…
Yes, use Crossworks from Rowley + one JTAGkey from Amontec !
Laurent
Well, I don’t want to buy a new compiler, I just want a reasonably reliable jtag flasher…
I already have JTAGKeys
I normally use a CrossConnect with ARMs and CrossWorks, but I just tried a JTAGkey-tiny (I got it for use with XMOS chips) and it worked fine with an LPC2103. I did have to reduce the JTAG clock speed to get it to work - have you tried that?
Leon
Could you explain what does not work - use openocd on a daily basis without problems - this includes luminary devices.
Cheers
Spen
where to start ?
starting openocd works only one in about 4 times. The other times it returns various, different errors…
then, ‘halt’ rarely actualy halts the cpu(s)
therefore ‘flash write_image erase’ doesn’t work in that case
but even if it’s halted, you get about 1 chance in 3 for the flash to complete anyway (error 0904 or something) – trying again /usualy/ works.
I won’t mention the debug, since ‘printf’ is a hell of a lot faster than trying to get anything working there.
And yes I tried changing jtag speed, I tried several jtagkeys, and several hosts. It’s consistent. It’s also consistent on all the various stellaris demo kits and on my own custom hardware.
I’m going to try again on a fresh svn and see if it makes a difference…
Other shell:% telnet localhost 4444
Trying 127.0.0.1…
Connected to localhost.
Escape character is ‘^]’.
Open On-Chip Debugger
targets
CmdName Type Endian ChainPos State
0: target0 cortex_m3 little 0 unknown
1: target1 cortex_m3 little 1 unknown
halt
target was in unknown state when halt was requested
flash write_image erase target_comms/gcc/target_comms.bin 0x800
auto erase enabled
Algorithm flash write 2048 words to 0x800, 7699 remaining
timed out while waiting for target halted
error executing stellaris flash write algorithm
flash writing failed with CRIS: 0x0
error writing to flash at address 0x00000000 at offset 0x00000800 (-902)
Runtime error, file “?”, line 1:
In procedure ‘flash’ called at file “command.c”, line 445
In procedure ‘unknown’ called at file “?”, line 1
flash write_image erase target_comms/gcc/target_comms.bin 0x800
auto erase enabled
Algorithm flash write 2048 words to 0x800, 7699 remaining
Algorithm flash write 2048 words to 0x2800, 5651 remaining
Algorithm flash write 2048 words to 0x4800, 3603 remaining
Algorithm flash write 1555 words to 0x6800, 1555 remaining
wrote 30796 byte from file target_comms/gcc/target_comms.bin in 4.736969s (6.348832 kb/s)
targets 1
Connection closed by foreign host.
zsh: segmentation fault sudo openocd -f catbells.cfg
Narowed it down a bit more. Seems that the top of the tree no longer likes to have 2 targets. I had fixed a similar problem a few months ago:
% sudo openocd -f catbells.cfg
Open On-Chip Debugger 1.0 (2008-11-26-09:47) svn:exported
BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS
$URL$
jtag_speed: 10
Info: JTAG device found: 0x3ba00477 (Manufacturer: 0x23b, Part: 0xba00, Version: 0x3)
Info: JTAG device found: 0x3ba00477 (Manufacturer: 0x23b, Part: 0xba00, Version: 0x3)
Warning:no telnet port specified, using default port 4444
Warning:no gdb port specified, using default port 3333
Warning:no tcl port specified, using default port 6666
Info: accepting ‘telnet’ connection from 0
% telnet localhost 4444
Trying 127.0.0.1…
Connected to localhost.
Escape character is ‘^]’.
Open On-Chip Debugger
targets 1
Connection closed by foreign host.
zsh: segmentation fault sudo openocd -f catbells.cfg
i have just committed a patch to fix that segfault - somehow it crept in with all the new scripting stuff.
a full debug log would be good aswell. The only multiple targets i have are different cores.
an issue will arise with two cores the same for flash programming using the write_image cmd.
As write_image scans the configured banks depending on the image address - you will have two the same and the first target found will always win.
The only safe way to write both devices would be to use flash write_bank
Cheers
Spen
Thanks for the fix, it now works. The ‘startup’ of openocd seems more stable so far, but the ‘flash fail, flash works’ still happend.
flash write_image is handy because it does the auto-erase. Also, it works for multiple flash banks by setting the target accordingly
targets 0
flash write_image erase file offset ← will targets device #0
targets 1
flash write_image erase file offset ← will targets device #1
sorry i forgot you could do that now.
I have just committed a bugfix to the luminary flash driver - todo with tail bytes.
I am still interested in solving your issues - any details you can give would be good.
Cheers
Spen
BTW, I did a fresh checkout and tried again. Basicaly, the flash ‘failing’ on the first attempt still does it as before, nothing new here.
However I noticed that my config file had to be rewritten completely, again.
Openocd now carry yet another layer of bloat, a web server ! wonderful
I also tried it on a run of the mill sam7s board, and now I have to unplug/replug my jtagkey between instances of openocd.
Is it time to fork the project and restore it to lean, mean and crude (and working!) ?
We have had no other reports of this sort of issue so perhaps it is related to the setup you have.
Openocd is evolving, this is because of the number of people giving up their spare time to add new features etc. If you have suggestion perhaps you could get involved too - the openocd dev mailing list is the best place to start.
https://lists.berlios.de/mailman/listin … evelopment
Cheers
Spen