Tauno Voipio wrote:> On 4.3.15 16:17, Les Cargill wrote: >> Tim Wescott wrote: >>> On Tue, 03 Mar 2015 22:27:40 +0200, Tauno Voipio wrote: >>> >>>> On 3.3.15 21:50, rickman wrote: > >>>> It seems to be a common ARM problem. At least in ARM7TDMI and Cortex-M, >>>> the JTAG interface quits, if the processor is left without clock. The >>>> newer processors have complicated programmable clock generating chains, >>>> which are easy to mis-program (been there, bricked many). >>>> >>>> My guess is that all the logic in the synthesized core needs the main >>>> clock to run at all. And - yes, it is against the JTAG standard. >>> >>> That's actually what led me to assigning a "debrick" pin -- my very >>> first >>> experience with an ARM Cortex part had me ordering replacement chips for >>> an eval board after I flubbed the PLL setup and bricked it. >>> >> >> Correct me if I am wrong,. but not all ARM ... setups >> are this way, to my observation. >> >> So what do you gain for the extra risk of bricking the thing? Seems >> unnecessarily risky. And I presume that the "debrick" pin just grounds >> something on the chip? > > > The clock generator needs to be set up from the initial > RC limp oscillator started at reset. At least the brickings > I have done were difficulties in setting the clock generator > registers so that the thing has a legal clock under the time > of setting up. There are fascinating implications in writing > the registers, and all are not written out clearly in the > data sheets. >Yeah, I got all that but I just wonder why they bothered with that design to start with? The ARM chips I have dealt with, all you lost when messing up any PLL setup was the DRAM interface.> The debrick pin in Atmel's SAMs needs to be pulled up for some > hundreds of milliseconds at reset, to erase all the internal flash. > It is an I/O pin, but it is sensed before any I/O setup at reset. >Ah, thanks. -- Les Cargill
OpenOCD, JTAG, ARM
Started by ●March 1, 2015
Reply by ●March 4, 20152015-03-04
Reply by ●March 4, 20152015-03-04
On Tue, 03 Mar 2015 14:50:48 -0500, rickman wrote:> On 3/3/2015 1:42 PM, Tim Wescott wrote: >> On Sun, 01 Mar 2015 22:03:36 +0100, Michael Welle wrote: >> >>> Hello, >>> >>> Tim Wescott <tim@seemywebsite.com> writes: >>> >>>> On Sun, 01 Mar 2015 21:32:07 +0100, Michael Welle wrote: >>>> >>>>> Hello, >>>>> >>>>> good news, the I can connect again ;). Thanks to Tauno for pushing >>>>> me in the right direction. 1kOhm from ISP enable to ground let me >>>>> connect via JTAG and erase the flash. >>>>> >>>>> Regards hmw >>>> >>>> Cool. I'm happy to have guessed wrong. >>> me too ;). Thanks for the help anyways. >>> >>> Now it would be interesting to know how that happened. >>> >>> Regards hmw >> >> I'm not familiar with the chip in question, but if enabling the ISP >> makes JTAG work, then it sounds like something in your software is >> making JTAG _not_ work. >> >> I'd do what I mentioned before -- look at the port setup, and make sure >> that your code isn't stomping on the JTAG pins. > > I think that has to be a flaw in the chip. I believe the spec for JTAG > is such that JTAG can take over the chip at any time. There should be > no need for asserting an ISP pin.It may be a flaw, but if so it's an intentional one. The behavior is shared by all the ARM Cortex parts that I've used, both from Luminary/TI and from ST. -- www.wescottdesign.com
Reply by ●March 5, 20152015-03-05
On 5.3.15 05:12, Tim Wescott wrote:> On Tue, 03 Mar 2015 14:50:48 -0500, rickman wrote: > >> On 3/3/2015 1:42 PM, Tim Wescott wrote: >>> On Sun, 01 Mar 2015 22:03:36 +0100, Michael Welle wrote: >>> >>>> Hello, >>>> >>>> Tim Wescott <tim@seemywebsite.com> writes: >>>> >>>>> On Sun, 01 Mar 2015 21:32:07 +0100, Michael Welle wrote: >>>>> >>>>>> Hello, >>>>>> >>>>>> good news, the I can connect again ;). Thanks to Tauno for pushing >>>>>> me in the right direction. 1kOhm from ISP enable to ground let me >>>>>> connect via JTAG and erase the flash. >>>>>> >>>>>> Regards hmw >>>>> >>>>> Cool. I'm happy to have guessed wrong. >>>> me too ;). Thanks for the help anyways. >>>> >>>> Now it would be interesting to know how that happened. >>>> >>>> Regards hmw >>> >>> I'm not familiar with the chip in question, but if enabling the ISP >>> makes JTAG work, then it sounds like something in your software is >>> making JTAG _not_ work. >>> >>> I'd do what I mentioned before -- look at the port setup, and make sure >>> that your code isn't stomping on the JTAG pins. >> >> I think that has to be a flaw in the chip. I believe the spec for JTAG >> is such that JTAG can take over the chip at any time. There should be >> no need for asserting an ISP pin. > > It may be a flaw, but if so it's an intentional one. The behavior is > shared by all the ARM Cortex parts that I've used, both from Luminary/TI > and from ST.As far as I know, the JTAG is a part of the core design coming as a block from ARM to the sublicensees. The documentation is very careful about the details, but my guess is that the whole core block is synthetized synchronous logic, running on the core clock. There is a hint about it, when it is said that one should not use the WFI (wait for interrupt) instruction, if it is desired to debug with JTAG. -- -TV
Reply by ●March 5, 20152015-03-05
On Thu, 05 Mar 2015 08:10:42 +0200, Tauno Voipio wrote:> On 5.3.15 05:12, Tim Wescott wrote: >> On Tue, 03 Mar 2015 14:50:48 -0500, rickman wrote: >> >>> On 3/3/2015 1:42 PM, Tim Wescott wrote: >>>> On Sun, 01 Mar 2015 22:03:36 +0100, Michael Welle wrote: >>>> >>>>> Hello, >>>>> >>>>> Tim Wescott <tim@seemywebsite.com> writes: >>>>> >>>>>> On Sun, 01 Mar 2015 21:32:07 +0100, Michael Welle wrote: >>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> good news, the I can connect again ;). Thanks to Tauno for pushing >>>>>>> me in the right direction. 1kOhm from ISP enable to ground let me >>>>>>> connect via JTAG and erase the flash. >>>>>>> >>>>>>> Regards hmw >>>>>> >>>>>> Cool. I'm happy to have guessed wrong. >>>>> me too ;). Thanks for the help anyways. >>>>> >>>>> Now it would be interesting to know how that happened. >>>>> >>>>> Regards hmw >>>> >>>> I'm not familiar with the chip in question, but if enabling the ISP >>>> makes JTAG work, then it sounds like something in your software is >>>> making JTAG _not_ work. >>>> >>>> I'd do what I mentioned before -- look at the port setup, and make >>>> sure that your code isn't stomping on the JTAG pins. >>> >>> I think that has to be a flaw in the chip. I believe the spec for >>> JTAG is such that JTAG can take over the chip at any time. There >>> should be no need for asserting an ISP pin. >> >> It may be a flaw, but if so it's an intentional one. The behavior is >> shared by all the ARM Cortex parts that I've used, both from >> Luminary/TI and from ST. > > > As far as I know, the JTAG is a part of the core design coming as a > block from ARM to the sublicensees. The documentation is very careful > about the details, but my guess is that the whole core block is > synthetized synchronous logic, running on the core clock. There is a > hint about it, when it is said that one should not use the WFI (wait for > interrupt) instruction, if it is desired to debug with JTAG.I can't remember the wording, but I felt that the verbiage surrounding the WFI instruction stuff was more than a hint. And the WFI does, indeed, royally screw JTAG. I do kinda wish that ARM had built something in so to detect activity on the JTAG port and flip a bit -- it would be nice to sense the presense of JTAG and refrain from using the WFI instruction. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
Reply by ●March 5, 20152015-03-05
On 5.3.15 19:21, Tim Wescott wrote:> On Thu, 05 Mar 2015 08:10:42 +0200, Tauno Voipio wrote: > >> On 5.3.15 05:12, Tim Wescott wrote: >>> On Tue, 03 Mar 2015 14:50:48 -0500, rickman wrote: >>> >>>> On 3/3/2015 1:42 PM, Tim Wescott wrote: >>>>> On Sun, 01 Mar 2015 22:03:36 +0100, Michael Welle wrote: >>>>> >>>>>> Hello, >>>>>> >>>>>> Tim Wescott <tim@seemywebsite.com> writes: >>>>>> >>>>>>> On Sun, 01 Mar 2015 21:32:07 +0100, Michael Welle wrote: >>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> good news, the I can connect again ;). Thanks to Tauno for pushing >>>>>>>> me in the right direction. 1kOhm from ISP enable to ground let me >>>>>>>> connect via JTAG and erase the flash. >>>>>>>> >>>>>>>> Regards hmw >>>>>>> >>>>>>> Cool. I'm happy to have guessed wrong. >>>>>> me too ;). Thanks for the help anyways. >>>>>> >>>>>> Now it would be interesting to know how that happened. >>>>>> >>>>>> Regards hmw >>>>> >>>>> I'm not familiar with the chip in question, but if enabling the ISP >>>>> makes JTAG work, then it sounds like something in your software is >>>>> making JTAG _not_ work. >>>>> >>>>> I'd do what I mentioned before -- look at the port setup, and make >>>>> sure that your code isn't stomping on the JTAG pins. >>>> >>>> I think that has to be a flaw in the chip. I believe the spec for >>>> JTAG is such that JTAG can take over the chip at any time. There >>>> should be no need for asserting an ISP pin. >>> >>> It may be a flaw, but if so it's an intentional one. The behavior is >>> shared by all the ARM Cortex parts that I've used, both from >>> Luminary/TI and from ST. >> >> >> As far as I know, the JTAG is a part of the core design coming as a >> block from ARM to the sublicensees. The documentation is very careful >> about the details, but my guess is that the whole core block is >> synthetized synchronous logic, running on the core clock. There is a >> hint about it, when it is said that one should not use the WFI (wait for >> interrupt) instruction, if it is desired to debug with JTAG. > > I can't remember the wording, but I felt that the verbiage surrounding the > WFI instruction stuff was more than a hint. > > And the WFI does, indeed, royally screw JTAG. I do kinda wish that ARM > had built something in so to detect activity on the JTAG port and flip a > bit -- it would be nice to sense the presense of JTAG and refrain from > using the WFI instruction.Or just pick the clock to the JTAG part ahead of the WFI gating. The best would be to follow the schematics in the JTAG standard and just clock that part from TCK alone. -- -TV
Reply by ●March 5, 20152015-03-05
On Thu, 05 Mar 2015 21:07:17 +0200, Tauno Voipio wrote:> On 5.3.15 19:21, Tim Wescott wrote: >> On Thu, 05 Mar 2015 08:10:42 +0200, Tauno Voipio wrote: >> >>> On 5.3.15 05:12, Tim Wescott wrote: >>>> On Tue, 03 Mar 2015 14:50:48 -0500, rickman wrote: >>>> >>>>> On 3/3/2015 1:42 PM, Tim Wescott wrote: >>>>>> On Sun, 01 Mar 2015 22:03:36 +0100, Michael Welle wrote: >>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> Tim Wescott <tim@seemywebsite.com> writes: >>>>>>> >>>>>>>> On Sun, 01 Mar 2015 21:32:07 +0100, Michael Welle wrote: >>>>>>>> >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> good news, the I can connect again ;). Thanks to Tauno for >>>>>>>>> pushing me in the right direction. 1kOhm from ISP enable to >>>>>>>>> ground let me connect via JTAG and erase the flash. >>>>>>>>> >>>>>>>>> Regards hmw >>>>>>>> >>>>>>>> Cool. I'm happy to have guessed wrong. >>>>>>> me too ;). Thanks for the help anyways. >>>>>>> >>>>>>> Now it would be interesting to know how that happened. >>>>>>> >>>>>>> Regards hmw >>>>>> >>>>>> I'm not familiar with the chip in question, but if enabling the ISP >>>>>> makes JTAG work, then it sounds like something in your software is >>>>>> making JTAG _not_ work. >>>>>> >>>>>> I'd do what I mentioned before -- look at the port setup, and make >>>>>> sure that your code isn't stomping on the JTAG pins. >>>>> >>>>> I think that has to be a flaw in the chip. I believe the spec for >>>>> JTAG is such that JTAG can take over the chip at any time. There >>>>> should be no need for asserting an ISP pin. >>>> >>>> It may be a flaw, but if so it's an intentional one. The behavior is >>>> shared by all the ARM Cortex parts that I've used, both from >>>> Luminary/TI and from ST. >>> >>> >>> As far as I know, the JTAG is a part of the core design coming as a >>> block from ARM to the sublicensees. The documentation is very careful >>> about the details, but my guess is that the whole core block is >>> synthetized synchronous logic, running on the core clock. There is a >>> hint about it, when it is said that one should not use the WFI (wait >>> for interrupt) instruction, if it is desired to debug with JTAG. >> >> I can't remember the wording, but I felt that the verbiage surrounding >> the WFI instruction stuff was more than a hint. >> >> And the WFI does, indeed, royally screw JTAG. I do kinda wish that ARM >> had built something in so to detect activity on the JTAG port and flip >> a bit -- it would be nice to sense the presense of JTAG and refrain >> from using the WFI instruction. > > > Or just pick the clock to the JTAG part ahead of the WFI gating. > > The best would be to follow the schematics in the JTAG standard and just > clock that part from TCK alone.Well, I suppose if I'm wishing -- yes. But from TCK please -- WFI is there to minimize power consumption, which is kinda hard if you have some obligate clocked portion of the chip. I'm thinking maybe I'll build something into the software to run for five minutes or so without WFI, and then enable it if some bit somewhere isn't set. That'll let JTAG come up in "human time". -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
Reply by ●March 5, 20152015-03-05
Den torsdag den 5. marts 2015 kl. 20.07.23 UTC+1 skrev Tauno Voipio:> On 5.3.15 19:21, Tim Wescott wrote: > > On Thu, 05 Mar 2015 08:10:42 +0200, Tauno Voipio wrote: > > > >> On 5.3.15 05:12, Tim Wescott wrote: > >>> On Tue, 03 Mar 2015 14:50:48 -0500, rickman wrote: > >>> > >>>> On 3/3/2015 1:42 PM, Tim Wescott wrote: > >>>>> On Sun, 01 Mar 2015 22:03:36 +0100, Michael Welle wrote: > >>>>> > >>>>>> Hello, > >>>>>> > >>>>>> Tim Wescott <tim@seemywebsite.com> writes: > >>>>>> > >>>>>>> On Sun, 01 Mar 2015 21:32:07 +0100, Michael Welle wrote: > >>>>>>> > >>>>>>>> Hello, > >>>>>>>> > >>>>>>>> good news, the I can connect again ;). Thanks to Tauno for pushing > >>>>>>>> me in the right direction. 1kOhm from ISP enable to ground let me > >>>>>>>> connect via JTAG and erase the flash. > >>>>>>>> > >>>>>>>> Regards hmw > >>>>>>> > >>>>>>> Cool. I'm happy to have guessed wrong. > >>>>>> me too ;). Thanks for the help anyways. > >>>>>> > >>>>>> Now it would be interesting to know how that happened. > >>>>>> > >>>>>> Regards hmw > >>>>> > >>>>> I'm not familiar with the chip in question, but if enabling the ISP > >>>>> makes JTAG work, then it sounds like something in your software is > >>>>> making JTAG _not_ work. > >>>>> > >>>>> I'd do what I mentioned before -- look at the port setup, and make > >>>>> sure that your code isn't stomping on the JTAG pins. > >>>> > >>>> I think that has to be a flaw in the chip. I believe the spec for > >>>> JTAG is such that JTAG can take over the chip at any time. There > >>>> should be no need for asserting an ISP pin. > >>> > >>> It may be a flaw, but if so it's an intentional one. The behavior is > >>> shared by all the ARM Cortex parts that I've used, both from > >>> Luminary/TI and from ST. > >> > >> > >> As far as I know, the JTAG is a part of the core design coming as a > >> block from ARM to the sublicensees. The documentation is very careful > >> about the details, but my guess is that the whole core block is > >> synthetized synchronous logic, running on the core clock. There is a > >> hint about it, when it is said that one should not use the WFI (wait for > >> interrupt) instruction, if it is desired to debug with JTAG. > > > > I can't remember the wording, but I felt that the verbiage surrounding the > > WFI instruction stuff was more than a hint. > > > > And the WFI does, indeed, royally screw JTAG. I do kinda wish that ARM > > had built something in so to detect activity on the JTAG port and flip a > > bit -- it would be nice to sense the presense of JTAG and refrain from > > using the WFI instruction. > > > Or just pick the clock to the JTAG part ahead of the WFI gating. > > The best would be to follow the schematics in the JTAG standard > and just clock that part from TCK alone. >it is more complicated than that, (it's been 10+ year since I worked on ARM but..) all then boundary scan etc. works just fine, but everything that talk to the CPU is sampled with cpu clk to avoid the async clock, that is also the reason for rclk which is just the tck sampled with clock talking to the cpu is mostly handfeeding data and enabling a single clock cycle -Lasse
Reply by ●March 5, 20152015-03-05
On Thu, 05 Mar 2015 17:26:14 -0600, Tim Wescott wrote:> On Thu, 05 Mar 2015 21:07:17 +0200, Tauno Voipio wrote: > >> On 5.3.15 19:21, Tim Wescott wrote: >>> On Thu, 05 Mar 2015 08:10:42 +0200, Tauno Voipio wrote: >>> >>>> On 5.3.15 05:12, Tim Wescott wrote: >>>>> On Tue, 03 Mar 2015 14:50:48 -0500, rickman wrote: >>>>> >>>>>> On 3/3/2015 1:42 PM, Tim Wescott wrote: >>>>>>> On Sun, 01 Mar 2015 22:03:36 +0100, Michael Welle wrote: >>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> Tim Wescott <tim@seemywebsite.com> writes: >>>>>>>> >>>>>>>>> On Sun, 01 Mar 2015 21:32:07 +0100, Michael Welle wrote: >>>>>>>>> >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> good news, the I can connect again ;). Thanks to Tauno for >>>>>>>>>> pushing me in the right direction. 1kOhm from ISP enable to >>>>>>>>>> ground let me connect via JTAG and erase the flash. >>>>>>>>>> >>>>>>>>>> Regards hmw >>>>>>>>> >>>>>>>>> Cool. I'm happy to have guessed wrong. >>>>>>>> me too ;). Thanks for the help anyways. >>>>>>>> >>>>>>>> Now it would be interesting to know how that happened. >>>>>>>> >>>>>>>> Regards hmw >>>>>>> >>>>>>> I'm not familiar with the chip in question, but if enabling the >>>>>>> ISP makes JTAG work, then it sounds like something in your >>>>>>> software is making JTAG _not_ work. >>>>>>> >>>>>>> I'd do what I mentioned before -- look at the port setup, and make >>>>>>> sure that your code isn't stomping on the JTAG pins. >>>>>> >>>>>> I think that has to be a flaw in the chip. I believe the spec for >>>>>> JTAG is such that JTAG can take over the chip at any time. There >>>>>> should be no need for asserting an ISP pin. >>>>> >>>>> It may be a flaw, but if so it's an intentional one. The behavior >>>>> is shared by all the ARM Cortex parts that I've used, both from >>>>> Luminary/TI and from ST. >>>> >>>> >>>> As far as I know, the JTAG is a part of the core design coming as a >>>> block from ARM to the sublicensees. The documentation is very careful >>>> about the details, but my guess is that the whole core block is >>>> synthetized synchronous logic, running on the core clock. There is a >>>> hint about it, when it is said that one should not use the WFI (wait >>>> for interrupt) instruction, if it is desired to debug with JTAG. >>> >>> I can't remember the wording, but I felt that the verbiage surrounding >>> the WFI instruction stuff was more than a hint. >>> >>> And the WFI does, indeed, royally screw JTAG. I do kinda wish that >>> ARM had built something in so to detect activity on the JTAG port and >>> flip a bit -- it would be nice to sense the presense of JTAG and >>> refrain from using the WFI instruction. >> >> >> Or just pick the clock to the JTAG part ahead of the WFI gating. >> >> The best would be to follow the schematics in the JTAG standard and >> just clock that part from TCK alone. > > Well, I suppose if I'm wishing -- yes. But from TCK please -- WFI is > there to minimize power consumption, which is kinda hard if you have > some obligate clocked portion of the chip. > > I'm thinking maybe I'll build something into the software to run for > five minutes or so without WFI, and then enable it if some bit somewhere > isn't set. That'll let JTAG come up in "human time".At least on the 1768/69 the wfi shuts down *some* DMA transfers. This caught me when I moved a buffer to the main memory block in my linker script: "The GPDMA may operate in Sleep mode to access AHB SRAMs and peripherals with GPDMA support, but the GPDMA cannot access the flash memory or the main SRAM, which are disabled in order to save power." Also happens if you build a DMA chain where some of the transfer is const text in flash. You will be waiting on the DMA interrupt until your WDT goes off. -- Chisolm Republic of Texas
