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 -- biff4emacsen - A biff-like tool for (X)Emacs http://www.c0t0d0s0.de/biff4emacsen/biff4emacsen.html Flood - Your friendly network packet generator http://www.c0t0d0s0.de/flood/flood.html
OpenOCD, JTAG, ARM
Started by ●March 1, 2015
Reply by ●March 1, 20152015-03-01
Reply by ●March 3, 20152015-03-03
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 hmwI'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. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
Reply by ●March 3, 20152015-03-03
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. -- Rick
Reply by ●March 3, 20152015-03-03
On 3.3.15 21:50, 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 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. -- -TV
Reply by ●March 3, 20152015-03-03
Den tirsdag den 3. marts 2015 kl. 20.51.04 UTC+1 skrev rickman:> 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. >plenty of processors where you can turn of the jtag and use the pins for something else, at that point the chip no longer has jtag so even if jtag had spec that said it should work at all times which I very much doubt it doesn't matter -Lasse
Reply by ●March 3, 20152015-03-03
On Tue, 03 Mar 2015 22:27:40 +0200, Tauno Voipio wrote:> On 3.3.15 21:50, 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 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. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
Reply by ●March 4, 20152015-03-04
Hello, Tim Wescott <seemywebsite@myfooter.really> writes: [...]> 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.my code at that time was a nearly empty main function, no registers or memory locations had been accessed from the C code. Since I'm new to ARM I tried some experiments to find out how the tool chain works. Maybe I forgot to erase the flash, flashed the binary to the 'wrong' place and some garbage in the flash was interpreted at code? Regards hmw -- biff4emacsen - A biff-like tool for (X)Emacs http://www.c0t0d0s0.de/biff4emacsen/biff4emacsen.html Flood - Your friendly network packet generator http://www.c0t0d0s0.de/flood/flood.html
Reply by ●March 4, 20152015-03-04
Hello, langwadt@fonz.dk writes: [...]> plenty of processors where you can turn of the jtag and use the pins > for something else, at that point the chip no longer has jtag so even > if jtagI haven't studied the spec in deep yet, but IIRC some JTAG pins are reused only for SWD. I think they can't be used as GPIOs on this controller.> had spec that said it should work at all times which I very much doubt > it doesn't matterPerhaps the problem was somehow clock related, as Tauno suggested. It's hard to speculate now. Maybe I f* up the board again in my experiments. Then, with all the possibilities what can go wrong in mind, I will have a closer look at the problem. Regards hmw -- biff4emacsen - A biff-like tool for (X)Emacs http://www.c0t0d0s0.de/biff4emacsen/biff4emacsen.html Flood - Your friendly network packet generator http://www.c0t0d0s0.de/flood/flood.html
Reply by ●March 4, 20152015-03-04
Tim Wescott wrote:> On Tue, 03 Mar 2015 22:27:40 +0200, Tauno Voipio wrote: > >> On 3.3.15 21:50, 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 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? -- Les Cargill
Reply by ●March 4, 20152015-03-04
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. 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. -- -TV
