Re: [Openocd-development] STM32 reset_config
On 11/11/2010 23:26, Peter Stuge wrote: Freddie Chopin wrote: according to OpenOCD (brilliant) policy of target config files I think it would be great if you stopped complaining using sarcasm and instead help analyze and improve. I think you have a lot of experience that is valuable. The policy stuff is nonsense. If there is a compelling argument then anything and everything will change. In particular if you do it yourself. :) But to make sure that time isn't spent in vain it's very wise to do as you have already done; discuss first. The cortex-m3 reset_config command gets priority (that's my understanding...), I also don't know for sure how this works, but I would assume that a later config file can override an earlier one? and if soft-reset method is selected, real reset will never be used, no matter that it's the best solution. That's obviously useless. Needs to be fixed then. If the board has a reset_config of for example srst_only then that will be used whatever the setting of cortex_m3 reset_config. Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32 reset_config
On 12/11/2010 10:33, Spencer Oliver wrote: On 11/11/2010 23:26, Peter Stuge wrote: Freddie Chopin wrote: according to OpenOCD (brilliant) policy of target config files I think it would be great if you stopped complaining using sarcasm and instead help analyze and improve. I think you have a lot of experience that is valuable. The policy stuff is nonsense. If there is a compelling argument then anything and everything will change. In particular if you do it yourself. :) But to make sure that time isn't spent in vain it's very wise to do as you have already done; discuss first. The cortex-m3 reset_config command gets priority (that's my understanding...), I also don't know for sure how this works, but I would assume that a later config file can override an earlier one? and if soft-reset method is selected, real reset will never be used, no matter that it's the best solution. That's obviously useless. Needs to be fixed then. If the board has a reset_config of for example srst_only then that will be used whatever the setting of cortex_m3 reset_config. Mmm - Think i may be incorrect here, the cortex_m3 reset_config does override the standard reset_config. Looking back this was done so it did not break any stellaris scripts that define reset config. Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32 reset_config
On 2010-11-12 12:16, Spencer Oliver wrote: Mmm - Think i may be incorrect here, the cortex_m3 reset_config does override the standard reset_config. Looking back this was done so it did not break any stellaris scripts that define reset config. Would that be enough to change behavior so that hardware reset would be used if available, no matter what option of cortex-m3 reset_config was selected? Option to select srst may be then removed, and this command could be renamed to soft_reset_config. Another solution is to change cortex-m3 reset_config to capabilities model - you list all supported reset options, OpenOCD selects what's best. For example cortex-m3 reset_config srst sysresetreq vectreset would define a chip that can use any method - if srst is available, use that, else use sysresetreq. cortex-m3 reset_config srst vectreset would define a chip that does not handle sysresetreq, so in case of lack of srst, use vectreset. As it's hard to imagine a chip that has no srst, that option can be removed too, and command renamed some way. What do you think? 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32 reset_config
--- On Fri, 11/12/10, Freddie Chopin freddie_cho...@op.pl wrote: it's hard to imagine a chip that has no srst, As for boards or JTAG adapters without nSRST, no imagination is required; I have production boards of both flavors. that option can be removed Shouldn't be, though; that'd be very unwise. - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32 reset_config
David Brownell wrote: --- On Fri, 11/12/10, Freddie Chopin freddie_cho...@op.pl wrote: it's hard to imagine a chip that has no srst, As for boards or JTAG adapters without nSRST, no imagination is required; I have production boards of both flavors. Very true, but I think part of the current confusion is due to combination of reset properties of CPU cores and reset properties of boards and interfaces into the same variable, which I think we must avoid going forward. that option can be removed Shouldn't be, though; that'd be very unwise. I think the point is that we should give openocd the information it needs so that it can know when srst is really usable, and not. I completely agree with the model Freddie outlined, of having capabilities for each component involved, and openocd finding the cross-section of those capabilities. I think we should try to take small steps in that direction. Having a specific soft-reset config might be a good first step. //Peter ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32 reset_config
On 2010-11-12 18:27, Peter Stuge wrote: David Brownell wrote: As for boards or JTAG adapters without nSRST, no imagination is required; I have production boards of both flavors. Show my an example of any _normal_ JTAG interface that does not have srst? As for the second case, OpenOCD's main purpose is debugging, not programming, so production boards are not very interesting here. Shouldn't be, though; that'd be very unwise. What's the purpose of that option? If user desires a reset, best reset method should be used, and there is no better reset method than hardware SRST reset. If one wishes to use only software resets, than one can remove reset_config command or change it to none - now we have two commands that overlap. 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32 reset_config
Freddie Chopin wrote: On 2010-11-12 18:27, Peter Stuge wrote: David Brownell wrote: As for boards or JTAG adapters without nSRST, no imagination is required; I have production boards of both flavors. Show my an example of any _normal_ JTAG interface that does not have srst? I'm sure there are many stupid interfaces like that. We should still be able to use them as well as possible with their limited capabilities.. As for the second case, OpenOCD's main purpose is debugging, not programming, so production boards are not very interesting here. I disagree there, since openocd can easily be automated and customized I think it is also useful for programming. (E.g. the NXP+FPGA chain from just a few days ago.) But it doesn't change our problem; we need a data model that allows a meaningful decision tree in openocd. Limitations of one board or interface should not affect another with more capabilities. //Peter ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32 reset_config
Show my an example of any _normal_ JTAG interface that does not have srst? Depends entirely on what you mean by normal, doesn't it? All I can say is that I've come across non-prototype boards that don't rely on that signal, and thus don't provide JTAG support for it. That is, boards targetted at software developers, so normal in that sense ... and produced in volumes of at least hundreds if not much more. production boards are not very interesting here. You're reading the wrong things into that word. Production contrasts in my mind with one-off prototype ... a development board can be production, and many are. There's also embed-in-end-user-product type production boards, that may not even have JTAG. (Maybe odd form factors, extremely size and cost reduced, and so forth. That's not what I was describing. - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32 reset_config
On 11/12/2010 06:40 PM, Freddie Chopin wrote: Show my an example of any _normal_ JTAG interface that does not have srst? As for the second case, OpenOCD's main purpose is debugging, not programming, so production boards are not very interesting here. At least the Xilinx JTAG cables have no reset outputs, and I think the Altera cables are in the same category. Classical JTAG only needs four wires, so assuming that every JTAG cable should have some kind of reset capability is plain wrong. cu Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32 reset_config
On Wed, Nov 10, 2010 at 11:10 PM, David Brownell davi...@pacbell.net wrote: Today I've noticed that resetting the chip with OpenOCD does NOT reset peripheals (the chip is STM32F103RBT8), which IMO is not very good... Not all SoCs reset peripherals like that; don't assume they do. Likewise, not all boards. - Dave It's not an assumption, it's in the manual. Do you have an example of a microcontroller which doesn't reset the bulk of the peripherals on a NRST or equivalent? This is somewhat of a regression, since in 0.4.0, the STM32 (and likely other cortex-m3) peripherals were being reset when a (soft or hard) reset was issued from OpenOCD. Now they're suddenly not when the default configs are used. /Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32 reset_config
--- On Thu, 11/11/10, Andreas Fritiofson andreas.fritiof...@gmail.com wrote: It's not an assumption, it's in the manual. Do you have an example of a microcontroller which doesn't reset the bulk of the peripherals on a NRST or equivalent? Not handy, no; it surprised me too. ISTR there was a register controlling this behavior, and it seemed to be part of debug support. On the other hand, some non-microcontroller SoCs I've used take a different approach and have a formal controller dedicated to reset handling, which doesn't hook up to NSRST but offers per-peripheral controls over reset sequencing. On those SoCs, NSRST isn't a very widely used signal; affects only CPU cores. Debuggers and boot code are expected to talk to the reset controller as needed during bringup. - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32 reset_config
On 11/11/2010 05:01, Peter Stuge wrote: Spencer Oliver wrote: The default behaviour was changed to make it compatible with all cortex-m3 cores - will have to check but some stm32 and nxp parts had issues using SYSTEMRESET. Please give more detail about those nxp parts? All LPC17xx devices according to docs: This is intended to force a large system reset of all major components except for debug. Note: support for SYSRESETREQ is not included in LPC17xx devices. http://www.nxp.com/documents/user_manual/UM10360.pdf page 769 This is why VECTRESET was chosen as the safe default on all cortexm3 cores. Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32 reset_config
Hi! I've thought about that whole patch which adds cortex-m3 reset_config command and I think it's not very good now (if I correctly understand its behavior). Let's say, that there is a chip which has some problems with SYSRESETREQ, so the target config file forces VECTRESET (which is not a perfect solution, as it does not reset peripherals). Now - according to OpenOCD (brilliant) policy of target config files - there is no reset_config command in this file. As 99% of chips and boards on this planet do have resets wired up properly, user can specify reset_config on his/her own, but what for? The cortex-m3 reset_config command gets priority (that's my understanding...), and if soft-reset method is selected, real reset will never be used, no matter that it's the best solution. And again we are back to overriding mysterious configuration options by an inexperienced user who just wants to do some simple debugging on some simple microcontroller... 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32 reset_config
Freddie Chopin wrote: according to OpenOCD (brilliant) policy of target config files I think it would be great if you stopped complaining using sarcasm and instead help analyze and improve. I think you have a lot of experience that is valuable. The policy stuff is nonsense. If there is a compelling argument then anything and everything will change. In particular if you do it yourself. :) But to make sure that time isn't spent in vain it's very wise to do as you have already done; discuss first. The cortex-m3 reset_config command gets priority (that's my understanding...), I also don't know for sure how this works, but I would assume that a later config file can override an earlier one? and if soft-reset method is selected, real reset will never be used, no matter that it's the best solution. That's obviously useless. Needs to be fixed then. //Peter ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32 reset_config
On 2010-11-12 00:26, Peter Stuge wrote: Freddie Chopin wrote: according to OpenOCD (brilliant) policy of target config files I think it would be great if you stopped complaining using sarcasm and instead help analyze and improve. I think you have a lot of experience that is valuable. The policy stuff is nonsense. If there is a compelling argument then anything and everything will change. In particular if you do it yourself. :) I've tried many times, even recently - no interest in changing the status quo, discussion went on about implementing auto-discovery in OpenOCD. https://lists.berlios.de/pipermail/openocd-development/2010-November/016872.html But to make sure that time isn't spent in vain it's very wise to do as you have already done; discuss first. I always do. The cortex-m3 reset_config command gets priority (that's my understanding...), I also don't know for sure how this works, but I would assume that a later config file can override an earlier one? Imagine such case: target file defines no hardware resets and selects vectreset as the soft-reset method, as sysresetreq does not work. your file defines hardware resets effect - hardware resets are not used, vectreset is forced. To use hardware reset you have to add cortex-m3 reset_config srst. and if soft-reset method is selected, real reset will never be used, no matter that it's the best solution. That's obviously useless. Needs to be fixed then. But what would be the best solution? 4\/3!! ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32 reset_config
On Wed, Nov 10, 2010 at 6:50 PM, Freddie Chopin freddie_cho...@op.pl wrote: Hi! I've doubts about this commit http://openocd.git.sourceforge.net/git/gitweb.cgi?p=openocd/openocd;a=commit;h=85944d4144a1df0647e4324d1cf8ae9a276b70e5 Today I've noticed that resetting the chip with OpenOCD does NOT reset peripheals (the chip is STM32F103RBT8), which IMO is not very good... Do you think this patch should be reverted? Are there any important reasons to not have reset_config in stm32.cfg as in many other target cfg files? I don't think this specific patch is the problem. I've run with 'reset_config none' for a long time without any trouble. Before this patch there were a bunch of reset issues. Please don't revert it. Besides, having reset signals wired is optional and a board/adapter level decision, and should not be specified in the target file. If the peripherals are not getting reset I suspect some other patch has sneaked in that changed the soft reset behavior from a real reset to a core only reset. Perhaps to fix issues with other Cortex-M3 implementations. I haven't run HEAD for a while, but if I find some time I'll try to confirm and locate the problem. Regards, Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32 reset_config
On Wed, Nov 10, 2010 at 7:47 PM, Andreas Fritiofson andreas.fritiof...@gmail.com wrote: On Wed, Nov 10, 2010 at 6:50 PM, Freddie Chopin freddie_cho...@op.pl wrote: Hi! I've doubts about this commit http://openocd.git.sourceforge.net/git/gitweb.cgi?p=openocd/openocd;a=commit;h=85944d4144a1df0647e4324d1cf8ae9a276b70e5 Today I've noticed that resetting the chip with OpenOCD does NOT reset peripheals (the chip is STM32F103RBT8), which IMO is not very good... Do you think this patch should be reverted? Are there any important reasons to not have reset_config in stm32.cfg as in many other target cfg files? I don't think this specific patch is the problem. I've run with 'reset_config none' for a long time without any trouble. Before this patch there were a bunch of reset issues. Please don't revert it. Besides, having reset signals wired is optional and a board/adapter level decision, and should not be specified in the target file. If the peripherals are not getting reset I suspect some other patch has sneaked in that changed the soft reset behavior from a real reset to a core only reset. Perhaps to fix issues with other Cortex-M3 implementations. I haven't run HEAD for a while, but if I find some time I'll try to confirm and locate the problem. Without having tested it, commit 3c69eee9 seems to be the problem. While it's good that the reset type is now configurable, changing the default behavior wasn't perhaps the best idea. It would have been better to keep SYSRESETREQ as the default and change it in the configs for cores that haven't wired it up to the master reset. Regards, Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32 reset_config
On 10/11/2010 19:01, Andreas Fritiofson wrote: On Wed, Nov 10, 2010 at 7:47 PM, Andreas Fritiofson andreas.fritiof...@gmail.com wrote: On Wed, Nov 10, 2010 at 6:50 PM, Freddie Chopinfreddie_cho...@op.pl wrote: Hi! I've doubts about this commit http://openocd.git.sourceforge.net/git/gitweb.cgi?p=openocd/openocd;a=commit;h=85944d4144a1df0647e4324d1cf8ae9a276b70e5 Today I've noticed that resetting the chip with OpenOCD does NOT reset peripheals (the chip is STM32F103RBT8), which IMO is not very good... Do you think this patch should be reverted? Are there any important reasons to not have reset_config in stm32.cfg as in many other target cfg files? I don't think this specific patch is the problem. I've run with 'reset_config none' for a long time without any trouble. Before this patch there were a bunch of reset issues. Please don't revert it. Besides, having reset signals wired is optional and a board/adapter level decision, and should not be specified in the target file. If the peripherals are not getting reset I suspect some other patch has sneaked in that changed the soft reset behavior from a real reset to a core only reset. Perhaps to fix issues with other Cortex-M3 implementations. I haven't run HEAD for a while, but if I find some time I'll try to confirm and locate the problem. Without having tested it, commit 3c69eee9 seems to be the problem. While it's good that the reset type is now configurable, changing the default behavior wasn't perhaps the best idea. It would have been better to keep SYSRESETREQ as the default and change it in the configs for cores that haven't wired it up to the master reset. The default behaviour was changed to make it compatible with all cortex-m3 cores - will have to check but some stm32 and nxp parts had issues using SYSTEMRESET. I think it would be good for openocd to have knowledge of what core can handle certain reset modes. Cheers Spen ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32 reset_config
The default behaviour was changed to make it compatible with all cortex-m3 cores - will have to check but some stm32 and nxp parts had issues using SYSTEMRESET. I think it would be good for openocd to have knowledge of what core can handle certain reset modes. We have already gone down this path with success on Cortex A8 where there is a hack for an iMX51 part for the debug offset. This target specific code could either be in OpenOCD or perhaps better in the config files? -- Øyvind Harboe Can Zylin Consulting help on your project? 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] STM32 reset_config
On Wed, Nov 10, 2010 at 10:15 PM, Øyvind Harboe oyvind.har...@zylin.com wrote: Spencer Oliver s...@spen-soft.co.uk wrote: The default behaviour was changed to make it compatible with all cortex-m3 cores - will have to check but some stm32 and nxp parts had issues using SYSTEMRESET. I believe STM32 does what it is supposed to, I've never had issues with it. Code comments mentions some Stellaris parts only. Regardless, I feel that having a working SYSRESETREQ should be norm, and broken silicon worked around in the respective config file. I think it would be good for openocd to have knowledge of what core can handle certain reset modes. We have already gone down this path with success on Cortex A8 where there is a hack for an iMX51 part for the debug offset. This target specific code could either be in OpenOCD or perhaps better in the config files? In this case, one line of tcl overrides the default setting, so it's perfectly suited for the config files. /Andreas ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32 reset_config
Today I've noticed that resetting the chip with OpenOCD does NOT reset peripheals (the chip is STM32F103RBT8), which IMO is not very good... Not all SoCs reset peripherals like that; don't assume they do. Likewise, not all boards. - Dave ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] STM32 reset_config
Spencer Oliver wrote: The default behaviour was changed to make it compatible with all cortex-m3 cores - will have to check but some stm32 and nxp parts had issues using SYSTEMRESET. Please give more detail about those nxp parts? //Peter ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
