Help with Mplab Snap and AVR JTAG

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

I recently got myself an mplab snap since it was reasonably priced and claimed AVR JTAG support.

I'm trying to get the snap ro connect to an m644. After several attempts and not an insignificant amount of guesswork, I've finally got it to atleast compile blinky with avr8 (dont really want to go down the XC8 rabbit hole), verify target voltage and read the chip signature correctly and attempt to write via MPLAB X. I know the complied itself works fine because I sent the generated hex over with a bootloader. Oh, yeah, the part is programmed with a bootloader with the appropriate fuse and lock bits set for a 2k boot size, If that makes a difference.

The JTAG lines, matched by name, are routed directly to the corresponding pins on the SNAP 8 pin connector. There are no external pull ups, series resistors, capacitors, or diodes anywhere near these lines save for a 10k pullup on the reset line.

I haven't used JTAG with AVRs before, though I have used AVRs a fair bit since '06 otherwise and JTAG with MSP430s through gdb and crossworks at different times and a launchpad and ATSAM7 through a segger Jlink and IAR. I haven't used MPLAB (or AVR studio, for that matter) before.

When it comes time to write, however, it dumps out with an "invalid physical state" error, I think with (49), but I'm not near the hardware right now to confirm. I can't seem to find any mention of such an error anywhere. Microchip documentation is horrible, and quite frankly is at the opposite end of the spectrum from what I've come to expect from Atmel.

I've pretty much run out of places to look. Any help or insight would be much appreciated.

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

MPLAB Snap is beta for AVR.

What debugger isn't beta for AVR?

  • MPLAB PICkit 4 : mega4809, mega3209, mega3208

from MPLAB X v5.20 'Device Support.htm'

MPLAB X IDE | Microchip Technology (Downloads tab, Release Notes)

 

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

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

What's the point of a beta (and their loud claims of AVR support) if it comes with no useful functionality, no useful documentation, and seemingly no authoritative support channel to collect errors and issues? I suspect the problem must stem from some screw up on my hardware, maybe something that needs to be pulled up isn't. If not, this seems pre-alpha, at best, and thank god I didn't go the whole hot and spring for a Pickit 4 as I had originally considered.

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

chintal wrote:
Any help or insight would be much appreciated.

Well since your working with legacy Mega AVR's, I would use the legacy tools, AS7 and a jtag ice clone, rather then the alpha (not even beta level) mplab!

You will find others here with similar frustrated experience, similar to your own, it's not ready for any serious development with AVR's IMO (YMMV).

Search out other threads here of others using mplab. 

There was a recent thread about a mod needed for SNAP so it would work with AVR's, a pull down resistor needs to be removed.

Jim

edit: SNAP mod added.

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274

 

 

 

Last Edited: Wed. Jun 12, 2019 - 01:43 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

chintal wrote:
no useful documentation,
MPLAB® PICkit™ 4 Debugger Pinouts for Interfaces - Developer Help

chintal wrote:
 and seemingly no authoritative support channel to collect errors and issues?
Microchip/Atmel support page | AVR Freaks

 

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

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

I presume you mean ETN-36 (http://ww1.microchip.com/downloads/en/DeviceDoc/ETN36_MPLAB%20Snap%20AVR%20Interface%20Modification.pdf) re the resistor to be removed.

I did see it, it seems to largely talk about PDI and TPI, though,so I did not try it. It seems simple enough, I suppose it's worth a go.

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

ki0bk wrote:
AS7 and a jtag ice clone, 
Atmel-ICE would be a better match for mega644; the ones at Waveshare recognize its price issue :

https://www.avrfreaks.net/forum/how-make-atmel-ice-cable#comment-2663511

Atmel-ICE "should" work better in the current MPLAB X than MPLAB tools though even Atmel-ICE is beta in MPLAB X v5.20

ki0bk wrote:
There was a recent thread about a mod needed for SNAP so it would work with AVR's, a pull down resistor needs to be removed.
https://www.avrfreaks.net/forum/mplab-snap#comment-2676171

 

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

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

Let's be practical.   You have bought a SNAP and not an ATMEL-ICE.

No need for any hardware mod to the SNAP.   You just connect to the JTAG pins.    The ATmega644 comes out of the factory with JTAGEN fuse.   

 

Unfortunately the SNAP is not supported by AS7.0 (yet).

So you have little choice but MPLABX v5.20

Yes,  I have used SNAP with JTAG.    It does mean you are stuck with MPLABX.    Make sure that you update to v5.20.

 

Post your MPLABX project e.g. ZIP up the project directory and attach the ZIP file.

Readers might build your project and help you with MPLABX, and the debug process.

 

David.

Last Edited: Wed. Jun 12, 2019 - 02:21 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ki0bk wrote:
and a jtag ice clone
Err no. The JTAG ICE only supported the 10 oldest AVR with JTAG. That does not include mega644. 

 

But what I would get is AS7 and an Atmel-ICE as that is a known combination that is bound to work with mega644.

 

I'd leave all the funky new stuff like MPLABX and Microchip Snap until all the bugs are worked out. History says, judging by the AS5->AS6->AS7 development, that it maybe takes 2..3 years from the starting point before you can expect an IDE/debugger combination to be stable. So far I think MPLABX etc has had something like 6..9 months maybe? Too early to expect any kind of reliability.

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

clawson wrote:
So far I think MPLABX etc has had something like 6..9 months maybe?
Come Join Us (MPLAB Now Supports AVRs) | AVR Freaks

clawson wrote:
Too early to expect any kind of reliability.
Some AVR have reached acceptable reliability per

"G" Green indicates full, production tested support.

in MPLAB X v5.20 'Device Support.htm'

 

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

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

Since it seems to be coming up a lot : I don't personally care about Mplab. The only reason I'm using it is because it's the only thing snap seems to support for now and I do try to give Manufacturer IDEs a fair shake.

I'm perfectly fine with an avrdude interface which I use with a bootloader that pretends to be an stk500.

I'm interested in getting debug to work, for which I obtained the Snap and installed Mplab. If it pans out, long term I'll most likely be using MDB from a terminal instead of mplab itself. I'd have liked gdb, but that's fine. My firmware is all either using esoteric makefiles or a cmake build system, and I really can't be bothered to use the gimmicky Makefiles mplab uses which "you really don't want to edit yourself" (per some MC forum thread somewhere I was looking at this afternoon). That's also why I went straight to AVR8 instead of XC8. The rest of my build environment will just need to be given a new avr gcc path.

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

I shall check the Mplab version and upgrade if needed. I still think there's something wrong with my JTAG connections. I'll take a closer look at my schematics and post a copy of the relevant bits in a day or so, as well as try to put the project directory zip up. Theres not very much I the project directory, though. It's literally a delay_ms blinky.

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

I know Snap is attractive because of the price but if you want "stable" so you can actually get on and do something I'd pay a bit more and get an Atmel-ICE.

 

The Snap will be great when it has widespread support in AS7 and MPLABX for all models of debuggable AVR but until then I would hold off.

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

@Cliff,

 

The SNAP hardware works pretty well in MPLABX v5.20.

It is the MPLABX debug environment that needs "improvement"

 

Netbeans is probably more powerful than VisualStudio.   And it can run on Linux, Mac, Windoze, ...

I would guess that the Register windows,   Locals, Breakpoints, ... could be configured to have the "look and feel" of VisualStudio.

 

I come from the prehistoric age of Makefiles and command lines.     Excellent for building a project.

However modern debugging requires a "visual"  (unless you are a masochist).

 

David.

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

@David,

While I would agree with you in general, in this specific instance I would say that even if the debug feels correct, the environment itself is greatly crippled by its near complete takeover of the build system. I know this is not entirely uncommon in IDE land, but microchip basically stuck their logo on whatever compiler they wanted, posiibly made minor internal or external changes, broke continuity with all that came before for what seems to me to be little more than a rebrand, atleast for XC32. There's only so much you can do before the IDE has to give you close in access to the build system, and that means the ability to muck about with makefiles without descending into a strange series of includes that the IDE generates 'on the fly'.

Everyone else seems to be doing alright and supporting both a gcc/gdb based backend as well as their own proprietary toolchains, and AVRs had that up until recently. Avarice and avrdude both seem to have poor to non-existant suppost post pickit 2. Compiler wise, Microchip docs for AVR8 are strange. You can install XC8 normally but you have sort of stumble onto AVR8 and work out how to install it or that it even can be installed. For some reason it doesn't seem to like the regular old avr-gcc distributions (which they seem to say is a known problem they are working on). It isn't at all hard to do, it just leaves a really bad taste to have to spend a day working out what toolchains are there and how to set them up, and at the end of it all need to retool legacy projects into their format, whatever that might be, in order to take advantage of their tools and get the kind of graphical debug you'd like.

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

You can use the regular gcc tools in MPLABX.
If you really wanted, you could install some other toolset.
I am a little concerned about the XC8 toolset.
Perhaps Microchip will drop gcc in the future. Gcc will still be fine for current products. It is proven and stable.
If Microchip develop a brand new architecture it might only be supported by XC8.
.
I would not lose any sleep over this. There are plenty of other chip manufacturers.
.
Regarding IDE style. I can live with AS7, IAR, Keil, Rowley, ...
I find Eclipse horrible. MplabX is somewhere in between.
.
David.

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

chintal wrote:
Everyone else seems to be doing alright and supporting both a gcc/gdb based backend as well as their own proprietary toolchains, and AVRs had that up until recently.
AVR GDB is community supported other than from ones at Microchip :

  • AVR GDB patches
  • AVR GDB proxy kickoff by a certain one at Microchip

VisualGDB has AVR GDB via AVaRICE (EDBG, Atmel-ICE, AVR and XMEGA AVR, no unified memory AVR)

EDBG is open though without freedom; IAR EWAVR has EDBG along with other AVR IDE.

EDBG arrived late'13 with an instance in Atmel Studio 6.2 (early'14)

 

Debugging Arduino AVR boards with Visual Studio – VisualGDB Tutorials

VisualGDB has CMake in addition to Microsoft MSBuild.

 

https://github.com/avrsimulator/gdbproxy

via https://www.avrfreaks.net/forum/avr-simulators-open-source#comment-2640886

new devices via device packs whereas that's AVaRICE source code changes

 

Embedded Debugger-Based Tools Protocols User's Guide - Document Revisions

Atmel Studio 6.2 (RELEASE NOTES) (page 33, Atmel-ICE on page 8)

 

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

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

david.prentice wrote:
I am a little concerned about the XC8 toolset.
Perhaps Microchip will drop gcc in the future.
Perhaps as MPLAB XC8 v2 for AVR is based on FSF AVR GCC whereas MPLAB XC8 v2 for PIC is based on Clang (not GPL, its Apache v2; there are other advantages)

david.prentice wrote:
If Microchip develop a brand new architecture it might only be supported by XC8.
If or when?

Reason : competition for 8b MCU

 


Clang C Language Family Frontend for LLVM

 

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

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

Some updates :

 

I had been using MPLAB IDE v5.15. I have since upgraded to v5.20. I think there has been some change, but it does not work yet.

 

The current situation is that the IDE connects to the snap, detects the target voltage, sits there for a while, and then dies with an error that seems to vary. I have seen atleast one instance of a timeout, one instance of a failure to reset, and one instance of original error (invalid physical state). Interestingly enough, atleast one of these attempts actually resulted in a program write, even though the debugger did not attach. I know this because it successfully nuked the existing firmware and put the blinky code I was using in MPLAB.

 

I've attached a copy of the schematic of the M644 portion of the board I'm using to test this for reference.

 

Attachment(s):