Re: [Openocd-development] STM32 core debug reset problem
On 04/11/2010 21:35, Andreas Fritiofson wrote: On Wed, Nov 3, 2010 at 10:01 AM, Chris Jonesch...@martin-jones.com wrote: I tried the IAR software but don't have a JTAG dongle directly compatible with it. I tried to get it to talk to OpenOCD via GDB but attempting to download the code to the STM32 that way just resulted in streams of errors. I didn't spend any more time on this because I don't think it would help to isolate the issue into or out of OpenOCD. There seem to be some circumstances in which attempting to start OpenOCD connected to an STM32 in stop mode, or switching rapidly into and out of stop mode, breaks the STM32's debug unit. It's consistently repeatable. For now we can work around it by being extremely careful when we try to connect OpenOCD, but I'd like to try and help prevent the problem. I agree with Michel that the first step towards that is probably to determine whether the problem has a reasonable chance of being fixable in OpenOCD. Otherwise it's a waste of time trying to. We could try completely different tools to see if they have the same problem. We can also ask ST (having tried different tools would help here, too). Maybe someone on the list has the tools and the time required. Unfortunately, I have neither right now. I've now spent some more time looking at this problem and have been digging around in arm_adi_v5.c to see what's going on. In the fault condition, even the first few operations in ahbap_debugport_init() don't seem to work. For example, reading the DP_CTRL_STAT register always returns 0. There's a loop which waits for the CDBGPWRUPACK bit in that register to be set. It never gets set in the fault condition, but the loop exits anyway and execution continues. I think this is a bug, but it doesn't affect the fault other than not reporting it. There is an ABORT instruction in a special DR register (*not* one of the DPACC registers) which looks useful in potentially returning the debug unit to a sane state, or at least cancelling any outstanding debug transactions, but until I've got my head around how to make the necessary JTAG operation I can't get it to do anything. I wanted to add some more basic tests of DR register reads other than the DPACC registers to check what was going on, and thought the IDCODE DR register would be a good start. I added: adi_jtag_dp_scan_u32(swjdp, JTAG_DP_IDCODE, DP_IDCODE, DPAP_READ, 0, dummy, ack); LOG_DEBUG(ahbap_debugport_init(): idcode=0x% PRIx32, dummy); but this seems to return 0x16 in dummy, which is nothing like the IDCODE in the ARM/ST documentation (0x3BA00477). This happens on 'working' STM32s and in the fault condition. Am I doing something daft? Can some kind soul help me navigate the various functions, please? I'm happy to spend the time investigating what's going on when armed with the necessary knowledge. 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
On 23/11/2010 18:21, Chris Jones wrote: I've now spent some more time looking at this problem and have been digging around in arm_adi_v5.c to see what's going on. In the fault condition, even the first few operations in ahbap_debugport_init() don't seem to work. For example, reading the DP_CTRL_STAT register always returns 0. There's a loop which waits for the CDBGPWRUPACK bit in that register to be set. It never gets set in the fault condition, but the loop exits anyway and execution continues. I think this is a bug, but it doesn't affect the fault other than not reporting it. I mentioned this before but you never replied. Have you tried slowing down the jtag clock, eg 1kHz or even less. Last time i debugged a target that used wfe a lot all worked fine as long as the jtag clock was very slow. Cheers Spen ___ 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
2010/10/31 Michel Catudal michelcatu...@gmail.com: Le 2010-10-29 19:15, Andreas Fritiofson a écrit : 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? A production unit that is to be protected from the environment must be molded into something. We would never use plastic in most application but the end result would be the same. I do agree that molded in plastic is strange but what difference would it make as for software is concerned? It's not the plastic mold that's strange, it's the desire to _debug_ software on a production unit, permanently sealed or not. Debugging is software development, which is more comfortably done on a lab unit which can be probed and measured (and, in the best of worlds, preferably _before_ production even starts). Most designs nowadays require reflashing at one time or another. Most of us in the industry no long use mask rom. Why do you think that we would want simulated mask rom? I didn't say that. You're talking about in-system programming, not debugging. ISP (or reflashing) is often possible over the debug access port, but it's not always the only option and seldom the most practical one. A better alternative, especially for a sealed product, is to use a preprogrammed boot loader operating over some other communication channel present in the product. I'm guessing that would have been Chris' first choice, had this particular boot loader of his not been broken. Regards, Andreas ___ 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 Wed, Nov 3, 2010 at 10:01 AM, Chris Jones ch...@martin-jones.com wrote: I tried the IAR software but don't have a JTAG dongle directly compatible with it. I tried to get it to talk to OpenOCD via GDB but attempting to download the code to the STM32 that way just resulted in streams of errors. I didn't spend any more time on this because I don't think it would help to isolate the issue into or out of OpenOCD. There seem to be some circumstances in which attempting to start OpenOCD connected to an STM32 in stop mode, or switching rapidly into and out of stop mode, breaks the STM32's debug unit. It's consistently repeatable. For now we can work around it by being extremely careful when we try to connect OpenOCD, but I'd like to try and help prevent the problem. I agree with Michel that the first step towards that is probably to determine whether the problem has a reasonable chance of being fixable in OpenOCD. Otherwise it's a waste of time trying to. We could try completely different tools to see if they have the same problem. We can also ask ST (having tried different tools would help here, too). Maybe someone on the list has the tools and the time required. Unfortunately, I have neither right now. Regards, Andreas ___ 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
Le 2010-11-04 17:10, Andreas Fritiofson a écrit : 2010/10/31 Michel Catudalmichelcatu...@gmail.com: Le 2010-10-29 19:15, Andreas Fritiofson a écrit : 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? A production unit that is to be protected from the environment must be molded into something. We would never use plastic in most application but the end result would be the same. I do agree that molded in plastic is strange but what difference would it make as for software is concerned? It's not the plastic mold that's strange, it's the desire to _debug_ software on a production unit, permanently sealed or not. Debugging is software development, which is more comfortably done on a lab unit which can be probed and measured (and, in the best of worlds, preferably _before_ production even starts). You didn't think this one thru. There is debugging during development but also during manufacturing. Usually even when the package is sealed we leave connections for debugging. What would you need to do if you have a recall of a product and you need to figure out what is wrong with your software? It is not always a hardware issue where you just swap units. Even in the cases where you have to disable jtag for units shipped it is nice to be able to debug with units almost identical to what is in the field. We only debug on prototypes before the production cycle. Once units are in production prototypes cannot be used to debug. Also, the final debug phase is always done on production units since we need to work with the real stuff. If you need high security you need to disable jtag after all your test. It would then be impossible to debug returned units but you still have similar units where you could try to simulate the issues that occured in the field. If you'd ever worked for the military you would realize that you need to have answers that the big brass will believe if you get a FUBAR or SNAFU. Michel Michel -- Tired of Microsoft's rebootive multitasking? then it's time to upgrade to Linux. http://home.comcast.net/~mcatudal ___ 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 31/10/2010 13:40, Michel Catudal wrote: Le 2010-10-30 04:20, Chris Jones a écrit : I'd like to work out whether the debug unit really does break, or whether there's just a misunderstanding about state between it and OpenOCD. Wouldn't pulling the boot pin and send the reset core work? I would suggest to use the IAR limited version with a small version of the code and try it out. You are limited at 32k with that version. You could also ask for a one month try out. With IAR you can use openocd or the manufacturer's code. Thanks to Michel for this suggestion and Andreas for pointing out DBGMCU_CR. Forcing the debug unit clock enable in stop mode completely cures this problem, but has an unacceptable effect on power consumption (as expected). It's fine for bench development purposes, though, so that's a useful step forward. I tried the IAR software but don't have a JTAG dongle directly compatible with it. I tried to get it to talk to OpenOCD via GDB but attempting to download the code to the STM32 that way just resulted in streams of errors. I didn't spend any more time on this because I don't think it would help to isolate the issue into or out of OpenOCD. There seem to be some circumstances in which attempting to start OpenOCD connected to an STM32 in stop mode, or switching rapidly into and out of stop mode, breaks the STM32's debug unit. It's consistently repeatable. For now we can work around it by being extremely careful when we try to connect OpenOCD, but I'd like to try and help prevent the problem. 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
On 30/10/2010 09:20, Chris Jones wrote: On 30/10/2010 00:15, Andreas Fritiofson wrote: On Fri, Oct 29, 2010 at 8:58 PM, Chris Jonesch...@martin-jones.com wrote: 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. Thanks for the hint about DBGMCU_CR. I didn't know that, and it could prove useful. However, I don't actually want to debug in stop mode. One thing I failed to mention is that, after a system reset, the firmware puts the STM32 in run mode until it's sent a command over USB putting it into the stop/wake cycle. During this time in run mode, debugging normally works fine. The problem is that after even one attempt at debugging during stop mode, the debug unit appears permanently broken and doesn't work in *run* mode any more. Only power-cycling the STM32 fixes it. Pulling BOOT0 high during reset and sending the STM32 into its bootstrap loader doesn't help either. stop mode debugging (wfe) works fine for me if i reduce the jtag clock to something like 1kHz, but try even lower if you still have problems. Cheers Spen ___ 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
Le 2010-10-29 19:15, Andreas Fritiofson a écrit : On Fri, Oct 29, 2010 at 8:58 PM, Chris Jonesch...@martin-jones.com wrote: 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? Would it reset differently if you play with the boot pin? 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? A production unit that is to be protected from the environment must be molded into something. We would never use plastic in most application but the end result would be the same. I do agree that molded in plastic is strange but what difference would it make as for software is concerned? Most designs nowadays require reflashing at one time or another. Most of us in the industry no long use mask rom. Why do you think that we would want simulated mask rom? It is a legitimate concern and probably needs to be answered but I think that STMicro is probably the best source for a response. -- Tired of Microsoft's rebootive multitasking? then it's time to upgrade to Linux. http://home.comcast.net/~mcatudal ___ 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
Le 2010-10-30 04:20, Chris Jones a écrit : I'd like to work out whether the debug unit really does break, or whether there's just a misunderstanding about state between it and OpenOCD. Wouldn't pulling the boot pin and send the reset core work? I would suggest to use the IAR limited version with a small version of the code and try it out. You are limited at 32k with that version. You could also ask for a one month try out. With IAR you can use openocd or the manufacturer's code. It is not the default in IAR but there is an option to send the reset core command to the processor before attempting to load the code. What I found out was that if I had DMA enabled part of the code would be trashed on power up. Debug wouldn't work because it would crash. Once I put my bootloader the checksum would always fail and that is when I found out that one area of RAM was being wiped out, code common between the ADC DMA and RAM area used by the IAR reflashing program. After I enabled the reset core everything worked fine. I use the bootloader to reflash code in the field connecting on the OBD or other diagnostic port. I use J-Link. Michel Catudal -- Tired of Microsoft's rebootive multitasking? then it's time to upgrade to Linux. http://home.comcast.net/~mcatudal ___ 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 30/10/2010 00:15, Andreas Fritiofson wrote: On Fri, Oct 29, 2010 at 8:58 PM, Chris Jones ch...@martin-jones.com wrote: 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. Thanks for the hint about DBGMCU_CR. I didn't know that, and it could prove useful. However, I don't actually want to debug in stop mode. One thing I failed to mention is that, after a system reset, the firmware puts the STM32 in run mode until it's sent a command over USB putting it into the stop/wake cycle. During this time in run mode, debugging normally works fine. The problem is that after even one attempt at debugging during stop mode, the debug unit appears permanently broken and doesn't work in *run* mode any more. Only power-cycling the STM32 fixes it. Pulling BOOT0 high during reset and sending the STM32 into its bootstrap loader doesn't help either. 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? Good point! This is about firmware upgrades in the field as much as anything. Ideally I'd have liked to use the serial bootstrap loader for doing that simply, but we have more than a hundred of these devices with an error in the hardware which means that the USART connection to the outside world is broken. No problem, I thought, we'll just use JTAG. I'd like to work out whether the debug unit really does break, or whether there's just a misunderstanding about state between it and OpenOCD. 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] 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
