MPLAB Snap

Go To Last Post
103 posts / 0 new

Pages

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

Gotta laugh, or cry, not sure which.

 

Meslomp, that is my thread on the MC Forum.

It is a SHORT version of my Thread about my difficulties with the SNAP.

None of the replies addressed the specific issue I have, namely the inability to download a pre-compiled .hex file to a Nano, and not also totally trash the Fuses.

 

The LONG version of difficulties with the SANP are detailed on a Freaks Thread that I hijacked, HERE.

 

Morton asked for some screen shots, so I provided a few.

I haven't hear anything back.

 

MC Support finally got back to me about my difficulty in getting my (first) Thread posted on the MC Forum.

That was a lengthy process.

 

I still can't download a pre-compiled .hex file into a Nano.

 

I gave up and moved on.

I use my AVR ISP mkII and my Atmel ICE.

 

My Stupid Non-working Avr Programmer, (SNAP for short) is just as non-functional today as it was when I purchased it.

 

I see that Cliff received some meaningful support from MC in another recent Thread of his.

Perhaps there is yet hope.

 

Perhaps not.

 

JC

 

Edit: Typo

I had a few other "S" works in mind, but this is a "G" rated Forum...

Last Edited: Fri. May 10, 2019 - 04:32 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Hello,

 

With such cheap price I couldn't resist to order one!

I had to remove the R48 as described on the snap page http://ww1.microchip.com/downloads/en/DeviceDoc/ETN36_MPLAB%20Snap%20AVR%20Interface%20Modification.pdf

I also made a small adapter to plug into UPDI pins.

With MPLAB X it works great, reading, writing (5V).

 

 

 

picture MPLAB SNAP + adapter 

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

fgras78 wrote:
With MPLAB X it works great, reading, writing (5V).

 

I bet you are using default fuses. This is no big deal for the UPDI chips, because the clock frequency is (mostly) set by software (the fuses only select 16 or 20MHz base clock). But for classic AVRs, you will quickly come across the problem that DocJC has been complaining about (to no avail so far). That is, the fuses are always auto-reset to factory default each time you upload a program.

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

I haven't removed R48 yet. Looks like that's next. Your SPI adapter is lots neater than mine. I'll check mine with an ohm meter again as it's easy to get the even and odd pins wrong when you're an autistic with spacial problems. 

 

My thread has never appeared on Microchip's forum. Perhaps shoes are required?

The largest known prime number: 282589933-1

It's easy to stop breaking the 10th commandment! Break the 8th instead. 

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

My thread has never appeared on Microchip's forum. Perhaps shoes are required?

 

Your account and first post as a newbie has to be Moderator approved.

 

For my SNAP post, (first post), it took almost a week before my post was approved.

Apparently their Moderators don't spend as much time on their Forum as our (outstanding!) Freaks Moderators do.

 

That delay is real helpful when one is trying to solve a problem...

 

Back in the day I seem to recall being told that MC/AVR was working on automatically making our Freaks log ins work on the MC site.

That, apparently, never happened.

 

JC

 

Edit.  typo and attitude...

Last Edited: Sat. May 11, 2019 - 06:32 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I decided it was about to SNAP my patience & put it aside, until I need a new dose of aggravation. 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

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

To help deal with that aggravation, I just ordered a new Atmel-Ice.

 

"The Freaks" are probably the main reason I have stayed with AVR so long. If the new overloards wished, I would help "freak" their site.

 

Oh, yes. Here is what MPLAB says when I try to program a 4313 on the pc. Haven't tried it on the mac yet.

 

 

The largest known prime number: 282589933-1

It's easy to stop breaking the 10th commandment! Break the 8th instead. 

Last Edited: Sun. May 12, 2019 - 01:56 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


Torby,

 

I was more thinking about this:

 

it is a post by this guy:

 

It was a rather long post were he seemed to have a couple of more tips/tricks.

I stopped reading at the first quote and did a quick scan on the rest.

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

You know. I think I saw that... I'll (forget to) try it tonight.

The largest known prime number: 282589933-1

It's easy to stop breaking the 10th commandment! Break the 8th instead. 

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

MPLAB Snap

...

50% Off - Use Coupon Code : TP1973        Expires : 30-Sep-2019

...

via Dev Tool Deals | Microchip Technology

current stock is 10895

2 week lead-time

 

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

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

Release Notes for MPLAB® Snap
In-Circuit Debugger & Device (Non-Production) Programmer

MPLAB® X IDE v5.25

__firmware__

 

August 2, 2019

 

...

 

1        Device Support

[MPLAB Snap is all beta for AVR in MPLAB X v5.25; tested (not beta) for a significant subset of PIC, PIC24, dsPIC, PIC32, and SAMS70Q19]

 

...

 

4        What's New in v5.25

·Support for AVR-mode CDC implementation on MPLAB PICkit 4 and MPLAB Snap. See Virtual COM Port for more information.

 

5        Repairs and Enhancements Made in v5.25

·SNAP-21:Verify failure on some older revs of PIC16(L)F182x/193x.

 

6        USB Port Setup

When MPLAB X IDE (v5.05 or greater) is installed the MPLAB Snap In-Circuit Debugger will automatically update any necessary device drivers upon connecting to USB.

 

7        Powering the Debugger and Target Board

The MPLAB Snap debugger derives power via a cable connected to the Micro-B USB connector and the computer. The target board must be powered from its own supply.

 

8        Setting Up the Debugger and Target Board in MPLAB X IDE

To set up the MPLAB X IDE:

1.      Launch MPLAB X IDE.

2.      In MPLAB X IDE, create or open a project with the debugger selected as the Hardware tool. The debugger will automatically connect when code is executed. (To always be connected, see Tools>OptionsEmbedded,Generic Settings, “Maintain active connection to hardware tool”.) Also, the debugger can automatically detect if it has been disconnected/reconnected and if the target has been disconnected/reconnected.

3.      The debugger will now be ready for use.

 

9        Virtual COM Port for AVR Devices

The Virtual COM Port is a general-purpose USB serial bridge between a host PC and a target AVR device.

The AVR-mode CDC implementation on the MPLAB PICkit4/SNAP Virtual COM port supports:

·Baud rates in the range 1200 bps to 500kbps

·Only 8-bit character format

·No hardware flow control

·One or two stop-bits

IMPORTANT NOTE: Connecting to the Virtual COM port from a terminal emulator will enable pins 7 and 8 on the MPLAB PICkit4/Snap header as TX and RX pins. This functionality is independent of the debugger functionality. You must ensure that you do not use CDC at the same time as a debug interface which also needs those pins, for example JTAG or SWD.

 

10    Known Problems

The following is a list of known problems. For information on common problems, error messages and limitations please see Troubleshooting in the on-line help file for the MPLAB Snap debugger.

10.1   Communications

Use a full-featured Micro-B USB cable (data and power), no longer than 1.5 meter, to connect to a computer (for example, the Microchip Part Number ATUSBMICROCABLE-XPRO). Ensure that the cables you use are USB 2.0 compliant. If you are using a hub, it must also be High Speed USB 2.0 compliant.

10.2   Tool SSRs (System Service Requests)

SNAP-48

Using MPLAB X IDE/IPE v5.25 the MPLAB PICkit 4 and MPLAB Snap ICD tools cannot program/debug the specific devices at the Vdd minimum voltage of 1.8 V (with respect to Vss). Workaround: Raise the Vdd voltage supplied to the part to 2V or higher.

AVR64DA128, AVR48DA128, AVR32DA128, AVR28DA128

 

...

 

10.3   Other Tool SSRs (System Service Requests)

The following is a list of issues that are being tracked for other tools but are related to this tool.

PK4-31

The firmware update will fail with either the MPLAB PICkit 4 or the MPLAB Snap ICD tool, when using:

- USB Full-speed port 
- USB Full-speed hub 
- USB Full-speed isolator

Workaround:

The tool would have to be plugged into a USB Full-speed or USB SuperSpeed USB port/hub/isolator to allow the firmware update process to complete successfully.

After the firmware update completes, the tool can then be plugged back into a USB Full-speed port/hub/isolator.

 

...

 

10.4   Engineering Technical Notes (ETNs)

The following ETNs are related to the MPLAB Snap in-circuit debugger. Please see the product webpage for details.

·Engineering Technical Note #36 MPLAB Snap AVR UPDI/PDI/TPI Interface Modification

 

11    Important Notes

...

 

11.2   AVR UPDI/PDI/TPI Support

A 1K ohm pull-up resistor must be installed between the MPLAB Snap ICD ICSP connector's (PCB reference designator J4) pin 4 (PGD) and pin 2 (VDD) to allow proper programming/debugging support for AVR parts that support the UPDI/PDI/TPI interface.

Note: If this 1K ohm pull-up resistor is not installed a 'PDI physical timed out. (25)' message will be issued for various operations in the MPLAB X IDE or MPLAB X IPE GUI.

 

...

 


MPLAB Snap (on sale at 50% thru 30-Sep'19, get two so one has ETN 36, get three if simultaneous debugging and USB CDC ACM)

ETN36_MPLAB Snap AVR Interface Modification

MPLAB® SNAP AVR UPDI/PDI/TPI Interface Modification

https://www.microchipdirect.com/product/Other?keywords=ATUSBMICROCABLE-XPRO

 

edit :

MPLAB X IDE | Microchip Technology

 

edit2 :

MPLAB® Snap Additional Items Needed - Developer Help

 

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

Last Edited: Tue. Aug 6, 2019 - 10:42 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Question about VTG: I'll only be using a SNAP for the new 0- and 1- series tinyAVRs (402/817 etc) over UPDI. For my PICs, the PICkits could supply 5V to the target and things were easy, but the AVRs require external power. Since the SNAP PCB is exposed, can I simply connect the VTG pin on the connector with the 5V line coming from the microUSB port so that the target AVR gets powered by the USB bus? I understand that the SNAP will always read and get a target voltage whenever it checks, but are there any other issues which would make this not work (or do something worse)?

-Sam

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

VTG is a level sensing input. It's so the programmer/debugger can adapt its other signals to either 3.3V, 5V or other Vcc levels.

 

Just build your circuit with it's normal power supply and power as the eventual device will then attach the debugger to that and it will adapt.

 

To power it I guess you could just run a cable from a second USB port on the PC and use the two outer lines which are 0V and 5V. Just don't try to pull more than 100mA.

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

Thanks clawson. I understand the VTG pin function, however my boards will only be 5V circuits, so I could do without the whole level shifting shebang. I'm sure there are better ways to get my target powered (like the USB thing you suggested), but do you think there is a problem if I feed the target power from the microUSB 5V via the VTG connector pin? In my (admittedly limited) knowledge, it would just be the same as powering it externally through another USB port, except that the SNAP would always sense 5V on the VTG pin, even when there is no target connected. Would that cause any issues with programming? 

-Sam

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

I don't see how that can be a problem, it would be like VTG is permanently connected to the target's VDD. It shouldn't cause any damage.

 

Edit: in fact the snap has mounting holes marked 5V0 and a 3V3 it should be easy to wire to VTG.

Last Edited: Tue. Aug 13, 2019 - 03:22 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've done something similar on my dragon debugger, wiring the vcc to vtg pin, works fine, however there is always the danger of connecting it the first time to an unknown board that has a vcc/gnd short somewhere and either damaging the snap or worse the USB port in your PC!!!   You have been warned. 

 

Jim

 

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

share.robinhood.com/jamesc3274
get $5 free gold/silver https://www.onegold.com/join/713...

 

 

 

 

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

Jim, good to know you've done it and it works. Your warning is good advice, I guess that's a chance I'll have to take. (I also usually test a board's power supply before connecting a programmer). Plus most computers I've had this issue with have shut the USB port down as soon as an overcurrent was detected.

-Sam

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

Friday Free Board Quiz – Week #92 prize is USB isolator | olimex

[picture then first paragraph]

USB-ISO is galvano isolator of your PC USB port with 1000VDC isolation. It’s must have device if you deal with Arduino prototype boards as in case you wired something wrong you can burn your PC or laptop USB port. USB-ISO will protect it. Also lot of people use USB-ISO for Audio DAC ground loop isolation.

via https://olimex.wordpress.com/?s=USB-ISO

 

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

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

samay wrote:
Plus most computers I've had this issue with have shut the USB port down as soon as an overcurrent was detected.
That can literally be blown through; one way is by mis-wire.

Protect Equipment with USB Isolators - B&B Electronics

... and its leads [hot, neutral, or ground] had been reversed to keep it [machine] from tripping a GFI switch. As the laptop and the connected device now had different ground potentials, the USB cable became the path to a lower ground state. It was an expensive lesson.

...

Southwire Southwire 120V AC Receptacle Tester at Lowes.com

 

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

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

Good morning,

 

I've bought the Snap recently and modified it a bit, shorting the USB 5V to VTG. 

But for one project i need a programmer with HV-UPDI, so i've started another project to make an adapter:

 

 

The component values are yet temporary, probably will need some tweaking to work properly.

My idea was to measure the UPDI signal from Snap, and when the programming starts, send a generated 12V to target.

The generator is a simple voltage multiplier with 5V and 12V zener diodes for protection.

The attiny5 generates alternating signals to the generator.

My plan was to NOT remove the updi pull-down resistor and instead add a 1k pull-up, then measure the levels with adc.

From what i've probed the updi line sits a bit under 4V idle and rises to over 4.5V for about 2.5ms, so after detecting a 1ms of over 4.5V the attiny5 will open the 12V output for about 1ms.

It would be simpler by just removing the pull-down, but i didn't want to modify the Snap too much. 

 

 

I've also added a jumper to connect the generated 12V directly to RST for HV-TPI programming.

Removing the jumper disconnects the 12V output. 

 

Now i wonder, does this circuit make sense so far? 

Should i change or add something?

 

Thank you.

 

edit: Updated the bottom layer.

Last Edited: Fri. Aug 16, 2019 - 11:18 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, maybe it will work, depends on how much time you have from when the snap sends the UPDI enable signal until it sends the first programming signals.

Seems a good idea to me.

 

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

current stock is 10344

 

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

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

clawson wrote:

So while you work in debugWire mode there isn't really any need to switch out of it because each time you start to debug the most recently built code will be programmed into the device anyway.

Why does AS7 have the option to choose "Release" or "Debug" if it recompiles anyway?  I always change the setting to "Debug" when I am going to use debugWire.  I do the same with JTAG.  Do I not have to do that?

 

clawson wrote:
As a Porsche owner/driver I cannot help but think I would never give up the almost unlimited power available to me when I actually need it. No one says you have to use it all the time but on the odd occasion it's nice to be able to push the throttle and know you will have extraordinary acceleration if you need it.

I feel the same way about my Mini, but it is probably not as fast as your Porsche.  But it will do 140 MPH, and accelerates pretty hard.  Although when it come to acceleration, it is hard to beat a liter motorcycle.  0 to 60 in 3.1 sec.  I dont ride one any more because my hands go to sleep after about an hour, and the last time I dropped my liter bike I had to ask a couple of girls to help me pick it up.  Now I have a 150cc motor scooter that will get up to 62 MPH

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

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

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

nop

Last Edited: Tue. Sep 17, 2019 - 04:11 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I purchased the SNAP device hoping I could use it to program an ATtiny84 however, the documented pinout of the SNAP and the SPI of the ATtiny84 doesn't seem to align.  From what I can tell from the ATtiny84 datasheet, it uses SPI for ICSP, i.e.

 

  • pin-1 of SNAP (reset) should go to pin-4 of the chip
  • pin-2 of SNAP (Vcc sense) should go to the Vcc of supply of the chip (pin-1), which I have at 3.3v from it's own regulated supply 
  • pin-3 of SNAP should be common ground
  • pin-4 of SNAP, serial data out should go to pin-6 of the chip, MOSI
  • pin-5 of SNAP, serial clock out should go to pin-9 of the chip

 

So where do I connect pin-8, MISO ?  How can the SNAP read from the chip?  The SNAP datasheet says it can program/debug any AVR chip, but I don't see how.  Am I supposed to somehow multiplex SNAP PGD (pin-4) back and forth on the chip's MOSI/MISO?  ...but without a direction signal, I don't see how.

 

The basic mismatch is the SNAP only has clock/data (two wire) but the SPI of the chip has clock and separate data-out/data-in (three wire).

 

BTW, I also did the board mod of removing pull-down R48 and substituting a 10K pull-up.

 

Any ideas?

 

Last Edited: Thu. Sep 19, 2019 - 03:32 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

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

Hi, thanks for the response - I actually have seen this pinout image before posting, but I don't see how it relates the SNAP data/clock (pin-4/pin-5) to the ATtiny84 SPI ICSP requirement of clock/MOSi/MISO ?

In other words, what specific SNAP-to-ATtiny84 connections are you recommending, like pin-for-pin, specifically..

 

.

 

Last Edited: Thu. Sep 19, 2019 - 03:52 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

forget the picture you saw, and use the page Meolsen gave you the link to to connect your Pickit to the ISP connections.

 

Use the " AVR ISP" connections column.

that should work.

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

Ok, I tried the "AVR ISP" pinout and SNAP pin-6 (~RESET) never goes low - it's always at nearly Vcc (3.3) and SNAP pin-6 (SCK) is always low - never any clock.  When I bring up MPLAB-IPE, it detects the SNAP because when I connect the USB, the IPE Tool drop-down changes from blank to "Snap S. No. XXXX..." the "Device" drop-down is set to "ATtiny84" and the indicator stays yellow, never green.  The "Active" LED on the SNAP device is always solid green, the "Status" LED never comes on or flashes.

 

For comparison, I can take the PIC "Curiosity" dev. board and connect the USB and start the same IPE and it recognizes the board and the PIC16F1619 chip and I can extract the current chip's program into a hex file.  I can compile an example with MPLAB-IDE and upload a new hex file with IPE and it runs.  So the USB port is good, the installation of IPE is good.  I can scope the SPI data/clock pins of the PIC board and see valid serial signal, so my scope usage is correct.

 

I tried two different blank ATtiny84 devices - nothing.  I think the SNAP device may be messed up. I will open a ticket with Microchip.

 

I may also resort to using an Arduino board as an AVR programmer, although I would have to use the Arduino IDE and libraries, which is OK for trying to get any kind of traction with AVR devices.  I really would prefer to use MPLAB IDE/IPE and not rely on Arduino libraries.

 

https://www.instructables.com/id/Arduino-Uno-to-Program-ATTINY84-Arduino-V-185/

https://code.google.com/archive/p/arduino-tiny/

 

Last Edited: Sat. Sep 21, 2019 - 04:30 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Does your Snap work with a PIC target?

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

cwolf wrote:
I think the SNAP device may be messed up. I will open a ticket with Microchip.
due to post 75, MPLAB® Snap Troubleshooting - Developer Help

 

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

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

@mraardvark Ah, great idea! I should have thought of that!  So I removed the PIC16F1619 chip from the "curiosity" board and stuck it into the prototype board where the ATtiny84 was, then I hooked up 3.3v (pin-1) & ground (pin-20) to the chip then:

 

  • SNAP pin-1, ~MCLR to PIC16F1619 pin-4 
  • SNAP pin-2, VTG to PIC16F1691 pin-1
  • SNAP pin-3, Vss to PIC16F1619 pin 20 (ground)
  • SNAP pin-4, ICSPDAT to PIC16F1691 pin-19
  • SNAP pin-5, ICSPCLK to PIC16F1619 pin-1

 

Then applied 3.3 supply to the chip and connected USB from SNAP to MacOS laptop and restarted MPLAB-IPE.  Now, unlike the ATtiny84, the IPE was talking to the chip!  (However the virtual GUI LED next to the "Device" drop-down never went from yellow to green, which does occur when using the "Curiosity" board)

 

Connecting to MPLAB Snap...

Currently loaded versions:
Application version............00.00.17
Boot version...................01.00.00
Script version.................00.03.10
Script build number............5aef1e175b

Connecting to MPLAB Snap...

Currently loaded versions:
Boot version...................01.00.00
Updating firmware application...

Connecting to MPLAB Snap...

Currently loaded versions:
Application version............00.03.07
Boot version...................01.00.00
Script version.................00.03.10
Script build number............5aef1e175b
Target device PIC16F1619 found.
Device Id Revision = 0x2004

Next, I tried reading from the chip, which was non-blank:

 

The following memory area(s) will be read:
program memory: start address = 0x0, end address = 0x1fff
configuration memory
User Id Memory
Read complete

While the IPE/SNAP was talking to the chip, unlike the ATtiny84, the SNAP "Status" LED fluctuated with yellow and my scope probe on ICSPCLK showed expected serial signal.

 

I have to say I don't find this surprising because going back to my original question, it seems the ATtiny84 has separate data-in/data-out, i.e. MOSI, MISO, but the PIC just has ICSPDAT/ICSPSCK which is in alignment with the original SNAP pinout which says to ignore pins 6,7 & 8.

 

In other words, the SNAP is documented to have only ICSPDAT on pin-4 and ICSPCLK on pin-5, i.e. it's "2 wire serial", but SPI has separate data-in/data-out, i.e. "3 wire serial".

Last Edited: Sat. Sep 21, 2019 - 06:04 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@gchapman I think because the SNAP device can talk to the PIC chip, it may not need emergency recovery, but I may try that at some point, thanks.

Last Edited: Sat. Sep 21, 2019 - 05:59 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

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

@gchapman I read your citation, which says:

Start by ensuring that the PICkit 4 is in 'EDBG mode', i.e the VID is 0x03eb. This can be done in MPLAB by doing any operation with the PICkit 4 with an AVR as the target device. It should _not_ appear as a Microchip WinUSB Device. 

 

I am not familiar with:

  • EDBG mode
  • VID
  •  

So can the SNAP device really be considered to have the same pinout as PICkit4?  The SNAP documentation says to ignore/not connect pins 6,7 & 8.

 

As for "WinUSB", my host machine is MacOS.

 

Even assuming I could pretend the SNAP pinout was the same as PICkit4, thus using pins 6, 7 & 8 per "AVR ISP" profile here:

https://microchipdeveloper.com/pickit4:interface-pinouts

 

I don't see how that jives with PIC chips only having a single data pin but AVR has separate data-in/data-out ?

 

 

Last Edited: Sat. Sep 21, 2019 - 06:28 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

and earlier in that thread is MPLAB® PICkit™ 4 Debugger Firmware - Developer Help

cwolf wrote:
So can the SNAP device really be considered to have the same pinout as PICkit4?
Yes and am assuming MPLAB Snap firmware is similar to MPLAB PICkit 4 firmware.

cwolf wrote:
I don't see how that jives with PIC chips only having a single data pin but AVR has separate data-in/data-out ?
Yes for AVR ISP (SPI), single data pin for AVR TPI and AVR PDI, shared single pin for AVR UPDI (one pin for clock and data, edit : and debugWIRE)

Connecting the Atmel-ICE | Atmel-ICE

 

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

Last Edited: Sat. Sep 21, 2019 - 06:47 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Huh.

 

I still can't download a pre-compiled .hex file into a Nano.

Are you by any chance trying to program the bootloader, or some other file that doesn't start at 0x0?

 

I just tried some experiments with a SNAP and a PICKit4 using the IPE tool to program an atmega328p (Arduino Clone) with a known working bootloader file (optiboot_atmega328.hex)

This works fine with avrdude and ArduinoISP.

It doesn't seem to work at all with MPLABX_IPE.  And it sort-of looks like it might be an IPE problem with interpretation of the .hex file!

 

Here's the evidence...

 

Suppose that I try to just program an ordinary "sketch" that starts at 0.  Blink, of course:

(oh, shoot me.  It won't let me copy/paste from the IPE output window.  Well, here come some big screen shots!)

 

Fine.  That works fine, and the board sits there and blinks.

 

However, if I try to burn the bootloader, it CLAIMS that it has written.  But it also claims that it has written a particularly weird program memory region (0-0xFF)

As if it got a length from the .hex file (256 words is the correct size for optiboot), but not the correct start address.   The bootloader doesn't work, and if you read the program memory, it shows that the appropriate area of flash has NOT been programmed (and there are "some" zeros in low memory...)

 

 

here's the end of the flash memory, after being read:

 

 

And here's the beginning of the flash.  There are, interestingly, zeros in all the words that an offset copy of optiboot would have had code in.  (ie, the last word that contains code is 0x3fed, and the last word that contains 0 in the read flash is 0x00ed...

 

 

It looks like I get the same behavior with a PICKit4, BTW.

 

I've been using the PK4 successfully burning bootloaders in mega4809, and assorted Xtiny chips.  But they all have the bootloader located at 0x0

 

Last Edited: Sat. Sep 21, 2019 - 08:39 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gchapman wrote:
Yes for AVR ISP (SPI), single data pin for AVR TPI and AVR PDI, shared single pin for AVR UPDI (one pin for clock and data, edit : and debugWIRE)

Connecting the Atmel-ICE | Atmel-ICE

 

This time I ignored the MOSI/MISO pins and connected SNAP pin-4 to ATtiny84 pin-7 and SNAP pin-5 to ATtiny84 pin-9.  ...and this time, it sort of worked. First I tried to read memory, then I tried a blank check from the IPE:


Connecting to MPLAB Snap...

Currently loaded versions:
Application version............00.03.07
Boot version...................01.00.00
Script version.................00.03.10
Script build number............5aef1e175b

The following memory area(s) will be read:
program memory: start address = 0x0, end address = 0x1fff
configuration memory
User Id Memory
Read complete
Warning: Debug bit is set on target image. This may not run correctly in production.

Blank Checking...
Verify failed.  [ Pgm ] at 0x0, expected 0x00003fff, got 0x00000000
You have set the program speed to Normal. The circuit on your board may require you to slow the speed down. Please change the setting in the tool properties to low and try the operation again.
Blank Check Failed

During the above session, I saw the "Status" LED on the SNAP board flickering yellow and I saw data and clock signal on the scope.

 

This only "worked" once, thereafter, the IPE would pop up an error dialog that says:

 

"Failed to connect to device using ISP.

The device might be in debugWIRE mode. If you want to enable ISP, make sure that you have ISP connected according to the tool user guide.  Do you want to disable debugWIRE and enable ISP?"

 

I select "Yes" and see this output:

 

Currently loaded versions:
Application version............1.2.66
Target voltage detected

The following memory area(s) will be read:
program memory: start address = 0x0, end address = 0xfff
configuration memory
Data Flash memory
Unexpected status code when executing ispEnterProgMode, expected 0 but got -64 (Command has failed to execute on the tool)

During the above 2nd session there is NO indication on the SNAP board's "Status" LED and NO serial signal when scoping data/clock.  I also went into the advanced setup of IPE and selected low speed serial and that didn't make a difference.

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

If it's a new SNAP, a lot of them seem to be having trouble out of the box. Regardless, here is what I suggest (to anyone having issues with the thing):

1. Reset the firmware : https://microchipdeveloper.com/snap:troubleshooting

2. After re-flashing, the IPE will redownload the application firmware to the SNAP. I think you're using MPLABX 5.25, the latest one. It doesn't work for me, but v5.10 has worked fine for a while, and it is working with my SNAP after doing step 1. The Application version with 5.10 will be different (0.14.xx instead of 1.2.66 IIRC). Try using that version, hopefully it'll work. 

Good luck.

-Sam

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

Thanks!

samay wrote:
It doesn't work for me, but v5.10 has worked fine for a while, and it is working with my SNAP after doing step 1.
fyi

Programming Center | Frequently Asked Questions | Microchip Technology Inc.

[bottom]

What version of MPLAB do you use?

We currently use MPLAB X 5.10.

The ones at MicrochipDIRECT are likely operating production programmers.

Production Programmers | Welcome to Microchip Technology | Microchip Technology Inc.

  • MPLAB PICkit 4 has some AVR capability
  • MPLAB ICD 4 has no AVR (yet IIRC)
  • Softlog - there's a post about Softlog programmers in this forum
  • MPLAB PM3 - don't know its AVR status

 


MPLAB Ecosystem Downloads Archive | Microchip Technology

 

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

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

samay wrote:

If it's a new SNAP, a lot of them seem to be having trouble out of the box. Regardless, here is what I suggest (to anyone having issues with the thing):

 

Hi Samay - I totally "snapped" and couldn't take it anymore!   I ordered a primitive programmer-only device:

USBASP

 

Obviously MPLAB-IPE doesn't recognize it, but I was able to use MPLAB-IDE and xc8 complier to build a basic "LED flasher" test program.  I took the resulting hex file and flashed my ATtiny84 chip using the usbsap and https://www.nongnu.org/avrdude/

 

I recycled the power and the chip started the LED flasher!

 

I still intend to get to the bottom of the issue with that nightmare SNAP device if it can help me break-point debug.

 

$ avrdude -p t84 -c usbasp -t

avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e930c (probably t84)

avrdude> quit
>>> quit

avrdude: safemode: Fuses OK (E:FF, H:DF, L:62)

avrdude done.  Thank you.

-----------------------------------------------------------------------------------
$ avrdude -p t84 -c usbasp -e -U flash:w:tinytest.X.production.hex

avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e930c (probably t84)
avrdude: erasing chip
avrdude: warning: cannot set sck period. please check for usbasp firmware update.
avrdude: reading input file "tinytest.X.production.hex"
avrdude: input file tinytest.X.production.hex auto detected as Intel Hex
avrdude: writing flash (84 bytes):

Writing | ################################################## | 100% 0.13s

avrdude: 84 bytes of flash written
avrdude: verifying flash memory against tinytest.X.production.hex:
avrdude: load data flash data from input file tinytest.X.production.hex:
avrdude: input file tinytest.X.production.hex auto detected as Intel Hex
avrdude: input file tinytest.X.production.hex contains 84 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 0.07s

avrdude: verifying ...
avrdude: 84 bytes of flash verified

avrdude: safemode: Fuses OK (E:FF, H:DF, L:62)

avrdude done.  Thank you.

 

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

gchapman wrote:
Softlog - there's a post about Softlog programmers in this forum

 

https://www.avrfreaks.net/forum/...

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

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

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

samay wrote:

If it's a new SNAP, a lot of them seem to be having trouble out of the box. Regardless, here is what I suggest (to anyone having issues with the thing):

 

I finally got around to trying to use the SNAP device again - I downgraded MPLABX IDE/IPE to 5.10 and reset the firmware in the SNAP and it still doesn't work.  I know the target chip and breadboard wiring is good because I was able to ISP program it with a different USB programmer and the "avrdude" open source command line programmer.  I will try Microchip support.

Thanks.

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

mishcat wrote:

I've bought the Snap recently and modified it a bit, shorting the USB 5V to VTG. 

But for one project i need a programmer with HV-UPDI, so i've started another project to make an adapter:

 

Small update, the circuit seems to work, but needs some tweaks.

 

UPDI signal waveformSNAP with the adapter

 

EDIT2:

Finally a more proper impulse

Latest schematics

 

Much better impulse, works on an ATtiny814 with GPIO on UPDI. The Snap now can HV-UPDI :) 

I think this is about it for now, i hope it helps someone.

 

EDIT3: Updated the firmware: Added a 2s timeout when the connection is still active

EDIT4: Firmware update: Changed to 1s timeout on active connection, but only after HV impulse

 

Attachment(s): 

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

This looks like an excellent project.  Do you intend to sell these boards?

 

I would assume that the main goal for Microchip was to support PIC and as many Atmel devices as possible.

 

If you add a 5x2 JTAG and 3x2 ISP/dW/PDI/UPDI header footprint it makes your board 100% desirable for AVR users.

 

David.

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

mishcat wrote:

Much better impulse, works on an ATtiny814 with GPIO on UPDI. The Snap now can HV-UPDI :) 

I think this is about it for now, i hope it helps someone.

 

Nice to see you got it to work. I don't have the ingredients to build a board exactly like yours, but maybe one with a switch regulator instead of the charge pump/Zener.

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

david.prentice wrote:

This looks like an excellent project.  Do you intend to sell these boards?

Thank You, 

I never thought about selling them, i'll post the gerber files and BOM when i'll test it some more.

 

 

david.prentice wrote:

If you add a 5x2 JTAG and 3x2 ISP/dW/PDI/UPDI header footprint it makes your board 100% desirable for AVR users.

That's a good idea, i'll try that in my spare time.

 

 

El Tangas wrote:

Nice to see you got it to work. I don't have the ingredients to build a board exactly like yours, but maybe one with a switch regulator instead of the charge pump/Zener.

Good luck ^^ 

It could be done on an Arduino with a few components, just to check the line for a voltage over about 0.9Vcc for 1ms and send a pulse from somewhere.

I even thought about using a 555 for that, but i'll stick with what i have now.

 

Some small hints:

- the board manages to create the 12V on 3.3V Vcc too, but Schottky diodes may work better

- instead of 5.1V Zener i'll use a Schottky towards Vcc in a next revision

- MPLAB v5.25 doesn't program fuses for me, but AS7.0.2389 does when you show unsupported devices (Tools -> Options -> Tools)

- the board is difficult to program now as i have to desolder the chip for every update, i'll look for an easier way

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
  • information sheet is dated 3-Oct'19
  • enclosure by Digi-Key can be printed; 'Remix' button for two changes

MPLAB Snap

...

MPLAB Snap In-Circuit Debugger Information Sheet

...

 

[Overview tab]

...

Files are available for creating an MPLAB Snap enclosure from Thingiverse here.

...

 

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

Pages