Unreliable JTAG poperation/slow programming

Go To Last Post
14 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

(Studio Ver 7.0.2397, ATMega1284p, JTAGICE mkII)

 

Sometimes my debugging goes fine and other times it can take a long time to program flash (goes in spurts with delays of 10 seconds or more before the "percent complete" counter starts moving again).

 

I also have times where the debug session terminates with "The application is in break mode" for no reason I can find.

 

"step over" and "step in" seem to take forever sometimes (10-20 seconds).

 

There will be times when I can't get the JTAG to connect at all.  Then after many tries at combinations of a) power off/on the target board, b) power off/on the JTAGICE, restart Atmel Studio, etc. it will start working for awhile.

 

I'm thinking that, for whatever reason, there are data errors between the target and the JTAGICE but they will come and go.

 

It seems like, even when it can't program flash reliably, reading the fuses seems to work - but, I assume that's a very short exchange so may get fewer errors.

 

I got this JTAGICE mkII years ago.  It's in what looks like a 'standard' blue "AVR Studio" semi-clear case but I can't swear that it wasn't some kind of knockoff.

 

This is getting very annoying and greatly impeding my progress.

 

Can anyone think of why this would be happening?

 

Failing a solution - I don't see me moving away from ATMega's for a long time.  What would be the best JTAG device for me to get for use with Studio?

 

Thanks in advance ...

 

(a frustrated) Chuck Hackett

 

 

Last Edited: Thu. Sep 24, 2020 - 10:54 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

The latest and greatest is the Atmel-ICE.  I would suggest you bite the bullet and just get one.  The amount of Advil to support the old JTAG MKII is not worth it.

 

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ChuckH wrote:
Can anyone think of why this would be happening?
Unstable or noisy power?

USB VBUS is dependent on PC's power supply or notebook's wall wart.

Power Supply | AVR JTAGICE mkII

 

Intermittent target cable?

Try another or re-mount the IDC (move the connector(s) a tad up or down the cable, target end is most likely for issues)

My Atmel JTAGICE2 is packed on a nearby shelf; can examine it if need be.

ChuckH wrote:
What would be the best JTAG device for me to get for use with Studio?
Atmel-ICE, close second is MPLAB PICkit 4, then MPLAB Snap.

 

P.S.

Wall warts are a personal bane.

 

P.P.S.

ChuckH wrote:
... but I can't swear that it wasn't some kind of knockoff.
IIRC, there's only one clone (Waveshare)

 


         <device Dname="ATmega1284P">
...
                  <at:interface type="isp" name="ISP"/>
                  <at:interface type="hvpp" name="HVPP"/>
                  <at:interface type="megajtag" name="JTAG"/>
                  <at:tool id="com.atmel.avrdbg.tool.medbg"/>
                  <at:tool id="com.atmel.avrdbg.tool.atmelice"/>
                  <at:tool id="com.atmel.avrdbg.tool.pickit4"/>
                  <at:tool id="com.atmel.avrdbg.tool.avrdragon"/>
                  <at:tool id="com.atmel.avrdbg.tool.ispmk2"/>
                  <at:tool id="com.atmel.avrdbg.tool.jtagicemk3"/>
                  <at:tool id="com.atmel.avrdbg.tool.snap"/>
                  <at:tool id="com.atmel.avrdbg.tool.edbgc"/>
                  <at:tool id="com.atmel.avrdbg.tool.edbg"/>
                  <at:tool id="com.atmel.avrdbg.tool.avrone"/>
                  <at:tool id="com.atmel.avrdbg.tool.jtagice3plus"/>
                  <at:tool id="com.atmel.avrdbg.tool.powerdebugger"/>
                  <at:tool id="com.atmel.avrdbg.tool.edbg"/>
                  <at:tool id="com.atmel.avrdbg.tool.stk600"/>
                  <at:tool id="com.atmel.avrdbg.tool.jtagicemkii"/>
                  <at:tool id="com.atmel.avrdbg.tool.stk500"/>
                  <at:tool id="com.atmel.avrdbg.tool.simulator"/>
                  <at:property name="com.atmel.avrdbg.tool.simulator.key" value="ATmega1284P"/>
                  <at:property name="com.atmel.avrdbg.tool.simulator.model.win32" value="simulator/win32/libatmega1284p.dll"/>

copied from 'Atmel.ATmega_DFP.pdsc' at http://packs.download.atmel.com/#collapse-Atmel-ATmega-DFP-pdsc

 

USB AVR JTAGICE XPII - Waveshare Wiki

AVR JTAG ICE MkII Emulator for all AVR microntrollers (Kanda)

 

https://www.avrfreaks.net/forum/mplab-snap?page=2#comment-2987696

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jgmdesign wrote:
The amount of Advil to support the old JTAG MKII is not worth it.

 

Amen ... I ordered an Atmel-ICE yesterday - I am wasting too much time dealing with it.  Especially while tracking down a difficult condition.  Not just the time wasted but also the disruption in the thought process required to track down a bug.

 

I changed the USB cable and tried the MKII on three different boards with three different power supplies and all was the same. 

 

At the moment I can read/write fuses, load/verify a bootloader through the programming interface, load the flash on 'run' (counter appears to advance to the end) but the debug session will not start successfully ("application in break mode" error).

 

sigh ...

 

Chuck Hackett

 

PS: my apologies to the moderators for originally posting in the wrong forum)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jgmdesign wrote:
The latest and greatest is the Atmel-ICE.  I would suggest you bite the bullet and just get one. 

Indeed.

 

yes

 

Plus, as an added bonus, the Atmel-ICE will work with the newer protocols, and SAM devices.

 

And it's about a quarter of the size.

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Addendum: As mentioned above, I was able to load/verify the bootloader the "Device Programming" tab.  As a test, I turned off programming in project properties and loaded the application using the "Device Programming" tab.  Load/verify worked.  I was then able to attach to the target and debug ... strange

 

Chuck Hackett

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gchapman wrote:

Intermittent target cable?

Try another or re-mount the IDC (move the connector(s) a tad up or down the cable, target end is most likely for issues)

This has a high probability of being your problem, the tiny wires fatigue at the target end of the cable right at the point where the cable enters the IDC connector due to cable flex while pushing/pulling the connector on/off the target.

The cure is easy, carefully pry the top off the connector, pull the ribbon cable off the bottom, and slide the connector up the ribbon cable, use a small vise or large pliers and re-seat the connector.

Trim off the excess ribbon cable and you should be good to go again

 

Jim

 

 

Keys to wealth:

Invest for cash flow, not capital gains!

Wealth is attracted, not chased! 

Income is proportional to how many you serve!

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ki0bk wrote:
the tiny wires fatigue at the target end of the cable right at the point where the cable enters the IDC connector

 

I removed the cable from the mkII and moved both connectors inwards and trimmed the cable ... no joy sad

 

Chuck Hackett

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have received my new Atmel-ICE unit and my issues with writing flash seem to have been resolved except that the 'percent progress' display in the lower left corner now advances more slowly than before.  It seems to zip to about 40% and then advance one or two percent each second to about 73% and then the program starts.

 

I have not added any extra components to the JTAG lines such as pull-ups or bypass caps, etc.  Are there any that I should add?

 

(BTW: I have started a new thread on an associated issue: https://www.avrfreaks.net/forum/atmel-ice-loses-control-target)

 

Chuck

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ChuckH wrote:
the 'percent progress' display in the lower left corner

I'm not quite sure what that's actually supposed to be showing - is the percentage supposed to be

 

  • the percentage of your application that it's completed ?
  • the percentage of the total available flash  that it's completed ?
  • or what ??

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I myself ignore the progress bar most of the time.  In the OPs case the part is a 128k device....maybe it blasts the confit bits and such first and hence the bar moves quick, then when it starts chewing at the Flash...128k, it takes a little while.

 

for me, as long as it works when done I  am fine with it

 

jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:
I'm not quite sure what that's actually supposed to be showing - is the percentage supposed to be

 

I assume it's the percent of the area it's loading (EEPROM, Prog, etc.).  I notice that, loading the same chip different times after more code is added / removed, the last percentage displayed changes up / down.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jgmdesign wrote:
for me, as long as it works when done I  am fine with it

 

True ...

 

The major thing I noticed is that, using my older mkII, this progress bar was moving faster than when using the Atmel-ICE and I wondered why.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

An Atmel-ICE has reduced drive.

JTAG | AVR JTAGICE mkII

...

When external circuitry shares the JTAG debug lines on the target application, series resistors should be used to avoid driver contention, as shown in Figure 1. The value of the resistors should be chosen so that the external circuitry and the AVR do not exceed their maximum ratings (i.e. sink or source too much current). 1kΩ is a commonly used value.

...

MPLAB PICkit 4 can also drive 1KΩ.

 

"Dare to be naïve." - Buckminster Fuller