Re: [Openocd-development] Can't halt Calao USB A9263 with OpenOCD 0.5.0
1. Try changing the speed of JTAG to be 1/8th of core speed. 2. Try doing reset halt from the telnet first. 3. Make sure your board has the same reset configuration as you pass to OpenOCD - separate lines of TRST and SRST. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Can't halt Calao USB A9263 with OpenOCD 0.5.0
W dniu 2011-11-03 11:08:39 użytkownik Thomas Petazzoni thomas.petazz...@free-electrons.com napisał: You may also try reset_config srst_pulls_trst or other configurations... Not better, unfortunately. Still the exact same behaviour. Here is my interface file: none srst_pulls_trst trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain Notice that first you set srst_pulls_trst and then another config file sets that back to separate. Try adding the command to openocd call: openocd -f ... -c reset_config trst_and_srst srst_pulls_trst 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Can't halt Calao USB A9263 with OpenOCD 0.5.0
); Sorry, no more ideas from my side... Maybe someone else will be able to help you. Generally the code you are running on the chip can be somehow blocking JTAG access so, if you can, try halting chip with empty flash. I think (I'm not sure) that issuing poll command from telnet performs the check of communication... Please provide a debug log (run OpenOCD with -d 3 option) - maybe there is something interesting... 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Command-line paths problem in Windows
W dniu 2011-10-21 00:12:52 użytkownik Andrew Leech coronasen...@gmail.com napisał: Have you tried with double backslash \\ ? Actually no, I guess that it would probably work but you'd still have to give path to OpenOCD working directory in Eclipse and probably still use ..\\ before directory with config file. Anyway - it worked in some way before, it's said in the manual to use it that way (-f target/sth.cfg) so I guess that it would be best to restore previous - very convenient - behavior. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Command-line paths problem in Windows
W dniu 2011-10-21 13:06:05 użytkownik Spencer Oliver s...@spen-soft.co.uk napisał: i cannot reproduce this problem, any more details. We'll... I've compiled master from yesterday, using the same tools and libraries (libusb and libftdi) as before, using the same script as before - generally nothing changed from my point of view but I cannot run OpenOCD as before - using -f target/whatever.cfg produces an error as in first post. I've checked on another PC now and it's the same: Runtime Error: embedded:startup.tcl:58: couldn't read file D:openocd-0.6.0-dev- 11102001452in../interface/jtagkey.cfg: No such file or directory The root cause is that backslashes from path are removed, so D:\openocd-0.6.0-dev-11102001452\ becomes D:openocd-0.6.0-dev-11102001452 which is worthless. Maybe there were some changes in jimtcl lately? As I said - 0.5.0 compiled 2 months ago works fine. Is there any way I could see which version of jimtcl OpenOCD uses and somehow force it to use some other to see whether that's a problem of OpenOCD or jimtcl? 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Command-line paths problem in Windows
W dniu 2011-10-21 13:50:26 użytkownik Spencer Oliver s...@spen-soft.co.uk napisał: you could either do a git bisect to see what version it broke at. Will bisecting also affect jimtcl version used as a submodule or maybe always the most recent one is used? Generally I see some changes that could affect path handling so I'll give it a try in the afternoon. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Only every second programming works
W dniu 2011-10-19 14:14:11 użytkownik Akos Vandra axo...@gmail.com napisał: #lpcfixchecksum takes only binary files, so #make a binary file from the elf, and fix the checksum. arm-eabi-objcopy -O binary $FILE tmp.bin lpcfixchecksum tmp.bin On LPC2xxx you can use elf, hex of bin - no need to convert anything. -c reset run -c mwb 0x400FC040 0x01 How do you expect to write anything to memory when chip is running? 99% of problems in OpenOCD are solved by using reset halt only. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Last call before release
W dniu 2011-08-03 04:01:32 użytkownik Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com napisał: I'm going to create the 0.5.0 release Won't there be any final RC released as a tarball? 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] libswd drivers question
You can have weak symbols with stub implementations inside your library. Weak attribute is a GCC extension. Anyway - having just extern before such function names should be enough... Take a look at how it's done in OpenOCD - some modules are compiled into libraries, than one huge library is created and final executable is done with that lib. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] libswd drivers question
W dniu 2011-07-14 15:24:48 użytkownik Tomek CEDRO tomek.ce...@gmail.com
napisał:
Hello Freddie! I am doing exactly the same way, but at final link
operation libswd cannot find extern functions provided by openocd
library.
Maybe there's something wrong with compilation settings?
Anyway I was wondering if this method can produce standalone library
as there will be no extern functions provided by external
applications by default... this is why I am considering function
pointers...
If you define a consistent API that OpenOCD and UrJTAG would have to use than
having extern would be sufficient. In other case think about weak symbols -
your stub do-nothing implementations would just return some error
(ERROR_NOT_DEFINED for example) so that libswd would have a way to check.
Function pointers that would have to be initialized doesn't seem as a standard
solution to me.
During linking a weak symbol (your do-nothing stub) is discarded when another
normal symbol (real function from another library) is found. This way user
wouldn't have to worry about initializing anything [;
void function(void) __attribute__ ((weak));
void function(void)
{ return ERROR_NOT_DEFINED; }
P.S. Czy nie sądzisz, że to głupie, że dwóch Polaków gada ze sobą po angielsku?
(;
4\/3!!
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD for STM32F2xx microcontroller
I recall that there was some work to implement STM32F2xx in OpenOCD lately, but I don't know the progress. You are using (probably) my compilation from over half year ago, so at that time there was no work on that. Check if current tree has that target supported and if you need a precompiled version I could finally compile something new. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Help needed for SAM3S4C
Are you absolutely sure that your code was loaded in the chip? Because Eclipse takes the instructions from the chip and these seem totally different than what you'd expect... You can verify the instructions at some address with OpenOCD via telnet with command arm disassemble address count thumb - you will know then whether your code is flashed in the chip. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] remove srst pulls trst from LPC2xxx t= arget scripts
Rolf Meeser rolfm_...@yahoo.de napisał(a): On 12/05/2010 11:00 PM, Freddie Chopin wrote: So how about this idea of removing useless and wrong occurences of srst_pulls_trst from lpc config files? Are you sure this is correct? Copy protection of LPC controllers relies on the fact that it is not possible to halt the processor right after reset. If your findings were correct, you would have discovered an easy way to circumvent NXP's security mechanism. Well, I cannot check all LPCs, because at the moment I only have LPC2103, but this small experiment seems to show that srst_pulls_trst is not necessary https://lists.berlios.de/pipermail/openocd-development/2010-December/017405.html Actually this was suggested by Peter Stuge in August http://openocd.git.sourceforge.net/git/gitweb.cgi?p=openocd/openocd;a=commit;h=8772355bbd507f4cd191d589d7ab5060b97c1818 Not having srst_pulls_trst is very convenient, as sometimes this code that could run for a brief moment before halt could make things like disable JTAG, start PLL with wrong values, etc. Generally without that option debugging LPCs is much more reliable. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] remove srst pulls trst from LPC2xxx t= arget scripts
David Brownell davi...@pacbell.net napisał(a): Which ones are useless? Which are wrong? And for the latter , why haven't we seen specific bug reports, followed by trivial patches? C'mon - we both know that everyone thinks srst_pulls_trst is mandatory for LPC parts and my findings https://lists.berlios.de/pipermail/openocd-development/2010-December/017405.html as well as Peter Stuge's findings http://openocd.git.sourceforge.net/git/gitweb.cgi?p=openocd/openocd;a=commit;h=8772355bbd507f4cd191d589d7ab5060b97c1818 show that it's not true. Of course LPCs work with srst_pulls_trst - they will probably work with many (all?) combinations of reset_config, but these configs should show the best possible configuration, not something that barely works. Generally see my previous post about reasons to remove this option. The first sane example of that option which I ever herd was for some LPC chip where it was described as a silicon work-around (and thus it made sense to be in a target file). I've browsed through erratas for LPC2103, LPC2148 and LPC2478 - no mention about such limitation. I think everyone agrees that when board wiring calls for that option, it belongs in a board config file rather than elsewhere. As I've said on Saturday - I've just removed srst_pulls_trst - nothing else. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 1/2] add quot; cortex m3 reset config= = = ...quot; to stm32.cfg
David Brownell davi...@pacbell.net napisał(a): I think Freddie's comment (that it does have something to do with it) made confusion, then. Which comment? That would be explained by my trusting Freddie's comment to be accurate, i while it was instead ncorrect at the levels I was commenting on. ? 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 1/2] add quot; cortex m3 reset config = ...quot; to stm32.cfg
Spencer Oliver s...@spen-soft.co.uk napisał(a): I thought we has decided to work on the ability to make openocd a bit more reset aware for cortex-m3. This is just for now, as maybe a new bug-fix release will be made. This fixes the case for some users, but will break it for others. For whom does that break anything? STM32 supports sysresetreq, so why not use it in target config file? For the moment i would say hold off, and lets come up with a better solution that makes everyone happy. This is a temporary fix that breaks nothing until something else will be introduced. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 1/2] add quot; cortex m3 reset config= = ...quot; to stm32.cfg
Spencer Oliver s...@spen-soft.co.uk napisał(a): As we know the current behaviour of cortex_m3 reset_config is to override the std 'reset_config' setting - this has undesired effects for people who expect srst for example to work. We need to change that functionality then adding your patch would be ok. This does create an issue for all the luminary scripts however. They would need the 'reset_config srst_only' removing and this would break all the older scripts in the wild. I am looking at this at the moment, as i would like a solution. Are you working on something specific, or maybe my idea of cortex_m3 capabilities soft_reset would do? 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Current stable release is very very stale
David Brownell davi...@pacbell.net napisał(a): Plans are still: (i) merge framework code first, hold the FT2232/Luminary driver code till later. Have you synchronized your work with that of Tomek Cedro? There is a big chance that Tomek may be doing the same work you've already done... have to wait a long time to see it ;( As you see (probably) nothing is going on in this matter... If you think that, you've not bothered to read any of my status reports. OK, let me rephrase. Some ppl said that they are working on the subject, but due to various reasons the cannot continue. As you said - you've created the code last summer, now it's almost winter and you state that you'll not have much time to work on it soon. IMO SWD is the most wanted feature in OpenOCD. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Current stable release is very very stale
Eric Parsonage e...@eparsonage.com napisał(a): I am keen to hear when the next stable release of openocd is going to be available ? I want a release version of openocd that supports Lisa-l. Lisa-l support has been in the code for several months now but there is no sight of any release. I dont understand why the process is taking so long ? can somebody explain ? It was said that the milestone for next release is SWD support, so probably we'll have to wait a long time to see it ;( As you see (probably) nothing is going on in this matter... 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Openocd and latest code sourcery toolchain
Michele Da Rold michele.dar...@ecsproject.com napisał(a): someone have a new version compiled for windows and parallel port? Have you searched? http://lmgtfy.com/?q=openocd+windows http://freddiechopin.info/index.php/en/download/category/4-openocd http://freddiechopin.info/index.php/en/download/category/10-openocd-dev 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Disable stm32x block write by default?
Default stm32.cfg script, STM32F103RB chip, OpenOCD build from 28.10.2010. Everything works perfectly fine without any changes. Open On-Chip Debugger reset halt JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3) JTAG tap: stm32.bs tap/device found: 0x16410041 (mfg: 0x020, part: 0x6410, ver: 0x1) Only resetting the Cortex-M3 core, use a reset-init event handler to reset any p eripherals target state: halted target halted due to debug-request, current mode: Thread xPSR: 0x0100 pc: 0x08000130 msp: 0x26e8 flash probe 0 device id = 0x20036410 flash size = 128kbytes device id = 0x20036410 flash size = 128kbytes flash 'stm32x' found at 0x0800 stm32x unlock 0 stm32x unlocked. INFO: a reset or power cycle is required for the new settings to take effect. reset init JTAG tap: stm32.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3) JTAG tap: stm32.bs tap/device found: 0x16410041 (mfg: 0x020, part: 0x6410, ver: 0x1) Only resetting the Cortex-M3 core, use a reset-init event handler to reset any p eripherals target state: halted target halted due to debug-request, current mode: Thread xPSR: 0x0100 pc: 0x08000130 msp: 0x26e8 flash erase_address 0x0800 0x800 erased address 0x0800 (length 2048) in 0.078125s (25.600 KiB/s) flash fillw 0x0800 0x12345678 0x40 wrote 256 bytes to 0x0800 in 0.312500s (0.800 KiB/s) mdw 0x0800 0x40 0x0800: 12345678 12345678 12345678 12345678 12345678 12345678 12345678 12345 678 0x0820: 12345678 12345678 12345678 12345678 12345678 12345678 12345678 12345 678 0x0840: 12345678 12345678 12345678 12345678 12345678 12345678 12345678 12345 678 0x0860: 12345678 12345678 12345678 12345678 12345678 12345678 12345678 12345 678 0x0880: 12345678 12345678 12345678 12345678 12345678 12345678 12345678 12345 678 0x08a0: 12345678 12345678 12345678 12345678 12345678 12345678 12345678 12345 678 0x08c0: 12345678 12345678 12345678 12345678 12345678 12345678 12345678 12345 678 0x08e0: 12345678 12345678 12345678 12345678 12345678 12345678 12345678 12345 678 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] =?ISO-8859-2?Q?Re: Re: Problems with workareasize and STM32F100 (8kB= of RAM)?=
Peter Stuge pe...@stuge.se napisał(a): Freddie Chopin wrote: I was considering this too. I strongly prefer a single file for the entire family if possible, but it should not cost very much, if any, performance. But in this situation single file costs performance, so that's not a good idea. BTW I do not prefer single file for whole family, anyway OpenOCD does not have it as a rule. Too many levels IMO. Just put stm32, str7, str9 directly under target. Number of level is not important. Can be my way, can be your way (; Yes and no. I think that it's really nice to only need to specify the family of chips that you're working with. Maybe yes, but naming the specific chip does no harm either. Also yes and no. A typical openocd.cfg should just pull in some existing files from tcl/ but there are a lot of bad examples which confuse things, by copypasting everything into openocd.cfg instead of sourcing the distributed cfg files. I strongly disagree. User friendly nowadays means GUI and total ease-of-use. You know NXP chips, so you probably know Flash Loader. It is possible to use this application right out-of-the-box, you don't need to browse through the cfg files, change anything there, read manual with commands, etc. You just run and use it. Requiring somebody to write cfg files is not the right way to go. IMHO cfg files for all chips should be created, so that in std cases ppl would not need to write any files. If there isn't one already then I think an example on the web would go a long way. Do we have a wiki? That is your way, my way is to start OpenOCD with additional command line parameters (-f interface/sth.cfg -f target/sth.cfg -c jtag_khz 1000). It's pretty hard (impossible?) to override anything through command line parameters... You like your way, I like mine, probably neither of us will change their habits. I'm pretty sure there are some other ways and OpenOCD should allow to use it easily too. Separate CFGs for all chips is the way to go IMHO. BTW such files would not prevent using general family files. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] =?ISO-8859-2?Q?Re: Re: Problems with workareasize and STM32F100 (8kB= of RAM)?=
Xiaofan Chen xiaof...@gmail.com napisał(a): Yet another solution is to have a generic cfg file with minimum 4KB of SRAM but allow user to overwrite the generic config file with bigger working area for better performance. Is this possible? Of course it is possible, but how many users will know that they should do that (IMHO 5%), how many users will do that (IMHO 1%) and how many would just complain in vaious places that OpenOCD is slow and hard to use (IMHO 90%)? 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] =?ISO-8859-2?Q?Re: Re: Re: Re: Problems with workareasize and STM32F=100 (8kB of RAM)?=
Xiaofan Chen xiaof...@gmail.com napisał(a): I understand your concern. However, if you have a good wiki and documentations (say put in the comment in the starting of the config file), then it would not be too bad. Just ask the user to RTM/RTFM. ;-) That's not the case of telling somebody to do RTFM, but rather a case of general opinion about software that is around the web. There are a lot of programs that you do not need to look into cfg files and IMHO that's very fine. OpenOCD can be improved that way too, but I'd like to hear maintainter's opinion before I'll try making some patches. A GUI utility to generate the config file would be nice. A GUI utility to do usual things would be even nicer - specify interface/chip, press connect, select image file, press flash and that's it! OpenOCD is anyway not that fast and indeed not that easy to use, compared to IAR/J-Link... This can be improved! But every maintainer must want that too. I think making OpenOCD more user-friendly and having SWD support would be a major brakthrough for it, bot I think nothing is going on in those areas... 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] =?ISO-8859-2?Q?Re: Re: Problems with workareasize and STM32F100 (8kB= of RAM)?=
Peter Stuge pe...@stuge.se napisał(a): You must have missed the patches. I don't think so. SWD is being talked about for ~2 years, in the meantime SWD-only chips appeared on the market (LPC1xxx, LPC13xx, etc.), commercial and free toolchains support it already, OpenOCD is (IMHO) not even close... Sure, there've been some patches, like 1 every few months, but I guess implementing SWD will require a lot of patches (100?). In 2009 there was new release every ~4months, since 0.4.0 almost 9 months have passed, and I don't think we'll see 0.5.0 with SWD anytime soon. If you can help, go for it. I'd like to, but I can't - not my level of knowledge, not my level of skill - I'm just an embedded engineer, not PC programmer. Just remember that GUI is not the only way, and that flashing and debugging are distinct (although related!) tasks. Sure not, but the most successful commercial/free-demo tools are GUI-only (Keil, IAR, CrossWorks, etc.). Whatever you think about Windows, GUIs or ease-of-use, the facts are that these are popular because they can be operated by a monkey (; 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] =?ISO-8859-2?Q?Re: Re: Problems with workareasize and STM32F100 (8kB= of RAM)?=
oyvind.har...@zylin.com napisał(a): I think that OpenOCD should stay away from GUI's and focus on the core functionality. Just like GDB does. GDB isn't a GUI, but it *supports* GUIs. Sure, I also think that OpenOCD does not need an embedded GUI, but I hope that someday someone will make a GUI for OpenOCD as a separate project. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] =?ISO-8859-2?Q?Re: Re: Problems with workareasize and STM32F100 (8kB= of RAM)?=
Peter Stuge pe...@stuge.se napisał(a): Unless there is a way to tell devices apart. Usually there is (; Sometimes some more logic is required, but generally that is possible (JTAG ID, special registers with ID, flash sizes, etc.) BTW I do not prefer single file for whole family, Why not? No big deal, but I'm curious. Usually you have to change something in such generic files. The need to change anything in chip-specific files is lower. It requires more detailed manual configuration, ie. less automation, which is really annoying if it can be avoided. But sometimes it can't be avoided. I guess this is the case here. As I wrote before, generic files would still be usable alone, so automatic stuff can use them. OpenOCD does not do anything automatically though... Many may prefer GUI but please do not make the mistake of thinking that GUI is the only way to have ease of use!! Sure it's not (; GUIs such as Eclipse are sometimes so bad that they become counter- productive. I've touched on the Eclipse surface a few times in different contexts and it has always been an absolute disaster. It's the very definition of bloat if you ask me. My curiosity now - what do you prefer to IDEs like Eclipse. Personally I love Eclipse and I cannot imagine using anything else with comparable efficiency and ease. I did a few hours of research before starting with ARM last year, bought a nice development board with cfg in board/ and a JTAG adapter with cfg in interface/, and then I spent about 60 minutes on stuff before I had everything from toolchain to debugger and blinking LED working. I think that is pretty amazing, and it proves that the tools are really good already. I've received an LPC1114 mini-board recently. I knew nothing about those chips. I've installed Flash Loader and after few seconds the chip was programmed... Beat that (; No doubt they can get even better, but 60 minutes is already very close to out-of-the-box. I don't think it's useful to optimize that process too much more, because someone who can not manage to overcome such a small hurdle will inevitably fail miserably later in their project anyway, and should just be doing something else, or the same thing but in a different way. (Maybe using Flash Loader?) I don't think so. To grasp the configuration of OpenOCD you need to read the whole manual, check existing files, learn exotic TCL scripting (I've never heard about it before OpenOCD) from somewhere else (specifics are not included in OpenOCD manual) - it's far from being user-friendly... Of course such problems can and have to be solved by user, but I cannot agree to opinions that it's right that these are here, as they separate users from losers. In such case we could throw in some additional tests... Yes and no. I agree that it would have sucked if I had to write a target cfg for the device on my development board. But I didn't, because I made sure to buy a board that was already supported. Since OpenOCD is an open source project I don't think that it is realistic for anyone to expect that *every* possible target will already be supported. I also don't think you suggested this either, but clearly we all want more target cfg files. :) IMHO having target files for almost all (most of) supported chips is realistic - for instance OpenOCD has interface files for many supported interfaces, even though most of them are FT2232 based and could use only one cfg file instead of few dozens. As for Flash Loader, the name suggests that it is a download-only program, maybe not so much involved in debugging. OpenOCD does both, and since the latter requires a lot more information it is unneccessarily complicated to just do a firmware download. This might actually be a significant possible improvement for OpenOCD. On the other hand, you typically want the debugger working pretty soon as well.. Indeed Flash Loader is for flashing only, but there are many users who use OpenOCD only for that... Yep! Please send patches. I will also. I'll wait for maintainters' opinions, because if they don't like the idea of separate cfg files any patch in that area would be just a waste of time. Yes! I've tried to play with this a few times. I think it looks like a nice way to use openocd when openocd.cfg would do nothing but source existing files. I didn't get it to do exactly what I wanted, but I like this approach too because it doesn't require a config file. On the other hand the long command line is very annoying to type. I (almost) never type that, as Eclipse does that for me [; You can always have a shell script to do that for you, but that would probably be no different than having openocd.cfg. Hm? I was not really clear about how -c relates to e.g. procedures defined in openocd.cfg. Do you know more about the ordering? -c sth can call anything from any cfg file or OpenOCD-specific
[Openocd-development] =?ISO-8859-2?Q?Re: Re: Eclipse Helios GDB settings (was: STM32flashw=rite speed)?=
Andreas Fritiofson napisał(a): The clearing lockup after double fault says that the core was in a lockup state which means a fault occurred (bad memory access, invalid instruction and such, probably due to a software bug) and, in addition, there was an error while fetching or executing the exception vector (no fault handler installed?). Common bugs that can cause this is invalid pointer dereferencing, buffer overflows or enabled interrupts for which no handler is installed. Actually there is another (IMO more common) cause: no (valid) code in the device. After erasing, running the blank chip results in double lockup too. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] =?ISO-8859-2?Q?Re: Re: libftdi or libftdi-1.0 MinGW 32bit binary an=d OpenOCD?=
Xiaofan Chen xiaof...@gmail.com napisał(a): I have some issues to build libusb-win32 with x86_64-w64-mingw32 but I managed to fix them. Did you need some fixes as well? Could you post your fixes? After some minor fixes (header file location different from MinGW32bit), I can build libusb-win32 latest svn under x86_64-w64-mingw32 except the driver (too many errors). It was same here - I've just needed to change the location of some headers to build the dll and .a files. Anyway, we do not recommend or support using MinGW for the libusb0.sys building as of now. We recommend to use Microsoft WDK for the driver building since the past tests shows that the driver built with MinGW has some problems. But we may want to release 64bit MinGW import library in the future. Right now only 32bit MinGW import library are released. From what I remember that was the reason for me to build that myself - you provide only 32-bit version of libusb.a and building 64-bit version of OpenOCD requires a 64-bit version of the libs. Am I correct here? That was some time ago when I compiled those libs. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] =?ISO-8859-2?Q?Re: Re : Openocd-development Digest, Vol 45, Issue 44=ina?=
Hi! After installing OpenOCD extract the file c:\Program Files\OpenOCD\0.4.0\drivers\libusb-win32_ft2232_driver-100223.zip and follow the instructions in info.txt. This package has functional libusb-win32 drivers for JTAGkey. When searching for drivers point the wizard (with the Have Disk button) to the directory containing libusb-win32_ft2232_driver.inf. Have in mind that FT2232 is a composite device which normally takes 3-5 drivers: - Composite Device - this uses generic Windows driver (this usually does not require any Wizard and is installed automatically) - first channel (Channel A - usually JTAG interface) - second channel (Channel B - usually USB Serial Port or unused) if first or second channel are configured as serial port, additional drivers will be required for USB Serial Port. Your JTAGkey should require 3 drivers - Composite Device (automatic) and 2x libusb-win32 from the package bundled with OpenOCD installer. Do note, that once you installed ftd2xx drivers you have to remove the ones you wish to replace or - as Xiaofan said - you can manually update them. You only need to manipulate with the first channel, as OpenOCD doesn't care about the second channel (whether or not it's actually used for anything). 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] =?ISO-8859-2?Q?Re: [PATCH] stm32 : improve unlock procedure for mass=_erase?=
gcembed gcem...@gmail.com napisał(a): Hello, I have added a new command for stm32x : mass_erase_unlock This function combine stm32x unlock 0 + reset to apply unlock + stm32x mass_erase 0 Maybe unlock_mass_erase would be a better name? 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] STM32 flash erase timeout fix
Użytkownik Tobias Ringström tob...@ringis.se napisał: The current timeout for STM32 flash block erase and flash mass erase is 10 (ms), which is too tight, and fails around 50% of the time for me. The data sheet for STM32F107VC specifies a maximum erase time of 40 ms (for both operations). Never happened for me in a few different designs... 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] =?ISO-8859-2?Q?Re: Re: [PATCH] Change kb/s to KB/s in messages r=efering to kibibytes?=
Użytkownik Laurent Gauch laurent.ga...@amontec.com napisał: kilograms is Kg not kg You're wrong - kilogram is definetely kg - http://en.wikipedia.org/wiki/Kilogram http://en.wikipedia.org/wiki/SI_prefix , just the same as km or kV. Capital K actually stands for kelvin in SI, so using it as binary kilo is somewhat wrong. The notation KB/s is popular, but not scientific ! The / (devisor notation) in KB/s is really not a scientific notation Kbps is scientific ;-) The form x/s is widely used, while xps is used rarely (IMHO). The best would be to write in plain text as byte http://en.wikipedia.org/wiki/Byte per second bit http://en.wikipedia.org/wiki/Bit per second kilobyte http://en.wikipedia.org/wiki/Kilobyte per second megabit http://en.wikipedia.org/wiki/Megabit per second kibibit http://en.wikipedia.org/wiki/Kibibit per second or a mix as nnnKB/s (kilobyte http://en.wikipedia.org/wiki/Kilobyte per second) ... I'm for using the binary prefixes ( http://en.wikipedia.org/wiki/Binary_prefix ) in the form of x/s so e.g. KiB/s 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] GPL violations
I've recently wrote that I know of 4 GPL violations (distributing OpenOCD with ftd2xx library). Make that 5 now... Since there are NO activities from the most dedicated GPL-fans, than maybe I'll just post such version on my webpage too? 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] GPL violations
Użytkownik Nico Coesel ncoe...@dealogic.nl napisał: Freddie, IMHO its in everyone's best interest if you describe what and where the GPL violations are. People can then decide whether your findings are GPL violations and what to do about them. Hear no evil - see no evil is not going to work. All what I found is a pure GPL violation (according to GPL-fans from this list) - those are OpenOCD binaries linked to ftd2xx.dll or OpenOCD binary dynamically loading ftd2xx.dll. Why should I rat anyone (remember, that I'd love to distribute OpenOCD with ftd2xx.dll) when - as I said previously - finding one of that sites is TRIVIAL, and yet no-one has done anything... There was NO action what-so-ever, and when there was a discussion a year ago some ppl would kill for GPL. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 2/3] update win32 script search path
Użytkownik oyvind.har...@zylin.com napisał: I find it odd that none has. Personally I don't know what is the point of that patch. I don't use OpenOCD via tree of MinGW/MSYS and I don't think anyone does, so what's the point of that patch? I use MinGW/MSYS to compile OpenOCD, and it compiles fine, because that process does not require cfg files. In windows there is only one place for installing software - C:\Program Files\. Personally I package OpenOCD the same way as Michael Fisher has done that in the past: /bin/ (exe + dll), /interface/ (cfg), /target/ (cfg), /board/ (cfg) and that works as a charm. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] =?ISO-8859-2?Q?Re: Re: What became of the generic LPC config script=??=
Użytkownik oyvind.har...@zylin.com napisał: Could you point me to the latest version? http://lists.berlios.de/pipermail/openocd-development/2009-September/010849.html Why a sudden resurrection? 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] new lpc2xxx cfg files layout
Petri Pirttinen petri.pirtti...@tietolaite.com napisał(a): I may have missed something in here, but why trying to specify a crystal frequency? Can't we use 4 MHz in here, IF we are setting the clock source to internal RC oscillator in reset-init script anyway? 1. Not all LPCs have internal RC - just the more recent ones from LPC23xx and LPC24xx family - older ones (LPC21xx and LPC22xx) need a crystal to start and run. 2. To clarify - 12MHz is the default value for the chips without the RC. The ones that do have it have that frequency configured to 4MHz. And, Freddie, I hope you can bear with this conversation. I think that these things discussed in here does relate to each other, although some of them needs to be addressed separately really. In all and all I'm quite thrilled about this as finally I get some light shred to this LPC2xxx mess. Your proposed script layout is A LOT better than any I've seen so far. The things are related - true, but there is no problem in finishing with one and starting another then, not to simultaneously think about 10 different things. IMHO we'll never go anywhere while jumping around like this. Anyway - to be honest - I don't know what should I / we do now. The frequency IS required, it has to be specified some way or another. Unfortunatelly I think only the method proposed in the file I posted is user friendly - the need for next wrapper script that would specify that just because frequency is not specific to targets seem extremely un-friendly to me. How should that case be continued? I really don't know what other change is expected to happen in that file... 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] new lpc2xxx cfg files layout
oyvind.har...@zylin.com napisał(a): My concern about your patch(I haven't dived into it) is that last time I worked on LPC reset scripts, I had to stay clear of soft_reset_halt and set the CPU into the ARM state manually... To keep the status quo for now I haven't changed that part - there is no soft_reset_halt in reset-init. I've just added disabling of PLL and MAM. So what's the best way forward here? For me it seems that the best is to start gdb for flashing with: monitor reset init load and for debugging without flashing with: monitor reset init soft_reset_halt This way it works for me reliably. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Final Fixes for 0.2.0?
Řyvind Harboe oyvind.har...@zylin.com napisał(a): Can you do one better and submit a correct patch? The mechanism itself is fine, so I just fixed the descriptions and numbers. And some other minor things by the way. 4\/3!! work-area-fix.patch Description: Binary data ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] platform survey
Zach Welch z...@superlucidity.net napisał(a): Hi all, Michael Fischer posted the following survey on the SparkFun forum: http://forum.sparkfun.com/viewtopic.php?t=16044 There are already some more votes here: http://www.elektroda.pl/rtvforum/topic1347875.html You have to register to see the poll, but currently the numbers are: Windows ? 68% ?[ 20 ] Linux ? 24% ?[ 7 ] Mac OS X ? 3% ?[ 1 ] other ? 3% ?[ 1 ] all : 29 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] =?ISO-8859-2?Q?Re: Re: EmbeddedICE handling might be broken with A=
Użytkownik Kevin Townsend ktowns...@free.fr napisał: Error: JTAG tap: lpc2478.cpu got: 0x4f1f0f0f (mfg: 0x787, part: 0xf1f0, ver: 0x4) put that value (0x4f1f0f0f) in your config file at the top: set CPUTAPID 0x4f1f0f0f 0x is the default value used to cause the error, so that you can get the right value. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] another STM32 problems with RLink
I've tried with another RLink (that one is completely new) and it's the same. I've also tried the primer again and it works completely fine with exactly the same setup 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Fwd: openocd-0.1.0.mci
It was me (; I've downloaded the installer now and tested it with the md5 (also downloaded now) - its fine (on both download servers). The file matches the one I'm hosting on my private website... The downloaded installer works fine with my PC... Maybe the author of the forwarded mail should join the list and describe the his/her problems in greater detail? 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] OpenOCD 0.1.0 released
quest 1: would that be possible to change Type: Other to sth like Type: Windows installer on the project's file list? this would be more informative for the users (; quest 2: can I mirror to the project website on my webpage? 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
