Re: [Openocd-development] [PATCH 1/3] CortexA8: Setup debug_base according to variant
On Fri, Oct 29, 2010 at 7:57 AM, Marek Vasut marek.vasut.n...@gmail.com wrote: Shouldn't this be automatically detected? yes it should ... i'll send a patch on top of this one once I figure out how to do it. Is that good enough approach for you? Or shall we put these on hold until then? I would definitely like the autodetect to go in first, then the patches can be simplified. -- Øyvind Harboe US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 1/3] CortexA8: Setup debug_base according to variant
On Fri, Oct 29, 2010 at 8:08 AM, Marek Vasut marek.vasut.n...@gmail.com wrote: On Fri, Oct 29, 2010 at 7:57 AM, Marek Vasut marek.vasut.n...@gmail.com wrote: Shouldn't this be automatically detected? yes it should ... i'll send a patch on top of this one once I figure out how to do it. Is that good enough approach for you? Or shall we put these on hold until then? I would definitely like the autodetect to go in first, then the patches can be simplified. You've got a point here, but I really don't know how much time will that take, though I'll look into it probably even today. I'd appreciate any hints on this. Zach made some postings in the not to distant path to the list about this subject. -- Øyvind Harboe US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Problems with workareasize and STM32F100 (8kB of RAM)
On Fri, Oct 29, 2010 at 3:41 AM, Freddie Chopin freddie_cho...@op.pl wrote: Of course another solution would be to create a general cfg file and small dedicated cfg files for every STM32 device available (currently 89) - these would use (include) the general cfg. The structure of the target folder could be changed to 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? -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Problems with workareasize and STM32F100 (8kB of RAM)
Xiaofan Chen wrote: create a general cfg file and small dedicated cfg files for every STM32 device available Yet another solution is to have a generic cfg file with minimum 4KB of SRAM I think this was the idea. but allow user to overwrite the generic config file with bigger working area for better performance. The idea was that users override the generic config by sourcing a device specific config instead. I think that there is enough dynamic in the range of devices within families that when working with the high end devices it will not make sense to ever limit throughput to that of lower end devices. Ie. users would *always* want to override. And forcing them to do that manually doesn't make so much sense to me. The ideal would be for openocd to identify the device. I guess IDCODE is not good enough to tell two devices with the same core apart, so we really have to rely on user input for it. :\ //Peter ___ 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
Re: [Openocd-development] Switching to Jim Tcl release
Going twice... I'll be merging this beginning of next week not to ruin anyones(especially mine! :-) weekend if there is any fallout. It would mainly be with documenting and build procedures and laying out some bread-crumbs to follow. -- Øyvind Harboe US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 1/3] CortexA8: Setup debug_base according to variant
On Friday 29 October 2010 07:43:18 Peter Stuge wrote: Marek Vasut wrote: In this patch, I introduce the use of -variant parameter, so I can adjust the debug_base accordingly. This seems completely wrong to me. I think this logic should just stay in Tcl. So if anything, you would add a parameter for dap_base. That's what I wanted to do, but I'm still starting to get familiar with OpenOCD again. Could you point me in a direction please? //Peter ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 1/3] CortexA8: Setup debug_base according to variant
On Friday 29 October 2010 08:18:46 Marek Vasut wrote: On Fri, Oct 29, 2010 at 8:08 AM, Marek Vasut marek.vasut.n...@gmail.com wrote: On Fri, Oct 29, 2010 at 7:57 AM, Marek Vasut marek.vasut.n...@gmail.com wrote: Shouldn't this be automatically detected? yes it should ... i'll send a patch on top of this one once I figure out how to do it. Is that good enough approach for you? Or shall we put these on hold until then? I would definitely like the autodetect to go in first, then the patches can be simplified. You've got a point here, but I really don't know how much time will that take, though I'll look into it probably even today. I'd appreciate any hints on this. Zach made some postings in the not to distant path to the list about this subject. thanks! i'll look once I arive at university ... I just left dorms and I'm going for a bus :b Oyvind sorry, I just can't find it ... could you tell me where it is please ? ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 1/3] CortexA8: Setup debug_base according to variant
On Fri, Oct 29, 2010 at 9:33 AM, Marek Vasut marek.va...@gmail.com wrote: On Friday 29 October 2010 07:43:18 Peter Stuge wrote: Marek Vasut wrote: In this patch, I introduce the use of -variant parameter, so I can adjust the debug_base accordingly. This seems completely wrong to me. I think this logic should just stay in Tcl. So if anything, you would add a parameter for dap_base. That's what I wanted to do, but I'm still starting to get familiar with OpenOCD again. Could you point me in a direction please? This should be picked up automatically, so this is the wrong direction. If you type dap info 0, I believe it prints out the debug base, so the code is even in there in OpenOCD. -- Øyvind Harboe US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 1/3] CortexA8: Setup debug_base according to variant
Oyvind sorry, I just can't find it ... could you tell me where it is please ? Start here: https://lists.berlios.de/pipermail/openocd-development/2010-September/016482.html -- Øyvind Harboe US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Problems with workareasize and STM32F100 (8kB of RAM)
2010/10/29 freddie_cho...@op.pl: 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%)? 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. ;-) A GUI utility to generate the config file would be nice. OpenOCD is anyway not that fast and indeed not that easy to use, compared to IAR/J-Link... -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Problems with workareasize and STM32F100 (8kB of RAM)
On Fri, Oct 29, 2010 at 2:43 PM, Peter Stuge pe...@stuge.se wrote: The ideal would be for openocd to identify the device. I guess IDCODE is not good enough to tell two devices with the same core apart, so we really have to rely on user input for it. :\ Ah, good idea. I think a new parameter is good to have in the command line. For example, pk2cmd for PICkit 2 has the parameter -p mcuname even though it can automatic detect most of the PICs (not 12bit family though). So maybe it is good to have one parameter to specify the chip name. From there, certain parameter like working area and Flash size can be derived, through things like XML or plain text configure files. -- Xiaofan ___ 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
Re: [Openocd-development] Problems with workareasize and STM32F100 (8kB of RAM)
freddie_cho...@op.pl 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, Unless there is a way to tell devices apart. BTW I do not prefer single file for whole family, Why not? No big deal, but I'm curious. anyway OpenOCD does not have it as a rule. No, but I think that it is very important to have only a single recommended hierarchy for cfg files. Ie. that files in board/ must always be higher level than files in target/. I think this is the case now, and it is very important for understanding. 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 (; I do think number of levels is important. Fewer levels allows for a much quicker overview. 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. 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. 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. Many may prefer GUI but please do not make the mistake of thinking that GUI is the only way to have ease of use!! 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. On the other hand, if all circumstances are right and it fits the user's needs, then I am sure that it is wonderful. I know others who also quite strongly prefer command line control over OpenOCD as well as the other development tools. And I know several who are conditioned into thinking that GUI or IDE is the only way of working. Eclipse and other GUIs are very important since it helps them. Ease of use is another story however; I certainly agree about out-of-the-box being important, both for GUI and CLI! You know NXP chips, so you probably know Flash Loader. No, I've only used OpenOCD, mtools (for the USB storage bootloader in LPC134x since it makes assumptions about sector allocation which mismatch what the kernel vfat driver does) and vsprog so far. I avoid Windows as much as I can. It's really sad that NXP has even gone so far as to put in datasheets that the USB bootloader will only work with Windows. I guess we will only see more such nonsense in the future, as vendors try to focus on core business but must also integrate with a whole world around them that they do not understand the least bit. Difficult! Sorry, back on topic now. :) 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. 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. 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?) Requiring somebody to write cfg files is not the right way to go. 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. :) 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
Re: [Openocd-development] [PATCH 1/3] CortexA8: Setup debug_base?according to variant
Marek Vasut wrote: add a parameter for dap_base. That's what I wanted to do, but I'm still starting to get familiar with OpenOCD again. Could you point me in a direction please? Um, well, don't you just do the same thing as you did for -variant, except use strtoul() in the C code? //Peter ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 1/3] CortexA8: Setup debug_base according to variant
Øyvind Harboe wrote: So if anything, you would add a parameter for dap_base. Could you point me in a direction please? This should be picked up automatically, so this is the wrong direction. If you type dap info 0, I believe it prints out the debug base, so the code is even in there in OpenOCD. Awesome! Sorry for my noise. //Peter ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Problems with workareasize and STM32F100 (8kB of RAM)
freddie_cho...@op.pl wrote: 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... You must have missed the patches. I also think user friendliness and SWD are good improvements. If you can help, go for it. Just remember that GUI is not the only way, and that flashing and debugging are distinct (although related!) tasks. //Peter ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Problems with workareasize and STM32F 0 (8kB of RAM)
2010/10/29 freddie_cho...@op.pl: 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! That would be nice. Somewhat along the line of H-Jtag would be nice. http://www.hjtag.com/ 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... I have learned to be patient with Open Source projects. The sad reality is that in general the progress is not that fast for small projects like some projects I spent real efforts on (I did not spent too much efforts on OpenOCD though). For example libusb-win32 was not moving for three years (2007 -2010). In the end, Travis and I took over the project and make it moving again. -- Xiaofan ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Problems with workareasize and STM32F100 (8kB of RAM)
On Fri, Oct 29, 2010 at 10:24 AM, Peter Stuge pe...@stuge.se wrote: freddie_cho...@op.pl wrote: 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... You must have missed the patches. I also think user friendliness and SWD are good improvements. If you can help, go for it. Just remember that GUI is not the only way, and that flashing and debugging are distinct (although related!) tasks. 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. -- Øyvind Harboe US toll free 1-866-980-3434 / International +47 51 63 25 00 http://www.zylin.com/zy1000.html ARM7 ARM9 ARM11 XScale Cortex JTAG debugger and flash programmer ___ 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] stellaris.cfg
I had a problem with lm3s6965: Open On-Chip Debugger 0.5.0-dev-00565-g4617cd0 (2010-10-28-19:55) Licensed under GNU GPL v2 For bug reports, read http://openocd.berlios.de/doc/doxygen/bugs.html Info : only one transport option; autoselect 'jtag' 500 kHz adapter_nsrst_delay: 500 srst_only separate srst_gates_jtag srst_open_drain Info : clock speed 500 kHz Info : JTAG tap: lm3s6965.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3) Info : JTAG tap: lm3s6965.cpu tap/device found: 0x00ff (mfg: 0x07f, part: 0x, ver: 0x0) Warn : JTAG tap: lm3s6965.cpu UNEXPECTED: 0x00ff (mfg: 0x07f, part: 0x, ver: 0x0) Error: JTAG tap: lm3s6965.cpu expected 1 of 1: 0x0ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x0) Error: Trying to use configured scan chain anyway... Error: lm3s6965.cpu: IR capture error; saw 0x0f not 0x01 Warn : Bypassing JTAG setup events due to errors Warn : Invalid ACK 0x6 in JTAG-DP transaction Polling target failed, GDB will be halted. Polling again in 100ms A laptop with 0.5.0-dev-00445-g1143bbc (2010-07-20-09:22) works o.k., so I copied the stellaris.cfg from working laptop to desktop. Openocd back in action for Stellaris. Thanks Billy ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] stellaris.cfg
billium wrote:
I had a problem with lm3s6965:
Open On-Chip Debugger 0.5.0-dev-00565-g4617cd0 (2010-10-28-19:55)
Info : JTAG tap: lm3s6965.cpu tap/device found: 0x00ff (mfg: 0x07f, part:
0x, ver: 0x0)
Warn : JTAG tap: lm3s6965.cpu UNEXPECTED: 0x00ff (mfg: 0x07f, part:
0x, ver: 0x0)
Error: JTAG tap: lm3s6965.cpu expected 1 of 1: 0x0ba00477 (mfg: 0x23b, part:
0xba00, ver: 0x0)
Looks bad. :\
A laptop with 0.5.0-dev-00445-g1143bbc (2010-07-20-09:22) works o.k., so
I copied the stellaris.cfg from working laptop to desktop. Openocd back
in action for Stellaris. :)
Hm. Can you check what changes in the cfg file made it break? The
1143bbc..4617cd0 diff is attached. Please try adding each change in
to your working file and see where it breaks?
Which JTAG interface are you using?
//Peter
diff --git a/tcl/target/stellaris.cfg b/tcl/target/stellaris.cfg
index 5f4428f..e206a9c 100644
--- a/tcl/target/stellaris.cfg
+++ b/tcl/target/stellaris.cfg
@@ -1,5 +1,12 @@
# TI/Luminary Stellaris LM3S chip family
+# Luminary chips support both JTAG and SWD transports.
+# Adapt based on what transport is active.
+source [find target/swj-dp.tcl]
+
+# For now we ignore the SPI and UART options, which
+# are usable only for ISP style initial flash programming.
+
if { [info exists CHIPNAME] } {
set _CHIPNAME $CHIPNAME
} else {
@@ -18,22 +25,31 @@ if { [info exists CPUTAPID ] } {
set _CPUTAPID 0x0ba00477
}
+# SWD DAP, and JTAG TAP, take same params for now;
+# ... even though SWD ignores all except TAPID, and
+# JTAG shouldn't need anything more then irlen. (and TAPID).
+swj_newdap $_CHIPNAME cpu -irlen 4 -irmask 0xf \
+ -expected-id $_CPUTAPID -ignore-version
+
+if { [info exists WORKAREASIZE ] } {
+ set _WORKAREASIZE $WORKAREASIZE
+} else {
+ # default to 8K working area
+ set _WORKAREASIZE 0x2000
+}
+
jtag newtap $_CHIPNAME cpu -irlen 4 -irmask 0xf \
-expected-id $_CPUTAPID -ignore-version
-# The lm3s variant uses a software reset rather than SRST.
-# This stops the debug registers from being cleared; it works
-# around an erratum which should be fixed in later silicon.
set _TARGETNAME $_CHIPNAME.cpu
-target create $_TARGETNAME cortex_m3 -chain-position $_CHIPNAME.cpu \
- -variant lm3s
+target create $_TARGETNAME cortex_m3 -chain-position $_CHIPNAME.cpu
# 8K working area at base of ram, not backed up
#
# NOTE: you may need or want to reconfigure the work area;
# some parts have just 6K, and you may want to use other
# addresses (at end of mem not beginning) or back it up.
-$_TARGETNAME configure -work-area-phys 0x2000 -work-area-size 0x2000
+$_TARGETNAME configure -work-area-phys 0x2000 -work-area-size
$_WORKAREASIZE
# JTAG speed ... slow enough to work with a 12 MHz RC oscillator;
# LM3S parts don't support RTCK
@@ -42,7 +58,36 @@ $_TARGETNAME configure -work-area-phys 0x2000
-work-area-size 0x2000
# configures and enables the PLL. Or you might need to decrease
# this, if you're using a slower clock.
adapter_khz 500
-$_TARGETNAME configure -event reset-start {adapter_khz 500}
+
+source [find mem_helper.tcl]
+
+$_TARGETNAME configure -event reset-start {
+ adapter_khz 500
+
+ #
+ # When nRST is asserted on most Stellaris devices, it clears some of
+ # the debug state. The ARMv7M and Cortex-M3 TRMs say that's wrong;
+ # and OpenOCD depends on those TRMs. So we won't use SRST on those
+ # chips. (Only power-on reset should affect debug state, beyond a
+ # few specified bits; not the chip's nRST input, wired to SRST.)
+ #
+ # REVISIT current errata specs don't seem to cover this issue.
+ # Do we have more details than this email?
+ # https://lists.berlios.de/pipermail
+ # /openocd-development/2008-August/003065.html
+ #
+
+ set device_class [expr (([mrw 0x400fe000] 16) 0xff)]
+ if {$device_class == 0 || $device_class == 1 || $device_class == 3} {
+ # Sandstorm, Fury and DustDevil are able to use NVIC SYSRESETREQ
+ cortex_m3 reset_config sysresetreq
+ } else {
+ # Tempest and newer default to using NVIC VECTRESET
+ # this does mean a reset-init event handler is required to reset
+ # any peripherals
+ cortex_m3 reset_config vectreset
+ }
+}
# flash configuration ... autodetects sizes, autoprobed
flash bank $_CHIPNAME.flash stellaris 0 0 0 0 $_TARGETNAME
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] stellaris.cfg
Hi Bill, I recently tried OpenOCD and encountered the same problem. The cause seemed a relatively recent checkin that was attempting to add swj support. I've been bad though and haven't made a patch or filed a bug report. My quick fix was to comment out the two lines in stellaris.cfg that were mentioning swj (an import and some sort of swj add operation) Date: Fri, 29 Oct 2010 10:21:07 +0100 From: billium bill...@bucknall.me.uk To: openocd-development@lists.berlios.de Subject: [Openocd-development] stellaris.cfg I had a problem with lm3s6965: ... srst_only separate srst_gates_jtag srst_open_drain Info : clock speed 500 kHz Info : JTAG tap: lm3s6965.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3) Info : JTAG tap: lm3s6965.cpu tap/device found: 0x00ff (mfg: 0x07f, part: 0x, ver: 0x0) Warn : JTAG tap: lm3s6965.cpu UNEXPECTED: 0x00ff (mfg: 0x07f, part: 0x, ver: 0x0) Error: JTAG tap: lm3s6965.cpu expected 1 of 1: 0x0ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x0) Error: Trying to use configured scan chain anyway... Error: lm3s6965.cpu: IR capture error; saw 0x0f not 0x01 Warn : Bypassing JTAG setup events due to errors Warn : Invalid ACK 0x6 in JTAG-DP transaction Polling target failed, GDB will be halted. Polling again in 100ms ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] stellaris.cfg
I had a problem with lm3s6965: ... srst_only separate srst_gates_jtag srst_open_drain That looks wrong ... I don't recall that Stellaris parts wanted gating or open drain. And for that matter, the generic stellaris.cfg worked for me quite recently, so I suspect some issue with your customized setup Info : clock speed 500 kHz Info : JTAG tap: lm3s6965.cpu tap/device found: 0x3ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x3) Info : JTAG tap: lm3s6965.cpu tap/device found: 0x00ff (mfg: 0x07f, That 0x00ff indicates the JTAG scan failed. part: 0x, ver: 0x0) Warn : JTAG tap: lm3s6965.cpu UNEXPECTED: 0x00ff (mfg: 0x07f, part: 0x, ver: 0x0) Looks like hardware problems to me, at the level of some issue with TDI or TDO. Setting up your reset_config wrong, maybe... Error: JTAG tap: lm3s6965.cpu expected 1 of 1: 0x0ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x0) ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] STM32 core debug reset problem
Hi all, I'm using OpenOCD (version 0.4.0, downloaded from SourceForge and built about half an hour ago) on Debian Lenny (5.0, stable) running under VMWare Fusion on an x86 Mac Pro. The microcontroller I'm using is an STM32F103C6T6, and the JTAG dongle is an Amontec JTAGKey. By and large it works: I can program the flash, halt, use gdb, all the things I'd expect from OpenOCD. But there's a way of breaking it semi-permanently. The application on the STM32 is one which spends most of its time with the CPU in Stop mode, waking up periodically (about every 12ms) via an RTC interrupt to do some processing. If I attempt to start OpenOCD while the microcontroller is stopping and running like this, I get messages which say, Warn : Timeout (1000ms) waiting for ACK=OK/FAULT in JTAG-DP transaction and OpenOCD just won't work, though it finds the TAPs correctly so the JTAG hardware is clearly working to some extent. The whole JTAG system appears to be then stuck in this state. Restarting OpenOCD, doing a hardware system reset on the microcontroller, unplugging everything including the JTAG dongle and its USB interface, all make no difference. I've even tried exercising the JTAG port using another application (XJTAG) though this only does boundary scan testing and doesn't play with the ARM debug TAP. Though boundary scan works fine. The only thing which fixes the problem is power-cycling the STM32 chip itself. I note from its documentation and the ARM Cortex-M3 TRM that some parts of the core debug unit are only reset at power up, not in response to a system reset. The device has no TRST pin. However, this board is going to be permanently moulded into a plastic lump with a battery, so power cycling it is *not* an option. Am I stuck? Or is there a way of finding out how the Cortex-M3 debug unit is wedged, if that's the case, and tickling it back to life? Thank you Chris -- Chris Jones - ch...@martin-jones.com Martin-Jones Technology Ltd 148 Catharine Street, Cambridge, CB1 3AR, UK Phone +44 (0) 1223 655611 Fax +44 (0) 870 112 3908 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32 core debug reset problem
Hi Chris, I'm not an expert, nor a typical poster on this list, but have you properly configured the DBGMCU_CR register to allow debugging support while the STM32 is in STOP mode? Best, Kyle On Fri, Oct 29, 2010 at 2:58 PM, Chris Jones ch...@martin-jones.com wrote: Hi all, I'm using OpenOCD (version 0.4.0, downloaded from SourceForge and built about half an hour ago) on Debian Lenny (5.0, stable) running under VMWare Fusion on an x86 Mac Pro. The microcontroller I'm using is an STM32F103C6T6, and the JTAG dongle is an Amontec JTAGKey. By and large it works: I can program the flash, halt, use gdb, all the things I'd expect from OpenOCD. But there's a way of breaking it semi-permanently. The application on the STM32 is one which spends most of its time with the CPU in Stop mode, waking up periodically (about every 12ms) via an RTC interrupt to do some processing. If I attempt to start OpenOCD while the microcontroller is stopping and running like this, I get messages which say, Warn : Timeout (1000ms) waiting for ACK=OK/FAULT in JTAG-DP transaction and OpenOCD just won't work, though it finds the TAPs correctly so the JTAG hardware is clearly working to some extent. The whole JTAG system appears to be then stuck in this state. Restarting OpenOCD, doing a hardware system reset on the microcontroller, unplugging everything including the JTAG dongle and its USB interface, all make no difference. I've even tried exercising the JTAG port using another application (XJTAG) though this only does boundary scan testing and doesn't play with the ARM debug TAP. Though boundary scan works fine. The only thing which fixes the problem is power-cycling the STM32 chip itself. I note from its documentation and the ARM Cortex-M3 TRM that some parts of the core debug unit are only reset at power up, not in response to a system reset. The device has no TRST pin. However, this board is going to be permanently moulded into a plastic lump with a battery, so power cycling it is *not* an option. Am I stuck? Or is there a way of finding out how the Cortex-M3 debug unit is wedged, if that's the case, and tickling it back to life? Thank you Chris -- Chris Jones - ch...@martin-jones.com Martin-Jones Technology Ltd 148 Catharine Street, Cambridge, CB1 3AR, UK Phone +44 (0) 1223 655611 Fax +44 (0) 870 112 3908 ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32 core debug reset problem
On Fri, Oct 29, 2010 at 8:58 PM, Chris Jones ch...@martin-jones.com wrote: Hi all, I'm using OpenOCD (version 0.4.0, downloaded from SourceForge and built about half an hour ago) on Debian Lenny (5.0, stable) running under VMWare Fusion on an x86 Mac Pro. The microcontroller I'm using is an STM32F103C6T6, and the JTAG dongle is an Amontec JTAGKey. By and large it works: I can program the flash, halt, use gdb, all the things I'd expect from OpenOCD. But there's a way of breaking it semi-permanently. The application on the STM32 is one which spends most of its time with the CPU in Stop mode, waking up periodically (about every 12ms) via an RTC interrupt to do some processing. If I attempt to start OpenOCD while the microcontroller is stopping and running like this, I get messages which say, Warn : Timeout (1000ms) waiting for ACK=OK/FAULT in JTAG-DP transaction and OpenOCD just won't work, though it finds the TAPs correctly so the JTAG hardware is clearly working to some extent. The whole JTAG system appears to be then stuck in this state. Restarting OpenOCD, doing a hardware system reset on the microcontroller, unplugging everything including the JTAG dongle and its USB interface, all make no difference. I've even tried exercising the JTAG port using another application (XJTAG) though this only does boundary scan testing and doesn't play with the ARM debug TAP. Though boundary scan works fine. The only thing which fixes the problem is power-cycling the STM32 chip itself. I note from its documentation and the ARM Cortex-M3 TRM that some parts of the core debug unit are only reset at power up, not in response to a system reset. The device has no TRST pin. However, this board is going to be permanently moulded into a plastic lump with a battery, so power cycling it is *not* an option. Am I stuck? Or is there a way of finding out how the Cortex-M3 debug unit is wedged, if that's the case, and tickling it back to life? The debug unit is clocked by the core clock. So, naturally, when you stop the core clock you'll lose all debug access. There's nothing OpenOCD can do about it. As Kyle said, you can flip some bits in DBGMCU_CR to keep the debug unit clocked even in sleep modes. That will enable you to debug but of course it will also drain your battery. One can also ponder why you need debug access to something molded in plastic... Wouldn't it be better to debug your application on a more lab-friendly setup? //Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 1/3] CortexA8: Setup debug_base according to variant
On Friday 29 October 2010 09:37:36 Øyvind Harboe wrote: Oyvind sorry, I just can't find it ... could you tell me where it is please ? Start here: https://lists.berlios.de/pipermail/openocd-development/2010-September/01648 2.html Hey, I went through all of this stuff tonight ... and I came to a conclusion, that MEM-AP contains register called BASE whose top 20 bytes should contain the debug base address. From my observation, if I run: dap info 1 AP ID register 0x04770002 Type is MEM-AP APB AP BASE 0x8000 ROM table in legacy format CID3 0x00, CID2 0x00, CID1 0x00, CID0 0x00 MEMTYPE System memory not present. Dedicated debug bus. ROMTABLE[0x0] = 0x0 End of ROM table I get no data. Though if I artificially adjust the dbgbase to 0x6000 in arm_adi_v5.c, I get the following stuff. So, is the processor just making fun of me and misreporting the debug base or did I just miss something? This is what I get after the adjustment dap info 1 AP ID register 0x04770002 Type is MEM-AP APB AP BASE 0x6000 ROM table in legacy format CID3 0xb1, CID2 0x05, CID1 0x10, CID0 0x0d MEMTYPE System memory not present. Dedicated debug bus. ROMTABLE[0x0] = 0x1003 Component base address 0x60001000, start address 0x60001000 Component class is 0x9, CoreSight component Type is 0x21, Trace Sink, Buffer Peripheral ID[4..0] = hex 04 00 0b b9 07 Part is Coresight ETB (Trace Buffer) ROMTABLE[0x4] = 0x2003 Component base address 0x60002000, start address 0x60002000 Component class is 0x9, CoreSight component Type is 0x13, Trace Source, Processor Peripheral ID[4..0] = hex 04 10 4b b9 21 Part is Cortex-A8 ETM (Embedded Trace) ROMTABLE[0x8] = 0x3003 Component base address 0x60003000, start address 0x60003000 Component class is 0x9, CoreSight component Type is 0x11, Trace Sink, Port Peripheral ID[4..0] = hex 04 00 4b b9 12 Part is Coresight TPIU (Trace Port Interface Unit) ROMTABLE[0xc] = 0x4003 Component base address 0x60004000, start address 0x60004000 Component class is 0x9, CoreSight component Type is 0x14, Debug Control, Trigger Matrix Peripheral ID[4..0] = hex 04 10 4b b9 22 Part is Cortex-A8 CTI (Cross Trigger) ROMTABLE[0x10] = 0x5003 Component base address 0x60005000, start address 0x60005000 Component class is 0x9, CoreSight component Type is 0x14, Debug Control, Trigger Matrix Peripheral ID[4..0] = hex 04 00 0b b9 06 Part is Coresight CTI (Cross Trigger) ROMTABLE[0x14] = 0x6003 Component base address 0x60006000, start address 0x60006000 Component class is 0x9, CoreSight component Type is 0x14, Debug Control, Trigger Matrix Peripheral ID[4..0] = hex 04 00 0b b9 06 Part is Coresight CTI (Cross Trigger) ROMTABLE[0x18] = 0x7003 Component base address 0x60007000, start address 0x60007000 Component class is 0x9, CoreSight component Type is 0x14, Debug Control, Trigger Matrix Peripheral ID[4..0] = hex 04 00 0b b9 06 Part is Coresight CTI (Cross Trigger) ROMTABLE[0x1c] = 0x8003 Component base address 0x60008000, start address 0x60008000 Component class is 0x9, CoreSight component Type is 0x15, Debug Logic, Processor Peripheral ID[4..0] = hex 04 10 4b bc 08 Part is Cortex-A8 Debug (Debug Unit) ROMTABLE[0x20] = 0x0 End of ROM table ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
