MPLAB Snap
http://www.microchip.com/developmenttools/ProductDetails/PartNO/PG164100
...
The MPLAB® Snap In-Circuit Debugger/Programmer allows affordable, fast and easy debugging and programming of most PIC®, dsPIC® and AVR flash MCUs, using the powerful graphical user interface of MPLAB X Integrated Development Environment (IDE) version 5.05 or later.
...
MPLAB Snap
A subset of MPLAB PICkit 4 but with a limitation on UPDI and PDI (not 5V? not 12V?)
MPLAB Snap In-Circuit Debugger Information Sheet
(pages 4 and 5 for 'Interfaces Comparison' MPLAB Snap to MPLAB PICkit 4
Edit: pages
$14.95 while supplies last!
I understand that 'low voltage' means just not 12V. I hope. 5V supported.
They say avr spi support. With only two pins (and reset) ...
They say avr spi support. With only two pins (and reset) ...
they also say "same pinout as PICKit-4, which has more detailed info and shows connections to pins that the main diagram claims are "unused."
... MPLAB X Integrated Development Environment (IDE) version 5.05 or later.
MPLAB Snap device support is a subset of MPLAB PICkit 4.
Most popular AVR minus mega328, minus XMEGA, and minus unified memory AVR (tinyAVR 0 and 1-series, megaAVR 0-series)
http://www.microchip.com/mplab/mplab-x-ide (Downloads tab, Release Notes for v5.05, Device Support.htm)
MPLAB PICkit 4 pinout expanded in
Microchip Developer Help
MPLAB® PICkit™ 4 In-Circuit Debugger (ICD)
Pinouts for Interfaces
http://microchipdeveloper.com/pickit4:interface-pinouts
...
due to https://www.avrfreaks.net/forum/come-join-us-mplab-now-supports-avrs?page=3#comment-2527161
with PCB feet
YouTube
Unboxing the New MPLAB® Snap Debugger
Aug 20, 2018
That's the usual price, 15 USD, that was new there as of 21-Aug'18.
The October sale is a 25% discount at
microchipDIRECT
DEVELOPMENT TOOL DEALS
I got one, using the 25% discount. It's a little thing, I thought it would be more like the dragon. It fits a regular micro USB cable. I'll have to make a scrambler cable to connect to a 6 pin avr connector.
I'm used to flashing my processors. I guess now I snap them.
I'm used to flashing my processors. I guess now I snap them.
Just don't crackle or pop and you're good to go
Torby wrote:
I'm used to flashing my processors. I guess now I snap them.
Just don't crackle or pop and you're good to go
Well, I already fry them.
Hi
Am I allowed to ask some stupid questions?
I have obtained a SNAP and hope to be able to use this for ATmega328x and ATtiny debugging. From gchapman's post
(thank you g) it would seem that the AVR ISP and dW interfaces can be used for these devices.
Now my stupid questions (I ask your forgiveness in advance)
1) Can both the AVR ISP and dW be used for both programming and debug, or must one be used for programming and the other for debug?
2) What is VTG? Is this a potential (positive) supply to the target device? Or is this a supply back from the target for logic-level shifting? Or something else?
3) This image below from westfw's post - thank you too - indicates that pins 6, 7 and 8 either should not be connected or are unused. Should I even ask?
At this point in my learning, I know nothing at all about traditional Microchip parts or technologies and not a great deal about Atmel AVR.
On the positive front, I have got MPLAB X IDE installed on a PC and this seems to recognise the SNAP. My next steps will be to create an 'Hello World' program for an ATtiny85, try to upload that to the target and then try to work out how to debug.
After that I might look into this world peace thing...
Thank you all for the work you have done in creating and maintaining this wonderful forum.
M
VTG is the "target voltage" i.e. VCC from your externally powered AVR chip.
I suggest that you start with Uno hardware. Cut the RESET-EN solder-bridge. This lets you use debugWIRE.
Life is much simpler when you have a regular 3x2 ISP/dW header and a permanent UART-USB Serial link.
MPLABX + SNAP should work ok with the ATmega328P
It probably works fine with ATtiny85. But it is painful to hook up hardware (if you expect readers to guide you through any project)
David.
1) Can both the AVR ISP and dW be used for both programming and debug, or must one be used for programming and the other for debug?
2) What is VTG? Is this a potential (positive) supply to the target device? Or is this a supply back from the target for logic-level shifting? Or something else?
I have obtained a SNAP and hope to be able to use this for ATmega328x and ATtiny debugging.
3) This image below from westfw's post - thank you too - indicates that pins 6, 7 and 8 either should not be connected or are unused. Should I even ask?
My next steps will be to create an 'Hello World' program for an ATtiny85, try to upload that to the target and then try to work out how to debug.
https://www.avrfreaks.net/forum/come-join-us-mplab-now-supports-avrs?page=5#comment-2643626
2) What is VTG? Is this a potential (positive) supply to the target device? Or is this a supply back from the target for logic-level shifting? Or something else?
It's the highlighted option. You can see the level shifters on the snap, close to the data lines, they need to get power from the target device.
When will they provide an updated AtmelStudio that uses MPLAB SNAP as debugger/programmer? :(
I wouldn't hold your breath - it seems pretty clear that the intention is to try and slowly migrate everyone from AS7 to MPLAB
PicKit4 works pretty well in AS7.
I bet that SNAP would appear as a cut-price PicKit4. They would simply disable some devices / features.
It would be wise for Microchip to concentrate on one piece of software.
MPLABX is ok for building projects. In fact it is nicer than AS7 in several ways.
The "MPLABX debug" is not as good as AS7. (yet)
David.
Thank you David.
Another mystery vanishes.
M
Thanks clawson.
That's very helpful. dW is what I will concentrate on for now.
I didn't know that AVR programmers do not provide a power source to the target device. That information will, no doubt, save me a lot of pain downstream.
2) What is VTG? Is this a potential (positive) supply to the target device? Or is this a supply back from the target for logic-level shifting? Or something else?
It's the highlighted option. You can see the level shifters on the snap, close to the data lines, they need to get power from the target device.
----------------------------------------------------------------------------------------------------------------------------------------------------------------
Ah, cool!
Thank you El Tangas
Describe what hardware you have got on your desk.
Uno clone + SNAP + PC is all that you need to get started.
In fact an XMINI-mega328 + PC would be even easier.
Yes you can mess around with breadboards, UART-USB dongles, power supplies, ...
They are all things that can go wrong.
If you stick to common items readers might even walk you through a project (that they can set up on their own desk).
One of the beauties of Arduino is that anyone, anywhere in the world can upload a sketch and run it on their own Arduino.
You can also use the same Uno hardware to run a non-Arduino program. And readers can replicate this too. e.g. from your AS7 project.
David.
bWildered1 wrote:There will be issues; try beginning at https://www.avrfreaks.net/forum/mplab-snap-atmega328pb-program-and-debugwire?page=1#comment-2644391 and subsequent for a few workarounds though there's more information in that thread.I have obtained a SNAP and hope to be able to use this for ATmega328x and ATtiny debugging.bWildered1 wrote:expansion as MPLAB Snap is from MPLAB PICkit 4 which is the follow-on to MPLAB PICkit 3 (PIC only)3) This image below from westfw's post - thank you too - indicates that pins 6, 7 and 8 either should not be connected or are unused. Should I even ask?bWildered1 wrote:tiny85 is beta in MPLAB X v5.15; you may be the first here to try MPLAB Snap with tiny85.My next steps will be to create an 'Hello World' program for an ATtiny85, try to upload that to the target and then try to work out how to debug.https://www.avrfreaks.net/forum/come-join-us-mplab-now-supports-avrs?page=5#comment-2643626
Thanks for the evening's reading, gchapman.
It was interesting.
I hooked up a Digistump Digispark Tiny85 this morning and gave it a spin on MPLAB X with the SNAP. I used a 3V3 supply to the Tiny, and a connection from this to the SNAP VTG (along with GND). The only other connection I made was from SNAP pin 6 - dW - to P5 (RESET) on the Digispark Tiny. Then started a debug session. The end result was this message...
Data transmission failed. Error code -10121 returned while trying to receive USB data.
A communication error with the debug tool has occurred. The tool will be reset and should re-enumerate shortly.
Connection Failed.
Naturally I tried all USB ports and several cables.
(This is a Win7 installation; I also have a Linux system which I might try out, just to see...)
I seem to remember coming across something similar in my late night reading, so I'll go back over that to see what might turn up.
Thank you all for your help and advice.
Will let you know what happens, when I have further news.
M
Seriously. Buy a Uno clone. Cut the RESET-EN solder-bridge. Connect all 6-pins of the ISP interface.
The Unos are very cheap. Check that your clone has a RESET-EN printed on the pcb.
You have a useful amount of memory, peripherals, ...
Existing shields plug and go.
Yes, it is "fun" to squeeze something into an 8-pin chip. Even more "fun" with a 6-pin chip.
It is not a useful way to start learning about the subject.
More of an advanced project for an experienced user.
David.
Data transmission failed. Error code -10121 returned while trying to receive USB data....
Naturally I tried all USB ports and several cables.
,,,
I seem to remember coming across something similar in my late night reading, so I'll go back over that to see what might turn up.
https://www.avrfreaks.net/forum/mplab-snap-atmega328pb-program-and-debugwire?page=1#comment-2655506
The USB issues from MPLAB X v5.15 'Readme for MPLAB Snap.htm' :
...
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).
...
9.3 Other Tool SSRs (System Service Requests)
...
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 isolatorWorkaround:
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.
...
https://new.microchipdirect.com/product/Other?keywords=ATUSBMICROCABLE-XPRO
MPLAB X IDE | Microchip Technology
Describe what hardware you have got on your desk.
Uno clone + SNAP + PC is all that you need to get started.
In fact an XMINI-mega328 + PC would be even easier.
Yes you can mess around with breadboards, UART-USB dongles, power supplies, ...
They are all things that can go wrong.
If you stick to common items readers might even walk you through a project (that they can set up on their own desk).
One of the beauties of Arduino is that anyone, anywhere in the world can upload a sketch and run it on their own Arduino.
You can also use the same Uno hardware to run a non-Arduino program. And readers can replicate this too. e.g. from your AS7 project.
David.
Hi David.
If that post is for me, well let's see...
Test Equipment
DMM, 'scope, Logic Analyser, Component Tester (AVR based), probably some other stuff that I don't use very often
Power Supplies
Various
MCU Dev Stuff
Various STM8S and STM8L based (STM8S103 and STM8L151 probably most common), along with STLINKV2 programmer and debugger
ATmega328P, ATtiny85 devices with an USBASP (and now a SNAP)
STM32F various (along with the previously mentioned STLINKV2)
Some development/experimental boards
Various STM32 Discoveries/Nucleos, a TI Tiva, an Atmel Xplained (think I have two of these somewhere, one with an ATmega328PB and the other an ATtiny817), an MSP430something_or_other (I haven't used MSP430 for some time), and a few Arduino UNOs.
Dev Envs
Atmel Studio 7 (recently acquired, and was trying to get to grips with it when I became aware of the SNAP which led to), MPLAB X, Code Composer Studio (for MSP430), ST Visual Develop (for STM8), Code::Blocks (STM8 and general purpose), Atollic True Studio (STM32), Keil, IAR (used to use for MSP430, way back when), and (various)-gcc, cosmic, sdcc and ARM compilers. I prefer using SDCC with Code::Blocks on Ubuntu for STM8, and would use Ubuntu (or any Linux system) for AVR development if I could (MPLAB X offers that possibility).
Just a general comment, but over the years I have come to dislike Java and .NET based applications intensely. They might produce nice shiny products, but boy are they slow. Yea, I know that includes Atmel Studio, MPLAB X and Eclipse based tools.
I don't have any (current) plans for the MSP430. I do have some projects in mind that I think will suit the STM8x, and I have a couple for the Tiny, and some half-ideas (as yet) for the STM32.
PCs
Win7 64 Bit (pressed back into service and only really used for Atmel Studio)
Ubuntu 16.04 64-Bit (a 14 year old, but still my general use, system)
I've probably left out some stuff.
I suppose I should try to explain where I am coming from and where I want to go.
I used to do electronics (even got one of those engineering thingys a long time ago), and worked in various computer related fields over the years. Then I had what was described to me as a 'Neurological Incident'. Well, a couple of those.
And I have had to relearn a lot of things. (Including reading, which I find very tiring, although oddly I can write...)
Anyway, I have long realised that 'I' learn best when I do, rather than when I read. And so I am going to 'do'.
I am going to 'automate' my home. (That's not the correct term, but it'll do for now.)
I have long wanted to create a Renewable Energy monitoring system, maybe even more than that. Something that would log and report generation and consumption, for instance. And I want to monitor things like room temperatures and ambient temperatures. I would like, maybe, to set up a home brewing system, or home wine making (is there a term for that?) system, and have something monitor, or maybe control, such a system. I will build a greenhouse, and monitor that. And so on.
Then I recently discovered the new fangled idea called Internet-of-Things or IoT (a silly name, but it wasn't me I promise). Now one of the 'problems' I had not found a comfortable solution to was how to transfer data from possibly distributed control and monitoring systems to some central server or hub. I wont go into all of the things I considered, 'coz I when I tripped across this IoT I started getting ideas.
So I invested in a Raspberry PI (RPi) Zero. And I have got that set up and hooked into my home network. And I set up MQTT (just to see if I could).
Now I have discovered there's a problem with the RPi - it really does not like power outages, or other disturbances to its power source. It does not like that at all.
And so the first project for the new me will be an Uninterruptable Power Supply (UPS) for the Pi. The simplest of these would require 2 microcontroller pins, an ADC and a timer. Other functionality could be added, but all would 'fit' into an ATiny85 (I think it would fit an ATtiny13, but time will tell).
Now one of my 'controls' (I can't think of the right word) is to be parsimonious with resources, particularly power. And to make these control and monitoring systems as small and 'mean' (is that the right word?) as I can.
I have created a (provisional) board layout with a Digispark Tiny85 which is 1.5" x 0.8". That will fit snugly onto the Pi and an adjoining LiIon battery system.
The Arduino is fine. For what it is. But small and power conscious it is not. It would dwarf my Pi-Battery 'some word I cannot find'.
And this also gives me the opportunity to 'learn AVR debugging'.
If you get what I mean.
Anyway, sorry for all that rambling.
And thank you David, and all the rest of you, for information you have provided. A lot of my uncertainties are now behind me. I can now move on to new uncertainties.
(...now to get that SNAP debugging for me...)
Just a general comment, but over the years I have come to dislike Java and .NET based applications intensely. They might produce nice shiny products, but boy are they slow. Yea, I know that includes Atmel Studio, MPLAB X and Eclipse based tools.
Is it .NET or the operation of .NET?
Advantages of C# (.NET) and Java are those are memory-safe computer languages and the abstractions; disadvantage is the requirement for computer resources (CPU, memory)
The Visual Studio Code Arduino extension has EDBG; AVR GDB is a recent addition to Visual Studio Code.
Microsoft Visual Studio Code's hardware requirements are significantly less than that of Microchip MPLAB X.
Anyway, I have long realised that 'I' learn best when I do, rather than when I read.
to set up a home brewing system,
And so the first project for the new me will be an Uninterruptable Power Supply (UPS) for the Pi. The simplest of these would require 2 microcontroller pins, an ADC and a timer.
There are PMIC with one or two power inputs, a Li-ion cell charger, buck or buck-boost SMPS, and an ideal diode or two.
There's likely a Pi Hat that will meet your requirements.
PMIC are common for arm Cortex-A and ARM9.
Some PMIC are designed to mate with specific arm application CPU or are already on a SoM.
https://www.avrfreaks.net/forum/avr-studio-mac-linux#comment-2600281
https://code.visualstudio.com/docs/supporting/requirements#_hardware
ATSAMA5D27-SOM1 - Microprocessors
Hi All
I apologise in advance for what is to come.
Preamble
I obtained a SNAP programmer/debugger intending to use with AVR ATmega and ATtiny devices, most notably ATmega328Px and ATtiny85. I installed MPLAB X (5.15) IDE and IPE on a Win7 64-bit machine, but both applications reported problems when attempting to communicate with the target, a Digispark ATtiny85, specifically
Data transmission failed. Error code -10121 returned while trying to receive USB data.
A communication error with the debug tool has occurred. The tool will be reset and should re-enumerate shortly.
Connection Failed.
I tried many things, many suggestions in many posts to no avail until a link to another thread provided by gchapman led me to this
-------------------------------------------------------------------------------------------------------------------------------------------
Ok, I powered up my Snap #2, and out-of-the-box, "Error code -10121". Snap #1 is still working.
I reproduced the way snap #1 started working:
1) select ATSAMC20E1A
2) press Apply
3) press Connect. Some firmware activity takes place. Some Win drivers are installed.
4) select ATtiny1616
5) press Apply
6) press Connect. Some firmware activity takes place. Some Win drivers are installed. This message should appear:
*****************************************************
...
Currently loaded versions:
Boot version...................1.0.0Now Downloading new Firmware for target device: ATtiny1616
Updating firmware application...
From here on, the Snap is "cured". Worked on my 2 Snaps.
edit: forgot to say - this is using the IPE software.
-------------------------------------------------------------------------------------------------------------------------
by El Tangas in https://www.avrfreaks.net/forum/...
I tried those steps with the following results.
(Note: before I started there was a 'Microchip' category in Device Manager)
1. I started MPLAB IPE (hereafter IPE) and selected the ATSAMC20E15A (there doesn't seem to be an 'E1A)
2. I pressed 'Apply'
3. I pressed 'Connect' -> Windows began installing, and successfully installed, a new device which is labelled 'Microchip WinUSB Device'
The IPE failed to connect, reporting the following
*****************************************************
Connecting to MPLAB Snap...
Currently loaded versions:
Application version............00.00.17
Boot version...................01.00.00
Script version.................00.02.77
Script build number............5215401e64
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.02.11
Boot version...................01.00.00
Script version.................00.02.77
Script build number............5215401e64
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.
Failed to get Device ID. Please make sure the target device is attached and try the operation again.
Connection Failed.
-----------------------------------------------------------------------------------------------------------------------
Continuing with El Tangas' steps
4. Select ATtiny85 ('cause that's what I got...)
5. Press 'Apply'
6. press 'Connect' -> Windows began installing, and successfully installed, some more device driver(s)
The Device manager now shows a new category has been created (I didn't notice this at the time) - Human Interface Devices - and a new COM Port has been assigned - 'Snap Virtual COM Port'
A later examination of 'Human Interface Devices' shows
In the meantime, an activity icon adjacent to the IPE 'Connect' button began spinning its wheels, the fans on the PC sprang into life and became laboured after a time. This remained the state for some time. I left it for one half hour, just to ensure that it was really 'stuck' in some sort of loop.
Here's a couple of Windows Task Manager screenshots
At this point I had three options
(i) Unplug and re-connect the SNAP USB cable
(ii) Shutdown and restart IPE
(iii) Shutdown and restart the PC
I tried (i) -> There was no difference. The IPE kept spinning its wheels apparently trying to connect, and the PC CPU usage remained high
Then I tried (ii) -> the CPU usage immediately dropped to zero, or thereabouts
I restarted the IPE.
Pressed 'Connect' -> et voila! SUCCESS!
I then tried to read the configuration bytes on the Digispark ATtiny85, which are non-standard (if I may phrase it like that)
This shows the configuration bytes to be
L: 0x62
H: 0xDF
E: 0xFF
Lock: 0xFF
These are NOT correct.
I had previously checked the configuration bytes using AVR Studio and obtained the following
L: 0xE1
H: 0xDD
E: 0xFE
Well, at least IPE is now trying...
I then shut down IPE and started MPLAB X IDE (hereafter IDE) and tried to read the configuration bytes
Woo Hoo!
And the configuration bytes are correct too!
Then I tried to start a debug session...
OK. Not there yet!
But progress all the same.
It would seem that the MPLAB X install does not install the SNAP drivers correctly. On Windows, at any rate.
My car is due its annual medical, so I'm going to be tied up the next few days and, with other things to do as well, I probably wont be able to get back to this until mid-next week.
I would like to thank you all for your time and the very valuable help you give to those like me.
Where would we be without you?
Take care all
M
ps
One further apology...
When I was trying to work out how to add a picture to a post I added an attachment. Now I cannot work out how to remove that. And I am now too tired to care any more.
So, sorry again.
M
Attachment(s):
The digispark contains USB software and bootloader.
If you attempt to use AS7 the USB/boot code will be erased.
Life is simpler if you use a ATmega328P. You kill the bootloader but you still have the UART-USB comms.
Thanks for your earlier information. You clearly have experience. But I still reckon it is unwise (tm) to start with the Digistump.
David.
The digispark contains USB software and bootloader.
If you attempt to use AS7 the USB/boot code will be erased.
Life is simpler if you use a ATmega328P. You kill the bootloader but you still have the UART-USB comms.
Thanks for your earlier information. You clearly have experience. But I still reckon it is unwise (tm) to start with the Digistump.
David.
Sorry David, but I don't understand.
I must be in a dense state of mind at the moment.
M
In #31 you explain that you have XMINI boards and also ATmega328, ATtiny85 with USBASP.
I conclude that you are not an impecunious 12 year old. You have bought XMINI. You could buy a Uno clone.
You are aware that an external programmer will erase all the AVR memory. Boot section too.
A tiny85 has no Boot section or section specific protection.
I suggest that you gain experience with the XMINI(s) first. One USB cable and away you go!
Yes, we would be happy to walk you through SNAP + bare mega328P. Or even SNAP + bare tiny85.
The Digispark board becomes a bare tiny85 as soon as you erase the chip.
You will need to ask Digistump about debugging a Digispark board without destroying the Digistump USB.
David.
Hi All.
(Continuing from post #33)
Got an hour, so I continued from where I left off last night.
I had got to the stage where MPLAB IPE and IDE were communicating with the SNAP and could (apparently) communicate with the target. The latter seemed to be the case because both IPE and IDE reported successful reads of the target's configuration bytes, although the byte values reported by IPE were incorrect.
In IDE I had then tried to start a dW debug session, and got this...
I continued today by clicking the 'Yes' option in the window above to enable debugWire.
I was asked to toggle the power to the target...
...which I did.
I then tried to start a debug session. MPLAB IDE went through the motions, seemed to compile and upload the code, the PC started to go bananas again (high CPU usage, fans threatened to go on strike...) and remained like this for quite a while. Until I 'Paused' the debug using the icon on the toolbar.
I wont add screenshots of that here, or of MPLAB at that stage.
I have no idea yet how to use MPLAB and the views are strange to me; I am more used to IDEs that automatically open debug windows displaying the code with a cursor halted in an appropriate place, with a window showing registers, and so on.
Anyway, I found an IO View in one of the menus and that opened this
Among the other things on view, the window on the bottom right is showing the registers for Port B.
I toggled the value in PORTB - the Port B output data register - and an LED on the Digispark Tiny85 module switched on and off (having previously made sure that the Data Direction Register for Port B - DDRB - had configured that pin as an output, of course).
So cool!
All would seem to be Right With The World again.
The rest is down to me.
I will have to work with MPLAB to learn how to use it properly.
I can now deem this matter to be been resolved successfully, and get on with those little plans of mine.
Thank you all - I could not have done this without you.
Take care
M
ps
Summary
There remains a bug in IPE - it does not read the target configuration bytes correctly (perhaps it is displaying the device defaults?)
MPLAB install does not install the - Windows at least - SNAP drivers correctly; I used the procedure discovered by El Tangas to kickstart the SNAP driver install, and that seems to have got the beast working
In #31 you explain that you have XMINI boards and also ATmega328, ATtiny85 with USBASP.
I conclude that you are not an impecunious 12 year old. You have bought XMINI. You could buy a Uno clone.
You are aware that an external programmer will erase all the AVR memory. Boot section too.
A tiny85 has no Boot section or section specific protection.
I suggest that you gain experience with the XMINI(s) first. One USB cable and away you go!
Yes, we would be happy to walk you through SNAP + bare mega328P. Or even SNAP + bare tiny85.
The Digispark board becomes a bare tiny85 as soon as you erase the chip.
You will need to ask Digistump about debugging a Digispark board without destroying the Digistump USB.
David.
Ah!
I see!
I think.
The USB comms on the Digispark is of no interest to me.
I use the STM8Sxxx and the STM32Fxxx because of these
And this
And more like those.
Those little boards ease prototyping and experimenting enormously. They can be 'socketted' (or is it 'headed'), it is easy to connect a programmer/debugger, or any other hardware for quick tests/checks.
And that STLINKV2 not only programs but debugs as well.
All for a couple of Galactic Credits.
Other MCUs aren't really available like this.
There are a couple of AVRs on little boards that would make my life easy
With the USBASP for programming
But with no debug capability.
And I think it is rediculous to spend 50 times the cost of the microcontroller on a debugger.
Then along came SNAP.
Which is still far to expensive in my opinion.
But I was given one as a gift.
And so...
And so, I am now looking at using some of those ready made little development boards in projects.
It would be a trivial matter (I know, famous last words) to use an STM8S001J3/8L001J3/8L050J3 for those projects I have in mind that only need a few pins, or limited other resources. But it would be nice to see what I can do with a Tiny...
I have a few ATmega328P on little dev boards. I have one Digispark Tiny85. I think the project I have in mind at the moment would probably fit onto a 'tiny13 so, if it does, I'll get some of those and use one for the 'real' end unit. (I don't suppose you know if MPLAB reports RAM 'usage', if you know what I mean? Actually, that's a question for a different Post/Thread, or this one will spaghettify.)
I have several Arduino UNOs. They're OK. For what they are. But they are not the *most* suitable for pretty much any of the many projects I have in mind right now.
And besides, I want to work out how to use AVR properly. How to debug an AVR using the SNAP. And so on.
There's no point having a SNAP just collecting dust.
David, I really do appreciate all the time and effort you have given me. Many thanks.
Take care
M
If you want to learn AVR I'd get a JTAG model where debugging is the easiest of all. Wouldn't mess about with resource limited Tiny's or some even more limited models that don't have OCD at all.
Is it .NET or the operation of .NET?
Advantages of C# (.NET) and Java are those are memory-safe computer languages and the abstractions; disadvantage is the requirement for computer resources (CPU, memory)
The Visual Studio Code Arduino extension has EDBG; AVR GDB is a recent addition to Visual Studio Code.
Microsoft Visual Studio Code's hardware requirements are significantly less than that of Microchip MPLAB X.
I find that putting Java/.NET onto a PC has a similar effect to that of putting a millstone around the neck of a racehorse. They cripple PCs.
A professor said what one learns by creating with their hands is knowledge they'll remember.
I might 'borrow' that...
I'm short on fermentation process control (temperature, sourdough starter)
Me too. It might be fun finding out...
The simplest is a PMIC (no software)
There are PMIC with one or two power inputs, a Li-ion cell charger, buck or buck-boost SMPS, and an ideal diode or two.
There's likely a Pi Hat that will meet your requirements.
PMIC are common for arm Cortex-A and ARM9.
Some PMIC are designed to mate with specific arm application CPU or are already on a SoM.
Yea.
I have options.
I have an LiION battery holder, an LiION charge controller and several DC-DC converters to choose from. I could put together a 'unit' that the mains would charge as required, and that would provide 5V to the RPi. With a 2250mAh LiION battery and a nominal Pi consumption of 100mA, such a unit should keep the Pi alive for almost a day.
I have one of those 'battery bank' thingies which could probably be modified to do what is described above.
And I recently got myself one of these...
for a couple of Altairian Dollars.
That has all the electronics needed. ('They' seem to call it a 'battery shield'.)
But a power loss to the PI can be so catastrophic that I don't want to go through that again. I have had several recent power outages. And 'lost' the Pi on each and every one.
And so I did a little research.
And it is possible to send a signal to the Pi the 'tell' it to shut down. I have done those experiments, and that part works. A small micro with a single pin monitoring the LiION battery voltage could use another pin to generate the signal required to the Pi. With 2 pins, an ADC and a timer my Pi should be secure. Or at least secure from all but my experiments.
Besides, it challenges me to create again.
The hardest part might be to control 'mission creep'.
Hey, I thought this (getting my SNAP problems sorted out - having to engage with 'the outside world') was going to be tough. But is was enjoyable.
Thanks largely to you guys.
Keep up the good work.
Take care gchapman, and all.
M
https://www.avrfreaks.net/forum/avr-studio-mac-linux#comment-2600281
https://code.visualstudio.com/docs/supporting/requirements#_hardware
ATSAMA5D27-SOM1 - Microprocessors
But a power loss to the PI can be so catastrophic that I don't want to go through that again. I have had several recent power outages. And 'lost' the Pi on each and every one.
Raspberry Pi are popular due to a video camera interface, FOSS image recognition, and embedded use cases (therefore power failures due to battery malfunction or deep discharge)
But is was enjoyable.Thanks largely to you guys.
Flashing the Compute Module eMMC - Raspberry Pi Documentation
MicroSD Memory Cards - Swissbit
If you want to learn AVR I'd get a JTAG model where debugging is the easiest of all. Wouldn't mess about with resource limited Tiny's or some even more limited models that don't have OCD at all.
Ah, but the challenge is in getting control systems as lean, mean, as small as possible.
For me.
I know a guy who put a Porsche engine into a VW Beetle.
I'd be more interested in putting a Fiat Cinquecento engine into a Porsche.
And getting it to do what *I* needed.
M
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.
with Thanks! to mraardvark
for https://www.avrfreaks.net/forum/mplab-snap-atmega328pb-program-and-debugwire?page=1#comment-2673101
the ETN list
Engineering Technical Notes (ETNs) - Developer Help
was updated today to add
ETN36_MPLAB Snap AVR Interface Modification
MPLAB® SNAP AVR UPDI/PDI/TPI Interface Modification
...
I saw to remove the resistor. Haven't done it yet.
Mine gets a communication error when MPLAB (on a PC) tries to program. Hmm. I posted the error message at microchip's forum, but it hasn't been approved yet. I'll try again tonight. If it doesn't work with the peasea, I'll try it on the maque.
If I remember correctly I had a "communication error" the first time, then after launching a session with a PIC part I switched to an AVR and it worked...
If I remember correctly I had a "communication error" the first time, then after launching a session with a PIC part I switched to an AVR and it worked...
I probably won't switch to a pic to try it. Might have money for a new Atmel ICE soon.
Might have money for a new Atmel ICE soon.
Nevermind...
Torby, did a quick search on "mplab snap avr programming"
and that gave me this thread:
https://www.microchip.com/forums...
It seems to be interesting, not the first couple of comments, but later in that thread there is a long story the guy seemed to have tried a couple of things, perhaps have a read at that, and have a look at the search results given by google.
Torby, did a quick search on "mplab snap avr programming"
and that gave me this thread:
https://www.microchip.com/forums...
It seems to be interesting, not the first couple of comments, but later in that thread there is a long story the guy seemed to have tried a couple of things, perhaps have a read at that, and have a look at the search results given by google.
You mean the guy who replied?
" Please use Atmel-ICE, instead of MPLAB SNAP, to program Arduino. "
I'm thinking to buy a "full" Atmel-ICE since I'm interested in the SAM parts and I knew where the SAM cables were many moves ago. Then I'll protect the fragile connector and strap it to a board BEFORE using it.
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...
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).
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.
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?
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...
I decided it was about to SNAP my patience & put it aside, until I need a new dose of aggravation.
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.
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.
You know. I think I saw that... I'll (forget to) try it tonight.
...
50% Off - Use Coupon Code : TP1973 Expires : 30-Sep-2019
...
via Dev Tool Deals | Microchip Technology
current stock is 10895
2 week lead-time
Release Notes for MPLAB® Snap
In-Circuit Debugger & Device (Non-Production) Programmer
MPLAB® X IDE v5.25
__firmware__
August 2, 2019
...
[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]
...
·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.
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
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>Options, Embedded,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.
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.
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
...
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
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)?
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.
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?
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.
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
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.
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
Plus most computers I've had this issue with have shut the USB port down as soon as an overcurrent was detected.
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
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.
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.
current stock is 10344
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?
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
another tip in the last paragraph of https://www.avrfreaks.net/forum/snap-sale-cheeeep#comment-2759736
nop
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?
The pinout in https://microchipdeveloper.com/pickit4:interface-pinouts should work...
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..
.
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.
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/
Does your Snap work with a PIC target?
I think the SNAP device may be messed up. I will open a ticket with Microchip.
@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".
@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.
Maybe MPLAB Snap isn't entering the AVR 'mode'.
https://www.avrfreaks.net/forum/pickit4-not-showing-atmel-studio-7#comment-2678201
@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 ?
and earlier in that thread is MPLAB® PICkit™ 4 Debugger Firmware - Developer Help
So can the SNAP device really be considered to have the same pinout as PICkit4?
I don't see how that jives with PIC chips only having a single data pin but AVR has separate data-in/data-out ?
Connecting the Atmel-ICE | Atmel-ICE
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
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)
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.
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.
Thanks!
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.
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
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:
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.
Softlog - there's a post about Softlog programmers in this forum
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.
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.
EDIT2:
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):
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.
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.
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.
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.
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
- information sheet is dated 3-Oct'19
- enclosure by Digi-Key can be printed; 'Remix' button for two changes
...
MPLAB Snap In-Circuit Debugger Information Sheet
...
[Overview tab]
...
Files are available for creating an MPLAB Snap enclosure from Thingiverse here.
...
The current Microchip web site 404 offer :
...
50% off
Coupon Code: 404Discount
[BUY IT NOW button]
https://www.microchipdirect.com/product/search/all/mplab%20snap
via 404 | Microchip Technology
The coupons SPOOKY68 and 404Discount are not cumulative! I wanted Snaps with 100% discount
Microchip MPLAB PICkit 4/SNAP Cable Selection and Installation | Tag-Connect
...
Our soon to be launched new family of 8-pin TC2040 cables and solutions will support SAM, AVR, and MIPS. For more information or to be added to our notification list please ...
...
MPLAB Snap | Welcome to Microchip Technology | Microchip Technology Inc.
...
30% Off
Coupon Code
TP2023
Expires : 30-Sep-2020
...
...
via Dev Tool Deals | Microchip Technology
edit 2-Sep'20 :
In Stock: 140
In Stock: 100
edit 12-Sep'20 :
In Stock: 82
edit 14-Sep'20 :
In Stock: 73
edit 16-Sep'20 :
In Stock: 44
edit 22-Sep'20 :
In Stock: 21
edit 23-Sep'20 :
In Stock: 19
edit 25-Sep'20 :
In Stock: 16
edit 29-Sep'20 :
Out of Stock
edit 30-Sep'20 :
In Stock: 2
currently 8-pin SIL to 6-pin TC :
You searched for "PICkit 4" | Tag-Connect
TC2030-PKT-SWD SAM debug cable for PICkit4/SNAP | Tag-Connect
...
...
Pinouts for Interfaces | MPLAB® PICkit⢠4 In-Circuit Debugger User's Guide
...
...
stock is low
Has anyone been able to get the CDC UART to work? Apparently, this is a feature that's available when the SNAP is in AVR mode. A serial port shows does up on my computer, but there are no data on pin 7 or 8 when I'm sending data from the serial monitor.
Are you using the DTR signaling?
Not that I'm aware of? I was currently using the Arduino serial monitor. I know it's "dumb", but it pretty much always works. Does the SNAP require handshaking to function as a USB-UART bridge?
I think the same guidelines apply as for nEDBG/PKOB nano - the IO lines are tristate until a terminal connects and asserts DTR (user guide explains this). Some terminals do this, some have a checkbox that needs checking.
Of course also remember to connect VTG as reference for those level shifters.
Of course also remember to connect VTG as reference for those level shifters.
This was the issue, thank you!
I took the time to update the SNAP firmware too. Damn what a stupidly complicated process. I first had to download MPLAB X (Why isn't this possible in AS7), then (according to a writeup @jeruud did here a while ago), create a PIC project, Install XC8, and then press a circulating arrow symbol in GUI. What happened to atfw.exe?
Damn what a stupidly complicated process
Totally agree :/
Release Notes for MPLAB® Snap
In-Circuit Debugger & Device (Non-Production) ProgrammerMPLAB® X IDE v5.45
__firmware__
October 15, 2020
...
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.
...
Pinouts for Interfaces | MPLAB Snap In-Circuit Debugger User's Guide
good day!
cat from avrdude.conf
snap_updi = MPLAB(R) SNAP in UPDI mode
question's...
UPDI - the debug mode (yes/no?)
SPI - can't with snap? for command line programming
- linux x32/64, older & new... :o) - avrdude 6.3-2021.01.17
cat from avrdude.conf
snap_updi = MPLAB(R) SNAP in UPDI modeUPDI - the debug mode (yes/no?)
Yes. Well, UPDI is both upload AND debug, for the chips that support it.
SPI - can't with snap? for command line programming
I would guess that "all" of the UPDI programmers are using the same JTAG2UPDI protocols as the JTAGICE3, so it's really easy to add such programmers to avrdude.conf, because you just alias some new USB ID to the JTAGICE3 protocols.
ISP may not be as easy :-( (although there is a "type = "jtagice3_isp";" used by the assorted XPlained Mini boards and such. Maybe someone just hasn't done it.)
- linux x32/64, older & new... :o) - avrdude 6.3-2021.01.17
None of the avrdude.conf files I can find mention SNAP at all, including Arduino (which has patches) and the CVS sources for avrdude itself. Where did you get yours?
Maybe someone just hasn't done it.)
work is in full swing: o)
Where did you get yours?
+
i need to connect atmega328 ISP to SNAP through avrdude
apparently, it's impossible?
Maybe someone just hasn't done it.)
work is in full swing: o)
i need to connect atmega328 ISP to SNAP through avrdude
apparently, it's impossible?
I've been using the SNAP and the PICkit4 as ISP programmers using this very fork of Avrdude. Works perfectly!
All you have to do is add the SNAP and PICkit4 to the avrdude.conf file, like I've done here: MiniCore avrdude.conf
programmer id = "pickit4_isp"; desc = "MPLAB(R) PICkit 4 in ISP mode"; type = "jtagice3_isp"; connection_type = usb; usbpid = 0x2177; ; programmer id = "snap_isp"; desc = "MPLAB(R) SNAP in ISP mode"; type = "jtagice3_isp"; connection_type = usb; usbpid = 0x217F, 0x2180, 0x2181; ;
thank
edit : oops ... already in post #118
None of the avrdude.conf files I can find mention SNAP at all, including Arduino (which has patches) ...