Re: [Openocd-development] Problems with workareasize and STM32F100 (8kB of RAM)
On Tue, Nov 2, 2010 at 5:51 PM, Freddie Chopin freddie_cho...@op.pl wrote: On 2010-10-29 11:21, freddie_cho...@op.pl wrote: 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. Is there really no interest in such change? I saw a long and healthy discussion with some good names, so I figured this issue was well looked after. Perhaps you can provide a patch and / or summarize what the problem is and what your plan / conclusion is in a new thread? -- Ø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
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
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] 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 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
Re: [Openocd-development] Problems with workareasize and STM32F100 (8kB of RAM)
However, I've always thought that OpenOCD somehow finds the amount of RAM that is available on the chip and will not allocate more than is possible? Nope. There is no code in OpenOCD to figure this out. Perhaps it would be a good idea for some target family scripts to have some required options, such as amount of RAM for chip? Perhaps with a default to the minimum possible amount of ram. -- Ø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)
Øyvind Harboe wrote: Perhaps it would be a good idea for some target family scripts to have some required options, such as amount of RAM for chip? Perhaps with a default to the minimum possible amount of ram. Makes sense. I think in general it would be nice to tidy a little in tcl/target/ - sometimes there's a per-chip cfg, other times there's just a family cfg. The latter is great as long as it works, but then it would need to use the least common denominator, which may be a problem for the largest parts in the same family. //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)
On Thu, Oct 28, 2010 at 8:42 AM, Peter Stuge pe...@stuge.se wrote: Øyvind Harboe wrote: Perhaps it would be a good idea for some target family scripts to have some required options, such as amount of RAM for chip? Perhaps with a default to the minimum possible amount of ram. Makes sense. I think in general it would be nice to tidy a little in tcl/target/ - sometimes there's a per-chip cfg, other times there's just a family cfg. The latter is great as long as it works, but then it would need to use the least common denominator, which may be a problem for the largest parts in the same family. Patches welcome! :-) Good target/board scripts can do wonder for the OpenOCD experience... Some scripts are also a lot of work to put together. -- Ø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)
Øyvind Harboe wrote: Perhaps it would be a good idea for some target family scripts to have some required options, such as amount of RAM for chip? Perhaps with a default to the minimum possible amount of ram. Makes sense. I think in general it would be nice to tidy a little in tcl/target/ - sometimes there's a per-chip cfg, other times there's just a family cfg. The latter is great as long as it works, but then it would need to use the least common denominator, which may be a problem for the largest parts in the same family. Patches welcome! :-) Fair enough. Always the tradeoff between using and producing tools. As much as I dislike things ftdi it'd be nice to touch up that driver a little. Going to libftdi-1.0 would be a somewhat major change I think, but small simple fixes might be to get rid of the segfault when JTAG adapter is not plugged, and if the adapter is unplugged while OpenOCD is running then it goes into some loop printing error messages. Anyway, I'd like to do more testing with the Versaloon. Good target/board scripts can do wonder for the OpenOCD experience... Yes, I would even say that they are key. Have to refresh those Tcl skills. Some scripts are also a lot of work to put together. No doubt. Especially if they are to be really generic. //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)
On Wed, Oct 27, 2010 at 10:53 PM, Freddie Chopin freddie_cho...@op.pl wrote: Hi! Someone has asked me for help with using OpenOCD + STM32F100 (8kB of RAM). After some time I've come to conclusion that the problem was caused by incorrect workareasize value, which in stm32.cfg is defined to be 16kB. With std cfg files flashing the device resulted in: Error: JTAG-DP STICKY ERROR Error: MEM_AP_CSW 0x2352, MEM_AP_TAR 0x20002004 Error: JTAG-DP STICKY ERROR Error: MEM_AP_CSW 0x2352, MEM_AP_TAR 0x20002004 Warn : Block write error address 0x20002000, wcount 0xc The flashing actually works, but is extremely slow (rate 200B/s). Changing the workareasize to 2kB helps - everything works normally then. We should probably change it to the least common denominator within the family, which is 8kB (maybe even 6?). Definitely, if you don't see any significant reduction in flashing speed after reducing the workareasize (8kB vs 2kB). That's likely dependent on the adapter in use, of course. However, I've always thought that OpenOCD somehow finds the amount of RAM that is available on the chip and will not allocate more than is possible? Am I wrong? Yes. Early silicon had a SRAM size register in factory programmed ROM but it was later removed for some reason. I don't think OpenOCD used it even when it existed. We could probably determine the size indirectly, maybe from a chip id database, but I think it's just as good to simply provide a minimum safe workareasize and let the user override it if he wishes. //Andreas ___ 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 2010-10-28 19:53, Andreas Fritiofson wrote: We should probably change it to the least common denominator within the family, which is 8kB (maybe even 6?). Definitely, if you don't see any significant reduction in flashing speed after reducing the workareasize (8kB vs 2kB). That's likely dependent on the adapter in use, of course. The smallest RAM capacity in the STM32 family is 4kB. There are like 10 devices with so little RAM available. http://www.st.com/stonline/stappl/st/com/selector/index.html#querycriteria=RNP139=1169.0 I'll try to check the flashing speed with various workareasizes later. Yes. Early silicon had a SRAM size register in factory programmed ROM but it was later removed for some reason. I don't think OpenOCD used it even when it existed. We could probably determine the size indirectly, maybe from a chip id database, but I think it's just as good to simply provide a minimum safe workareasize and let the user override it if he wishes. It's a good idea in my opinion, but I'm not sure whether it's possible - the MCU Device ID register only shows the family (low-, medium-, high-density, connectivity, value, etc.), so that's not enough - maybe checking flash size would allow OpenOCD to determine the RAM size... I'll investigate this more later. 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)
On 2010-10-28 20:15, Freddie Chopin wrote: I'll try to check the flashing speed with various workareasizes later. _WORKAREASIZE 0x4000 (16kB) Start address 0x8000130, load size 129296 Transfer rate: 8 KB/sec, 12929 bytes/write. _WORKAREASIZE 0x1000 (4kB) Start address 0x8000130, load size 129296 Transfer rate: 4 KB/sec, 12929 bytes/write. So there is a decrease... It's a good idea in my opinion, but I'm not sure whether it's possible - the MCU Device ID register only shows the family (low-, medium-, high-density, connectivity, value, etc.), so that's not enough - maybe checking flash size would allow OpenOCD to determine the RAM size... I'll investigate this more later. There are some cases where the amount of available RAM cannot be determined - there are some devices of the same family that have the same flash size but different amount of RAM. E.g.: STM32F105VB (CL), 128kB flash, 32kB RAM STM32F107RB (CL), 128kB flash, 48kB RAM However, that is enough to determine max amount of RAM with small error - there are such pairs with (more or less) adjacent amounts of ram (4/6, 6/10, 32/48, 48/64, etc.). I'd even like to do that, but the mechanics of OpenOCD is still a big mystery for me - in stm32x_write_block() (stm32x.c) the buffer size to be allocated is fixed at 16kB, and this file does nothing with workareasize defined in cfg files (I think...). What is the reason to use fixed buffer size of 16kB? Shouldn't that be changed as there are chips with more RAM and those could benefit from higher workareasize (I cannot check, I only have chips with 20kB of RAM). 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 target - st - stm32 stm32f103rb.cfg stm32f105v8.cfg ... - str7 str710.cfg str711.cfg ... - str9 ... - nxp - lpc17xx ... - lpc2xxx ... and so on. I think that would improve the OpenOCD experience for the users... It's still not very user-friendly ); I could try to do some patches, but I'd first like to hear your opinions. 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 Chopin wrote: 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. 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. The structure of the target folder could be changed to target - st - stm32 stm32f103rb.cfg stm32f105v8.cfg ... - str7 str710.cfg str711.cfg ... - str9 ... - nxp - lpc17xx ... - lpc2xxx ... and so on. Too many levels IMO. Just put stm32, str7, str9 directly under target. I don't know the ST parts, but I like NXP a lot and I've started looking at the TI LM3S (I think we should rename the files from stellaris) which also look nice. Have a look at stellaris.cfg, which seems to be generic for that family. I think that would improve the OpenOCD experience for the users... Yes and no. I think that it's really nice to only need to specify the family of chips that you're working with. It's still not very user-friendly ); 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. If there isn't one already then I think an example on the web would go a long way. Do we have a wiki? //Peter ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Problems with workareasize and STM32F100 (8kB of RAM)
Hi! Someone has asked me for help with using OpenOCD + STM32F100 (8kB of RAM). After some time I've come to conclusion that the problem was caused by incorrect workareasize value, which in stm32.cfg is defined to be 16kB. With std cfg files flashing the device resulted in: Error: JTAG-DP STICKY ERROR Error: MEM_AP_CSW 0x2352, MEM_AP_TAR 0x20002004 Error: JTAG-DP STICKY ERROR Error: MEM_AP_CSW 0x2352, MEM_AP_TAR 0x20002004 Warn : Block write error address 0x20002000, wcount 0xc The flashing actually works, but is extremely slow (rate 200B/s). Changing the workareasize to 2kB helps - everything works normally then. However, I've always thought that OpenOCD somehow finds the amount of RAM that is available on the chip and will not allocate more than is possible? Am I wrong? Here is the relevant part of -d 3 log for workareasize that is way over the available RAM: Debug: 570 5594 target.c:1125 target_alloc_working_area_try(): MMU disabled, using physical address for working memory 0x2000 Debug: 571 5594 target.c:1185 target_alloc_working_area_try(): allocated new working area at address 0x2000 Debug: 572 5594 target.c:1315 target_write_buffer(): writing buffer of 48 byte at 0x2000 Debug: 573 5594 target.c:1185 target_alloc_working_area_try(): allocated new working area at address 0x2030 Debug: 574 5594 target.c:1315 target_write_buffer(): writing buffer of 8192 byte at 0x2030 Debug: 575 5735 adi_v5_jtag.c:266 jtagdp_transaction_endcheck(): jtag-dp: CTRL/STAT error, 0xf021 Error: 576 5735 adi_v5_jtag.c:296 jtagdp_transaction_endcheck(): JTAG-DP STICKY ERROR Debug: 577 5750 adi_v5_jtag.c:312 jtagdp_transaction_endcheck(): jtag-dp: CTRL/STAT 0xf001 Error: 578 5750 adi_v5_jtag.c:327 jtagdp_transaction_endcheck(): MEM_AP_CSW 0x2352, MEM_AP_TAR 0x20002004 Debug: 579 5750 adi_v5_jtag.c:266 jtagdp_transaction_endcheck(): jtag-dp: CTRL/STAT error, 0xf021 Error: 580 5750 adi_v5_jtag.c:296 jtagdp_transaction_endcheck(): JTAG-DP STICKY ERROR Debug: 581 5766 adi_v5_jtag.c:312 jtagdp_transaction_endcheck(): jtag-dp: CTRL/STAT 0xf001 Error: 582 5766 adi_v5_jtag.c:327 jtagdp_transaction_endcheck(): MEM_AP_CSW 0x2352, MEM_AP_TAR 0x20002004 Warn : 583 5766 arm_adi_v5.c:337 mem_ap_write_buf_u32(): Block write error address 0x20002000, wcount 0xc Any ideas? 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
