Hello, has anybody hard facts what the requirements for the ration between Jtag/SWD clock and MCU clock is. Main interest is for Cortex-M, but facts for other archs are welcome. Information floating aound in the net tells abound a factor of 6, but some people tell about successfull SWD communication even with a MCU clock much slower than the SWD clock. Thanks -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 1623569 ------- Fax. 06151 1623305 ---------
Ration between MCU and JTAG/SWD clock (Cortex-M and others)?
Started by ●May 18, 2016
Reply by ●May 18, 20162016-05-18
On 18.5.16 12:52, Uwe Bonnes wrote:> Hello, > > has anybody hard facts what the requirements for the ration between Jtag/SWD > clock and MCU clock is. Main interest is for Cortex-M, but facts for other > archs are welcome. Information floating aound in the net tells abound a > factor of 6, but some people tell about successfull SWD communication even > with a MCU clock much slower than the SWD clock. > > ThanksThe Atmel SAM4s stumble, if you do not respect the ratio 6. It is a design flaw in the ARM core part, as the JTAG handling should be totally asynchronous to the master clock, and depend on JTAG clock only. If you make a mistake in the clock generator setup, you may end up with a brick. I had a long fight with the SAM4S clock generator, including occasional bricks. My guess is that ARM have used logic clocked with the master clock, instead of the way described in the JTAG standard. The same problem plagued the old ARM7TDMI. -- -TV
Reply by ●May 18, 20162016-05-18
On Wed, 18 May 2016 15:23:48 +0300, Tauno Voipio wrote:> On 18.5.16 12:52, Uwe Bonnes wrote: >> Hello, >> >> has anybody hard facts what the requirements for the ration between >> Jtag/SWD clock and MCU clock is. Main interest is for Cortex-M, but >> facts for other archs are welcome. Information floating aound in the >> net tells abound a factor of 6, but some people tell about successfull >> SWD communication even with a MCU clock much slower than the SWD clock. >> >> Thanks > > > The Atmel SAM4s stumble, if you do not respect the ratio 6. > > It is a design flaw in the ARM core part, as the JTAG handling should be > totally asynchronous to the master clock, and depend on JTAG clock only. > If you make a mistake in the clock generator setup, you may end up with > a brick. I had a long fight with the SAM4S clock generator, including > occasional bricks. > > My guess is that ARM have used logic clocked with the master clock, > instead of the way described in the JTAG standard. > > The same problem plagued the old ARM7TDMI.ALL my embedded ARM designs have some sort of anti-brick hardware/ software. Usually it's a GPIO pin with a pull-up, and software that spins on the pin BEFORE it goes and messes with clocks or JTAG pin assignments. When I can, it's the very first thing that runs out of reset. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com I'm looking for work -- see my website!
Reply by ●May 18, 20162016-05-18
On Wednesday, May 18, 2016 at 1:47:51 PM UTC-7, Tim Wescott wrote:> On Wed, 18 May 2016 15:23:48 +0300, Tauno Voipio wrote: > > > On 18.5.16 12:52, Uwe Bonnes wrote: > >> Hello, > >> > >> has anybody hard facts what the requirements for the ration between > >> Jtag/SWD clock and MCU clock is. Main interest is for Cortex-M, but > >> facts for other archs are welcome. Information floating aound in the > >> net tells abound a factor of 6, but some people tell about successfull > >> SWD communication even with a MCU clock much slower than the SWD clock. > >> > >> Thanks > > > > > > The Atmel SAM4s stumble, if you do not respect the ratio 6. > > > > It is a design flaw in the ARM core part, as the JTAG handling should be > > totally asynchronous to the master clock, and depend on JTAG clock only. > > If you make a mistake in the clock generator setup, you may end up with > > a brick. I had a long fight with the SAM4S clock generator, including > > occasional bricks. > > > > My guess is that ARM have used logic clocked with the master clock, > > instead of the way described in the JTAG standard. > > > > The same problem plagued the old ARM7TDMI. > > ALL my embedded ARM designs have some sort of anti-brick hardware/ > software. Usually it's a GPIO pin with a pull-up, and software that > spins on the pin BEFORE it goes and messes with clocks or JTAG pin > assignments. When I can, it's the very first thing that runs out of > reset. > > -- > > Tim Wescott > Wescott Design Services > http://www.wescottdesign.com > > I'm looking for work -- see my website!Tim - Is the goal of spinning on the GPIO pin so that there is time to get the JTAG to connect in case the code ever configures the clock to something of an invalid value? Thanks, Chris
Reply by ●May 19, 20162016-05-19
On 18.5.16 23:47, Tim Wescott wrote:> On Wed, 18 May 2016 15:23:48 +0300, Tauno Voipio wrote: > >> On 18.5.16 12:52, Uwe Bonnes wrote: >>> Hello, >>> >>> has anybody hard facts what the requirements for the ration between >>> Jtag/SWD clock and MCU clock is. Main interest is for Cortex-M, but >>> facts for other archs are welcome. Information floating aound in the >>> net tells abound a factor of 6, but some people tell about successfull >>> SWD communication even with a MCU clock much slower than the SWD clock. >>> >>> Thanks >> >> >> The Atmel SAM4s stumble, if you do not respect the ratio 6. >> >> It is a design flaw in the ARM core part, as the JTAG handling should be >> totally asynchronous to the master clock, and depend on JTAG clock only. >> If you make a mistake in the clock generator setup, you may end up with >> a brick. I had a long fight with the SAM4S clock generator, including >> occasional bricks. >> >> My guess is that ARM have used logic clocked with the master clock, >> instead of the way described in the JTAG standard. >> >> The same problem plagued the old ARM7TDMI. > > ALL my embedded ARM designs have some sort of anti-brick hardware/ > software. Usually it's a GPIO pin with a pull-up, and software that > spins on the pin BEFORE it goes and messes with clocks or JTAG pin > assignments. When I can, it's the very first thing that runs out of > reset.It depends ... In Atmel SAM3 and SAM4 chips there is an I/O pin which when be pulled up during power-on for some time (200 ms or more) the whole flash gets erased. To complicate the things, the erased state is not the same as a factory-fresh chip: one configuration bit is different, but the chip does respond to JTAG after full erase. It just does not start from the programmed code unless one configuration bit is set again. The construction limits usage of the I/O pin so that the external circuitry must not usually keep the pin up at power-on. -- -TV
Reply by ●May 19, 20162016-05-19
On Thursday, May 19, 2016 at 1:49:53 AM UTC-7, Tauno Voipio wrote:> On 18.5.16 23:47, Tim Wescott wrote: > > On Wed, 18 May 2016 15:23:48 +0300, Tauno Voipio wrote: > > > >> On 18.5.16 12:52, Uwe Bonnes wrote: > >>> Hello, > >>> > >>> has anybody hard facts what the requirements for the ration between > >>> Jtag/SWD clock and MCU clock is. Main interest is for Cortex-M, but > >>> facts for other archs are welcome. Information floating aound in the > >>> net tells abound a factor of 6, but some people tell about successfull > >>> SWD communication even with a MCU clock much slower than the SWD clock. > >>> > >>> Thanks > >> > >> > >> The Atmel SAM4s stumble, if you do not respect the ratio 6. > >> > >> It is a design flaw in the ARM core part, as the JTAG handling should be > >> totally asynchronous to the master clock, and depend on JTAG clock only. > >> If you make a mistake in the clock generator setup, you may end up with > >> a brick. I had a long fight with the SAM4S clock generator, including > >> occasional bricks. > >> > >> My guess is that ARM have used logic clocked with the master clock, > >> instead of the way described in the JTAG standard. > >> > >> The same problem plagued the old ARM7TDMI. > > > > ALL my embedded ARM designs have some sort of anti-brick hardware/ > > software. Usually it's a GPIO pin with a pull-up, and software that > > spins on the pin BEFORE it goes and messes with clocks or JTAG pin > > assignments. When I can, it's the very first thing that runs out of > > reset. > > > It depends ... > > In Atmel SAM3 and SAM4 chips there is an I/O pin which when be pulled > up during power-on for some time (200 ms or more) the whole flash > gets erased. To complicate the things, the erased state is not the same > as a factory-fresh chip: one configuration bit is different, but the > chip does respond to JTAG after full erase. It just does not start from > the programmed code unless one configuration bit is set again. > > The construction limits usage of the I/O pin so that the external > circuitry must not usually keep the pin up at power-on. > > -- > > -TVThat makes sense. I corrupted an ARM7 from NXP years ago with the wrong clock divisors and have just tried to be very careful ever since. In this particular case, we were finally able to attach to the device via JTAG and load in code that had good divisor values. Currently, our team is having an issue with a TM4C1294 Tiva-C part right now. I think we've done this because the one particular chip that is having issues went belly up when we were playing with the PLL settings. We aren't having any luck connecting to this one device via JTAG. I was trying to erase the Flash for the Tiva-C part as you described, but I'm having trouble doing this with the UniFlash utility from TI. Any experience with this device getting the Flash erased so we can connect with JTAG again? Thanks, Chris
Reply by ●May 19, 20162016-05-19
On Wed, 18 May 2016 16:25:28 -0700, chris.lambrecht.ee wrote:> On Wednesday, May 18, 2016 at 1:47:51 PM UTC-7, Tim Wescott wrote: >> On Wed, 18 May 2016 15:23:48 +0300, Tauno Voipio wrote: >> >> > On 18.5.16 12:52, Uwe Bonnes wrote: >> >> Hello, >> >> >> >> has anybody hard facts what the requirements for the ration between >> >> Jtag/SWD clock and MCU clock is. Main interest is for Cortex-M, but >> >> facts for other archs are welcome. Information floating aound in the >> >> net tells abound a factor of 6, but some people tell about >> >> successfull SWD communication even with a MCU clock much slower than >> >> the SWD clock. >> >> >> >> Thanks >> > >> > >> > The Atmel SAM4s stumble, if you do not respect the ratio 6. >> > >> > It is a design flaw in the ARM core part, as the JTAG handling should >> > be totally asynchronous to the master clock, and depend on JTAG clock >> > only. >> > If you make a mistake in the clock generator setup, you may end up >> > with a brick. I had a long fight with the SAM4S clock generator, >> > including occasional bricks. >> > >> > My guess is that ARM have used logic clocked with the master clock, >> > instead of the way described in the JTAG standard. >> > >> > The same problem plagued the old ARM7TDMI. >> >> ALL my embedded ARM designs have some sort of anti-brick hardware/ >> software. Usually it's a GPIO pin with a pull-up, and software that >> spins on the pin BEFORE it goes and messes with clocks or JTAG pin >> assignments. When I can, it's the very first thing that runs out of >> reset. >> >> -- >> >> Tim Wescott Wescott Design Services http://www.wescottdesign.com >> >> I'm looking for work -- see my website! > > Tim - > > Is the goal of spinning on the GPIO pin so that there is time to get the > JTAG to connect in case the code ever configures the clock to something > of an invalid value?Yes. Then you can erase the flash via JTAG and start over, perhaps after stepping through the code and seeing your error. I know that the answer is "just be careful", but between PLL setup and pin reassignment there's enough JTAG booby-traps that such a pin has saved my ass innumerable times. Actually, the real answer would be for the JTAG to be active without a processor clock and with the processor held in reset, but the chip manufacturers don't do things that way. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com I'm looking for work -- see my website!
Reply by ●May 19, 20162016-05-19
On 19.5.16 20:21, Tim Wescott wrote:> On Wed, 18 May 2016 16:25:28 -0700, chris.lambrecht.ee wrote:>> Is the goal of spinning on the GPIO pin so that there is time to get the >> JTAG to connect in case the code ever configures the clock to something >> of an invalid value? > > Yes. Then you can erase the flash via JTAG and start over, perhaps after > stepping through the code and seeing your error. > > I know that the answer is "just be careful", but between PLL setup and > pin reassignment there's enough JTAG booby-traps that such a pin has > saved my ass innumerable times. > > Actually, the real answer would be for the JTAG to be active without a > processor clock and with the processor held in reset, but the chip > manufacturers don't do things that way.Yes. In my case I *was* careful, but the data sheet did not care to mention that the clock generator goes west, if you change more than one bit field in the control registers at a time, even when they are in the same register. This applies at least to SAM4S and SAM4E. The empirical method took two weeks of programming and erasing. -- -TV
Reply by ●May 19, 20162016-05-19
Den onsdag den 18. maj 2016 kl. 14.23.52 UTC+2 skrev Tauno Voipio:> On 18.5.16 12:52, Uwe Bonnes wrote: > > Hello, > > > > has anybody hard facts what the requirements for the ration between Jtag/SWD > > clock and MCU clock is. Main interest is for Cortex-M, but facts for other > > archs are welcome. Information floating aound in the net tells abound a > > factor of 6, but some people tell about successfull SWD communication even > > with a MCU clock much slower than the SWD clock. > > > > Thanks > > > The Atmel SAM4s stumble, if you do not respect the ratio 6. > > It is a design flaw in the ARM core part, as the JTAG handling > should be totally asynchronous to the master clock, and depend > on JTAG clock only. If you make a mistake in the clock generator > setup, you may end up with a brick. I had a long fight with the > SAM4S clock generator, including occasional bricks. > > My guess is that ARM have used logic clocked with the master > clock, instead of the way described in the JTAG standard. > > The same problem plagued the old ARM7TDMI.The way it was done in the ARM7TDMI was that the jtagclock was sampled with the system clock, the sampled clock was output so for debuggers that supported it you could automatically handle different clock speeds things need to be synchronized somewhere and a few jtag signals are simpler that bunch of other signals -Lasse
Reply by ●May 19, 20162016-05-19
On 19.5.16 21:37, lasselangwadtchristensen@gmail.com wrote:> Den onsdag den 18. maj 2016 kl. 14.23.52 UTC+2 skrev Tauno Voipio: >> On 18.5.16 12:52, Uwe Bonnes wrote: >>> Hello, >>> >>> has anybody hard facts what the requirements for the ration between Jtag/SWD >>> clock and MCU clock is. Main interest is for Cortex-M, but facts for other >>> archs are welcome. Information floating aound in the net tells abound a >>> factor of 6, but some people tell about successfull SWD communication even >>> with a MCU clock much slower than the SWD clock. >>> >>> Thanks >> >> >> The Atmel SAM4s stumble, if you do not respect the ratio 6. >> >> It is a design flaw in the ARM core part, as the JTAG handling >> should be totally asynchronous to the master clock, and depend >> on JTAG clock only. If you make a mistake in the clock generator >> setup, you may end up with a brick. I had a long fight with the >> SAM4S clock generator, including occasional bricks. >> >> My guess is that ARM have used logic clocked with the master >> clock, instead of the way described in the JTAG standard. >> >> The same problem plagued the old ARM7TDMI. > > The way it was done in the ARM7TDMI was that the jtagclock was sampled > with the system clock, the sampled clock was output so for debuggers > that supported it you could automatically handle different clock speeds > > things need to be synchronized somewhere and a few jtag signals are > simpler that bunch of other signals > > > -Lasse > >Lasse: The JTAG logic should run only clocked by TCK, independent of other clocks in the system. The signals from/to the JTAG machine shift registers may then be synchronized with the rest of the chip. The main problem is that ARM insists to run the JTAG state machine clocked by the processor clock. -- -TV
