On Thu, 19 May 2016 22:34:03 +0300, Tauno Voipio wrote:> 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.YES! YES! And, for completeness, there should be an atomic reset-and- halt command. However -- that won't save you from software that erroneously remaps the JTAG pins to something else. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com I'm looking for work -- see my website!
Ration between MCU and JTAG/SWD clock (Cortex-M and others)?
Started by ●May 18, 2016
Reply by ●May 19, 20162016-05-19
Reply by ●May 19, 20162016-05-19
Den torsdag den 19. maj 2016 kl. 21.34.07 UTC+2 skrev Tauno Voipio:> 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.I know I've worked a lot with ARM7TDMI-S many years ago. I think not having the jtag clock run on the processor clock would greatly complicate things. Much of what you do via jtag is done by hand feeding instructions to the cpu -Lasse
Reply by ●May 19, 20162016-05-19
On 19.5.2016 г. 23:02, lasselangwadtchristensen@gmail.com wrote:> ..... >> >> 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. > > I know I've worked a lot with ARM7TDMI-S many years ago. > > I think not having the jtag clock run on the processor clock would greatly > complicate things. Much of what you do via jtag is done by hand feeding instructions to the cpu > > -Lasse >That is understandable, but what about boundary scan? I am pretty sure things have worked on tck only for that on the few platforms I have used (e.g. mc68340, mpc8240, mpc5200/5200b, some TI DSP). In fact I think the rev. A of the 8240 needed some clock for boundary scan to work, not sure how it was on the E revision (the rev. A never worked really, I got some E replacements back then by a kind Motorola guy and things just worked). But for the internal debug registers I'd be very surprised if much would work on any of these (I have never used it, was never given the specs, NDA or no NDA - but I never really needed these anyway, the core has more than enough on offer for debugging). On smaller MCUs I have used I used those with BDM which is publically documented; I would also be very surprised if much of the BDM stuff worked with a non-working system clock though. Dimiter ------------------------------------------------------ Dimiter Popoff, TGI http://www.tgi-sci.com ------------------------------------------------------ http://www.flickr.com/photos/didi_tgi/
