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/

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

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!

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

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

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

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!

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.
> 
> -- 
> 
> -TV

That 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

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

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