SWD Debugging the Arduino MKR-WiFi-1010 with Atmel ICE

Over the weekend I received my new Arduino MKR-WiFi-1010 (the ABX00023) that I purchased from Amazon, as seen here along with my Atmel ICE:

Warning: after writing this blog I realized that using the Atmel ICE can end up causing problems with the bootloader when later attempting to upload a sketch via the serial port! This was easily resolved (everything is easy, when you know how), but beware.

Update: I wrote this blog on Burning Bootloader from Visual Studio with Atmel Ice for the Arduino MKR WiFI 1010.

Ironically, I found this board shortly after commenting to Peter Scargil that I really didn't think anything could replace the Espressif ESP8266 (other than the ESP32) since it has been around for so long and has such a strong community and momentum. I found the 1010 shortly after seeing a tweet from MicroChip regarding the ATMega4809. (an 8-bit Arduino, 16MHz ceramic resonator, WiFi board using the ECC608 Crypto-Authentication chip for $44.90). The MKR1010 (32 bit!) was listed as "related product".  Now, I knew the MKR-1010 board had been released some time ago - but at the time I seem to think it was rather expensive and didn't think much more about it. However at $29.90 - that's just too appealing to pass up. Amazon prime to the rescue for me gizmo addiction: delivered the next day at no extra change! Thank you Prime!

It has been some time since my last blog post. I have a draft blog of some things that I learned with my new CNC, but it is rather messy at the moment, so instead this weekend I am back to debuggers and this MKR-1010 board.

One of the main points of interest with this board - is that in addition to the SAMD21 (specifically the ATSAMD21G18A) it also has an on-board ESP32 ... and the MicroChip ECC508 Crypto-Authentication chip! Although I really like the ESP8266 boards, I will say that JTAG debugging was not exactly the easiest and most robust, as noted here and here. One thing about the Atmel ICE is that in Atmel Studio, it is a fairly robust and reliable hardware debugger.

So fresh out of the gate, I was disappointed that I did not have a cable for (what I thought) was the Single Wire Debug (aka SWD) connector:

Comparing a 50 mil connector to what I thought was the SWD connector.

Note that black connector not a 0.1 pin spacing, it is already the small 50 mil connector that is on the Atmel ICE. The white connector below is even smaller than that!

I spent an embarrassingly long time scouring the internet for anything I could find on "Arduino MKR 1010 SWD Debugging Connector". I could not even determine what that tiny white connector is called so that I could order one. I even posted a plea for help on the Arduino MKRWiFi1010 forum,

Eventually, I found this post where someone was asking about connecting the Atmel ICE SWD to the MKR-ZERO. Although I had no indication the 6 pads on the underside of my MKR-1010 were actually the J2 SWD pins, I was hopeful that the folks at Arduino would have standards and consistency.

Schematic diagram for MKR-1010 SWD Connector (pads on reverse)

The Maker Zero SWD pins are as shown here, in this diagram provided by Federico_Vanzati:

MKR-Zero SWD Pins for Atmel ICE

Keep in mind I had no experience, no knowledge of the MKR-Zero, however the MKR WiFi 101 is just a bit similar, once you see them both, eh?

MKR-1010 board from the Arduino site

So although I was confident and hopeful that I could finally get the Atmel ICE to connect, I was still stuck with 6 pads and no holes. I really wish the Arduino folks would have made a more debug-friendly connector.

Fortunately, I had some of those snap-apart headers on hand. I bent two sets of 3 pins...

Header with some pins bent for the surface-mount SWD pads.

...and stuck them both into a 6-pin cable connector to hold them in the proper position for soldering:

Preparing the home-made surface mount headers in a 6 pin connector.

Be sure that the longer header pin is not pulled through when bending them: Not only do you want to have a good length for electrical contact, but you also don't want them too long on the PCB. Yes, there's a solder mask layer that should act as an insulator, but I would not count on it.  Make sure that pins are only as long as the solder pads. I needed to trim mine.

Note that using sets of three will increase overall mechanical strength - but as they are surface mounted, care should be taken when inserting & removing connections.

So the reality of annoying future breadboard use becomes quite apparent once the header is soldered in place. Clearly the designer prioritized the Arduino logo over the practicality of pad header placement:

My MKR-WiFi-1010 SWD Header Connection, freshly soldered on

I'm thinking if I plug it into a breadboard, I'll just use some of those stackable headers. Still, this will leave many more mechanical connections and many more places for connection problems.

From the MicroChip / Atmel ICE docs - these are the pins used for SWD on the SAMD21 chips:

SAMD Pins for SWD Debugging with Atmel ICE (from the User Guide)

Upon reading the pinouts and looking at the cables and adapters that I have for the Atmel ICE, I realized that my only option was to use that handy-but-annoying Squid Cable.

Arduino MKR WiFi 1010 with SWD Atmel ICE Pin Numbers shown.

Here's what the board looks like connected to the Atmel ICE:

Arduino MKR-WiFi 1010 connected to Atmel ICE with the Squid Cable.

I sure wish a simple 10-pin header would have been installed on the MKR boards - that would connect directly to the Atmel ICE debugger. Well, no worries.. good to go!

There's a MKR-Wifi-1010 tutorial on actually using the WiFi here on GitHub. I actually used the WiFi tutorial page to get started. I took the ino file and pasted it into the Arduino IDE and compiled to ensure everything was working properly. Then I created a new Atmel Studio project from the ino.

Atmel Studio setup step 1.

And on the next screen, select the location of the ino project from the Arduino IDE:

Atmel Studio setup step 2.

Edit Feb 2019: If you don't see the board listed, then launch the Arduino IDE and ensure it is installed via Tools - Board - Board Manager:

Type "MKR" to shorten the list:

/Edit... back  to Atmel Studio:

Connection in Atmel Studio is pretty straightforward, just select the Atmel ICE and ensure "SWD" is used:

Atmel Studio SWD Debugger Settings for Atmel ICE

After that... voila! Click the Debug menu and step in, set breakpoints, and more!

One thing that is not super obvious when debugging with the Atmel ICE, is most sample code is "wait forever until serial port available" during setup. Well, the Atmel ICE is not the serial port!

  //Initialize serial and wait for port to open:
  Serial.begin(9600);
  while (!Serial) {
    ; // wait for serial port to connect. Needed for native USB port only
  }

So be sure to connect something to the serial port! The serial monitor in Atmel Studio is a bit wonky. I simply use putty.

See the Disassembly tab to view the assembly language generated from the source code:

The Processor button show interesting information:

Also cool to browse and inspect I/O registers:

This is SO much better than a zillion serial.println statements!

Well, I hope this saves you the hassle I encountered when trying to use the Atmel ICE hardware debugger with the Arduino MKR-WiFi 1010.

I've added a MKR-WiFi-1010 GitHub Repository with the source code and relevant pictures and documentation.

So ya, perhaps this Arduino will take over the Espressif chips ... but as there's an Espressif on-board this guy, perhaps that's not a fair comparison. Still - it is a quite interesting board at a somewhat reasonable price.

Resources, Inspiration, Credits, and Other Links:

• WiFiNINA library
• Adafruit's Proper debugging of ATSAMD21 Processors - Restoring Bootloader
• Bootloaders at ArduinoCore-samd/bootloaders/mkrwifi1010/
• MKR1000 Firmware update by badballscrewbob

Please leave comments, ideas, suggestions below (moderated, sometimes delayed) or send me a message at gmail, or find me on twitter.

Serial Port Debugging

Today I'm trying to use the AVR serial port on a custom ATMEGA328 board.

TL;DR

• Know your fuse settings! Incorrect settings can result in timing problems, including incorrect UART baud rates.
• RS232 Serial port UART decoding using Rigol DS1054z Oscilloscope
• How to fix bad baud rate timing with software.
• Programming AVR devices from Atmel Studio and Arduino IDE with Atmel ICE

Try as I might, I simply could not get it to work properly. The LED on the USB/TTL adapter would blink during data transfer, but no data shows up in Putty from the AVR.

After exhausting all obvious possibilities, it was time to get serious about looking at what's going on. Rigol oscilloscope debugging to the rescue!

I had not performed any signal decoding any time recently and needed to refresh my memory.  I tried reading the fine manual, but alas still could not get it to work quite the way I wanted. I found this really quite excellent YouTube video. (I have the DS1054z, but close enough)




In short, the most important thing is that the oscilloscope needs to be "zoomed out" (horizontal scale) when doing single trigger. The full capture is apparently the scale of the visible screen. I might have implemented that a bit differently but it is ok once understood.

Trigger: Menu Button (CH1, falling edge, single sweep). Adjust trigger level to halfway point, in my case 1.6V.

Decode: Math Button, (Decode 1, Decoder = RS232, Decode ON, Tx = CH1, Baud Rate, etc)

First, an example of a properly working H (from "Hello World") as sent by Putty:

Fairly straightforward serial port setup: 9600 8N1. I connected my oscilloscope probe to GND and Tx of a typical USB TTL adapter. Pressing the "H" on the keyboard when Putty has focus, sends a nice, clean RS232 digital sequence to the TTL adapter as shown:

Reminder that UART/TTL RS232 idle is normally high, transmission begins with low start bit, then (in our case) 8 data bits, least-significant-bit (LSB) first, then followed by stop bit (aka mark) which is high.

Note the scale here is 500 μs (0.5 ms) per division. We're seeing about 100 μs per bit. Actually at 9,600 baud, the expected time per bit is (1 bit / (9600 bits / sec)) = 0.0001041667 seconds or about 104 μs per bit.

The ASCII value of "H" is 72 = = 0x4c = = 0b01001000

Indeed we see about 400 μs of zero (1 start bit, and then 3 LSB's of the "H"), a one, 2 more zeros, followed by a one, zero, then return to high for stop.

So ok, the TTL adapter is working. Actually, I already knew that, as I used it to login to the serial port of my Raspberry Pi just to confirm. Ok, so that's the easy one. Now on to the data coming from the AVR. Much more interesting:

Here's the source code in Atmel Studio. Also pretty straightforward:

Here too, 9600, (default 8N1). But with a much different result:

The first curious thing I observed was that the delay(milliseconds) function was off by an order of 16 (as measured by eye).  Note the scale here is 5mS per division; 10x slower that the trace above!

A coding delay(1000) actually waited for approximately 16 seconds. So the first thing I thought was perhaps the timescale was simply off, so I tried scaling the baud rate by 16. No luck.

Ok, this certainly explains why nothing is showing up in putty! First: notice there seems to be a duplicate character! (there's no echo; nothing connected to the Tx pin other than the oscilloscope probe) Next: notice the scale on the properly decoded character above on CH2 is 500 μs/div.  The scale on this AVR data is 5 ms/div.  The first low pulse on CH1 is 400 μs, but on CH2 more like nearly 7 ms (7,000 μs!)

Quick note on the math, assuming we're really off by exactly 16x:

400 μs * 16 = 6400 (or 6.4 ms); more precisely (4 * 104.17) * 16 = 6,666.67 μs (or 6.67 ms)

Unfortunately 9600 * 16 =  153,600 is not a valid baud rate. However 2400 * 16 = 38,400 baud is!

So I tried changing the source code to send a character at 2400 * 16 baud (38,400). However it too could not be decoded.

The AVR serial port does indeed look like it is approximately 16x slower. Zooming in on that first low pulse to confirm:

It appears that that first 4 bit pulse is actually 6.3 ms long. Interestingly it is not 6.4 ms (or more precisely not 6.67 ms). That makes a difference of  (6,300 μS / (4 * 100 μS) = 15.75x, not the nice round 16.  More precisely: (6,300 μS / (4 * 104.17 μS) = 15.12x.

So ok, the good old Microsoft Paint program (glad to hear it will not be retired!)... a quick copy / paste / scale of the non-working (10x scale; recall 500μs/dev vs 5ms/div ) waveform on top of the properly decoded signal shows we're not going to get from here to there with a simple baud rate scale. The data is not just duplicated at the wrong speed, something weird is going on with a lot more data than just a single character:

So it would seem my AVR is not going to be doing any useful Serial Port Communication anytime soon. Perhaps there's something weird going on in Atmel Studio. But of all the people that would know how to properly program an ATMEGA328, one would think it would be the ones that built Atmel Studio, eh? Time to go back to bed, just in time for the sunrise.

UPDATE: Ok, so after getting some sleep I thought more about this problem. I was wrong about the math! I needed a target that is 15.75 (more precisely 15.12) times faster than the oscilloscope is capturing. So I simply scaled the baud rate in the app:

And setting the decode frequency to the un-scaled value... TADA! Perfectly decoded. <Happy dance>.

I've kept the estimated and precise numbers above, as the initial estimate of 15.75x worked, even though 15.12x is the more precise answer. Somewhere buried in the RS232/UART spec is probably a timing tolerance range.

Oh and look at that "extra" data: I'm doing a Serial.println() that includes extra carriage return and line feed chars! <sigh>

Here's a lesson I've repeatedly learned: walking away from a problem can sometimes solve it ten times faster as compared to attempting to brute-force it non-stop. (particularly at 4:00 in the morning, time change day)

Still it is curious that I needed to scale the baud rate by an odd value of 15.75 (?)

So a little bit of googling (ok, imagine being an embedded programmer before the internet, say in the 80's. crazy)... I found this YouTube video on ISP programming problems due to wrong clock frequency:



But that's not really my problem - as I can program it using ISP or debugWIRE, but the clock is still wrong by a factor of 15.12x.

There's still the ISP Clock Frequency setting in Atmel Studio:

But that's just the clock speed at which the ISP is doing the programming; this is not the clock speed of the processor. Eventually I found this interesting clip (starting at about the 1:50 mark):



This does seem like a reasonable solution. Perhaps I should have known there's a frequency setting. How else would the code "know" how long a millisecond is?

But I've never needed to manually set the processor speed ever before and never had any serial problem quite like this. In any case - first time for everything. So I tried values of 16000000UL and 1600000UL, and others. No values of #define F_CPU seemed to help. Ok, at this point I'm glad it was not something so obvious.

I'm think it might be something with the fuse settings, but even with the online fuse calculator, nothing jumps out as the obvious answer.

Stay tuned for an update if I figure this one out. In the meantime to set a baud rate, I'll simply multiple by 15.12 (certainly makes for some not-very-portable code  :|  meh)

/*Begining of Auto generated code by Atmel studio */
#include 
/*End of auto generated code by Atmel studio */

#define  F_CPU 16000000UL # does this actually do anything?

//Beginning of Auto generated function prototypes by Atmel Studio
//End of Auto generated function prototypes by Atmel Studio

void setup() {
  // put your setup code here, to run once:
  //pinMode(2, OUTPUT);
  delay(100);
  Serial.begin(2400 * 15.12); // originally estimated at 15.75
}

void loop() {
  // put your main code here, to run repeatedly:
  Serial.println("H");       // Hello World. (just the "H" to keep things simple)
  //digitalWrite(2, HIGH);   // turn the LED on (HIGH is the voltage level)
  //delay(10);               // wait  
  //digitalWrite(2, LOW);    // turn the LED off by making the voltage LOW
  delay(200);                // wait  HH
}

I've posted my entire Atmel Studio Solution here. (note that it is in the M5-RadioHead branch of my LoRa-GPIO project)

Thanks to this post on the AVR Freaks forum, I did find this setting in Atmel Studio for F_CPU:

Although this certainly does not clarify why the problems exists in the first place. Perhaps if I had found the value something like 1,058,236 here, it would have been more of an AHA moment.  (1.0582 * 15.1195 = 16).  At this point I am thinking perhaps all this may be caused by a bad crystal oscillator. (?)

It was suggested that I use the Arduino IDE to program the M5Stack AVR chip instead of Atmel Studio. I found this forum thread that has the solution for using the Atmel ICE with the Arduino IDE. In particular, the input device, data gateway, and composite devices with hex Id's: 03EB and 2141 need to be selected with the install-filter-win.exe tool:

The Arduino IDE uses avrdude to program the ATmega328; the resultant output looks like this:

avrdude: Version 6.3, compiled on Jan 17 2017 at 12:00:53
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2014 Joerg Wunsch

         System wide configuration file is "C:\Users\gojimmypi\AppData\Local\Arduino15\packages\arduino\tools\avrdude\6.3.0-arduino9/etc/avrdude.conf"

         Using Port                    : usb
         Using Programmer              : atmelice_isp
avrdude: usbdev_open(): Found Atmel-ICE CMSIS-DAP, serno: J4180007xxxx
avrdude: Found CMSIS-DAP compliant device, using EDBG protocol
         AVR Part                      : ATmega328P
         Chip Erase delay              : 9000 us
         PAGEL                         : PD7
         BS2                           : PC2
         RESET disposition             : dedicated
         RETRY pulse                   : SCK
         serial program mode           : yes
         parallel program mode         : yes
         Timeout                       : 200
         StabDelay                     : 100
         CmdexeDelay                   : 25
         SyncLoops                     : 32
         ByteDelay                     : 0
         PollIndex                     : 3
         PollValue                     : 0x53
         Memory Detail                 :

                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           eeprom        65    20     4    0 no       1024    4      0  3600  3600 0xff 0xff
           flash         65     6   128    0 yes     32768  128    256  4500  4500 0xff 0xff
           lfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           hfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           efuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           lock           0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           calibration    0     0     0    0 no          1    0      0     0     0 0x00 0x00
           signature      0     0     0    0 no          3    0      0     0     0 0x00 0x00

         Programmer Type : JTAG3_ISP
         Description     : Atmel-ICE (ARM/AVR) in ISP mode
         Vtarget         : 3.3 V
         SCK period      : 125.00 us

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.02s

avrdude: Device signature = 0x1e950f (probably m328p)
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "C:\Users\GOJIMM~1\AppData\Local\Temp\arduino_build_159166/M5Stack_LoRa_AVR.ino.ino.hex"
avrdude: writing flash (1694 bytes):

Writing | ################################################## | 100% 6.94s

avrdude: 1694 bytes of flash written
avrdude: verifying flash memory against C:\Users\GOJIMM~1\AppData\Local\Temp\arduino_build_159166/M5Stack_LoRa_AVR.ino.ino.hex:
avrdude: load data flash data from input file C:\Users\GOJIMM~1\AppData\Local\Temp\arduino_build_159166/M5Stack_LoRa_AVR.ino.ino.hex:
avrdude: input file C:\Users\GOJIMM~1\AppData\Local\Temp\arduino_build_159166/M5Stack_LoRa_AVR.ino.ino.hex contains 1694 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 7.33s

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

avrdude done.  Thank you.

However I had the same result in needing the baud rate to be scaled by 15x in order for it to work properly. So this was still not the solution.

Many thanks to Jimmy Lai at M5Stack for sending me fuse selection setting pics (there are many settings to choose from!):

In the second and third pic, it is important to note that the DIVCK8 needs to be left unchecked, despite the value here showing 4E in that first pic. The desired values are: CE D9 FF

My fuse settings before:

Notice LOW.SUT_CKSEL! It is set to an internal clock! There's actually an external clock on the board:

Ok, one would think that even with an external clock, if the fuse settings say to use an internal clock - and this is in fact the default value, that it would work properly with the ATmega328p, eh? Apparently not. As seen above, the clock was wildly off.

When changing the fuses, there's a nice indication of what has been changed, but not written to the chip:

When pressing the Program button, there's a warning that if you don't know what you are doing, you might brick the target:

Braving the ominous warning dialog box... My final fuses look like this:

TADA! <big Happy Dance> Serial.println("Hello world") at 2400 baud actually streams out the UART at 2400 baud. Go figure. This was a tremendous amount of time spent on a couple of fuse bit settings. However it was also an awesome learning opportunity.

More coming soon.... now to get those RadioHead drivers onto the AVR...


Resources, Inspiration, Credits, and Other Links::

• Twelve tips for using the Rigol DS1052E Oscilloscope
• Arduino time keeping using millis() is not accurate or correct?
• Debugging AVR Applications with Atmel Studio (YouTube) 
• Atmel: megaAVR Clock Sources and Potential Errors (YouTube)
• How to Use Crystal Oscillators and Write the Fuse Bits to the AVR MCU (YouTube)
• NefitSerial.cpp - Hardware serial library for Wiring
• Fuse Calc
• DS1000z I2C Decoding and Triggering (covers DS1054Z, DS1074Z, DS1100Z, MSO1074Z, MSO1104Z)
• Rigol MSO1000Z/DS1000Z Series Digital Oscilloscope User Guide

Single-Step Debugging the Uno ATMEGA328 (aka Arduino Uno) for the M5Stack LoRa

Today I revisit my old friend, the Microchip Atmel ATMEGA328P (aka Arduino Uno), although this is unlike any Arduino I've had before!

This is a continuation of my previous blog, where I am working on improving the range of LoRa on the ESP32-based M5Stack module. Many thanks to Jimmy Lai that sent me a prototype of the next version of LoRa module!

Note my LoRa board arrived with no headers soldered on. There's not really room for a typical install of the usual jumper headers due to how thin this the module is. I still used the standard header, but given the limited space, I inserted the plastic on the reverse side of the board and snipped off the pins on that side.

I soldered from above. I can't remember the last time I did this - if ever. One thing to keep in mind is to use as little solder as possible, as quickly as possible. The solder will want to wick up the post, making them ever-so-slightly thicker. Also - if there's a glob of solder at the bottom, the jumper wire won't fit all the way, and we're already a little on the short side from installing the header on the other side.

Ready to proceed with the fun stuff...

Upon close inspection of this new LoRa board, there's a tiny ATMEGA328P sitting there! (yes, the same micro-controller in the famous Arduino Uno (see typical Uno schematic).

Unlike a "regular" Arduino, there's no need to cut the trace for "Reset EN". (regular Arduinos programmed with the serial port have DTR connected to reset with a capacitor that otherwise interferes with ISP).

This Mega328 has the 28 pin, MLF form factor:

See the full ATMega328 spec sheet here. This Mega 328 LoRa board is connected like this:

As shown, the Mega328 sits between the ESP32 core and the LoRa RA-02 transceiver. So the plan is interrupt driven LoRa that the Mega328 handles, while I2C will be used to exchange data from the ESP32 core and the Mega328. So before doing anything, this sounds complex enough to need a serious debugger.

Fortunately I already had an Atmel ICE debugger and Atmel Studio 7 installed. As a reminder, here are the instructions:

First: ensure the latest version of Atmel Studio is installed via Help - Check for Updates (I am using Version 7.0.1645). It may also prompt you to update the firmware in the ICE Debugger. (1.27 in my case). See Tools - Device Programming.

The most difficult thing is figuring out the pins to connect. Unfortunately the LoRa module has the ISP connections in a line rather than the standard connection. Adding to the frustration is the fact that the DuPont pins on the octopus cable have taped-on numbers. Although it is handy having the connections labeled, the thickness of the tape makes having 6 of them in a row a very tight fit:

As a feature request, I hope the M5Stack folks consider implementing a standard SPI / ICSP connector:

In the meantime, it would probably be worthwhile to create a custom inline Dupont header using a kit such as this and this crimping tool. (this is incredibly handy to have)

The single most important thing is that: MO = MOSI = TDI (I wasted a bunch of time when I had assumed MO = MisO = TDO; which is not correct!). Also note that nTRST != nSRST.  (yes, I made that mistake, too; my original screen clip did not include the SPI column which makes this more obvious).

These are the correct connections for debugWIRE, aka SPI, aka ISP programming of the M5Stack LoRa ATMEGA328P:

Note that VTG is not suited to power a remote device. This is a power sensor to determine logic voltage levels. Devices being debugged, including this LoRa module most be self powered!

For more information on the ICE Debugger, read the fine manual.

I started with a simple Uno sketch file:

void setup() {
  // put your setup code here, to run once:
  Serial.begin(115200);
}

void loop() {
  // put your main code here, to run repeatedly:
 Serial.println("hello");
}

Then in Atmel Studio: File - New - Project:

Select "Create project from Arduino sketch", edit directories as needed, then press ok.  Next select the file location of the Arduino sketch. Be sure to select Arduino/Genuino Uno for Board:

It may take a short while to create a project.

Once the project is created, click Project - {name} Properties (Alt-F7). Select Atmel ICE Debugger and ensure Debug Wire is selected for interface:

Next - click Debug - Step Into. The first time, there will likely be a warning about fuse settings:

Press Yes to set the fuses appropriately. If you get any other errors, check the wiring. Then recheck the wiring.

If successful, there will be a message that debugWIRE is enabled. BE SURE TO READ THE MESSAGE:

Note that you MUST power cycle the Mega328 (in our case the M5Stack & LoRa). Do not power cycle the Atmel ICE debugger.

Press ok, and VOILA!

I recall reading that the ATMega328 *must* have debugging properly disabled upon completion or Really Bad Things might happen (really?). I still do this, although I've never actually tested it to be sure. While paused at a breakpoint, click Disable debugWIRE and Close.

So the next step will be seeing if I can get the RadioHead drivers working on this new LoRa module... but first I'd like to get the LoRa AVR serial port working.


Resources, Inspiration, Credits, and Other Links:

• HTML Version of Atmel ICE Documentation
• AVR Tutorial
• Engbedded Atmel AVR® Fuse Calculator
• Updating firmware on USBASP bought from eBay
• USBasp - USB programmer for Atmel AVR controllers
• Atmel ICE
• Visual Micro Debugging
• Atmel ICE in Arduino IDE
• Atmel ICE User Guide
• AVR Freaks: Atmel-ICE unable to start a debugWire session
•