Elektronik_Header_3

 

Mating Arduino and Visual Micro

[Dieser Text auf Deutsch]

Searching information on debugging an ensorcelled Arduino without garbling the code with myriads of println() statements, I put hands on an Atmel-ICE without doing much research on tools empowering this ICE for debugging, in advance. Dealing with debugging Arduinos one will stumble over Visual Micro sooner or later and so did I. Somewhere buried in those pages of Visual Micro you find the statement “supports every programmer” so I downloaded the 45 day trial version and gave it a try.

Integration of Visual Micro into Atmel Studio 7 worked like a charm and after getting acquainted Visual Micro with Arduino IDE V1.6 I was able to compile the unchanged .INO code within Atmel Studio and flashed it to my Ardunio.

Compiling in Visual Studio is FAST!
Now we are ready to start debugging, but wait, we need a means for connecting the Atmel-ICE to the Arduino...

    Time leap backwards…
    To get hands on this Atmel-ICE without spending too much money I ordered the PCBA only version, no housing, no wires.

Atmel-ICE board only

    In retrospect, I would refrain from this not so brilliant idea since adaption of the tiny 1.27 mm pitch sockets on the ICE to the more standard 2.54 mm sockets on the Arduino is nearly impossible over here in Germany. I found cable with 1.27 mm double row sockets attached and so only had to DIY the conversion to 2.54 mm socket on the Arduino. For doing so I had to abrade the inner sides of two one row pin headers to achieve the correct distance of the rows. Nothing fun to do.

Atmel ICE with cable and Arduino Nano V3

    Now I was able to attach my ICE to the Arduino Nano for the first time.

Back to present…
Since this was my first encounter with Atmel Studio I had some difficulties finding those correct settings in Atmel Studio to use the ICE as programmer via SPI and as debugger via debugWIRE, respectively.

The Arduino Nano I used for my first steps in debugging has a broken USB chip, so I had to rely on SPI for programming the chip. That worked fabulous, all fine up til now.


Hint
debugWIRE communicates with the target by toggling the Reset line very fast. To achieve a good slew rate on the signals edges there must be no capacitance on this line.

To handle the programming by USB in a comfortable way, the inventors of Arduino tricked the DTR line of the onboard USB serial converter to issue a reset to the ÁC by connecting a capacitor in series between DTR output of the converter and RESET input of the ÁC.
We have to remove this capacitor, or at least its effect on the signal, by cutting the wire between capacitor and RESET input. One has to search a convenient spot to cut so in optimum the reset switch on the Arduino remains functional for issuing a manual reset.

Furthermore the normally required pullup resistor on the reset line has to be greater than 10k. On the various Arduinos I had on hands, there were values between 1k and 10k to be found. The latter can be left untampered, the former must be removed or changed to at least 10k. Removing the resistor is inoffensive when debugging via Atmel-ICE since the ICE has its own pullup implemented, but if you plan to still use the Arduino after debugging, it is advisable to change the value to 10k or above – hey, we are soldering anyway.


Now, on to debugging. In Atmel Studio select Atmel-ICE as debugger and debugWIRE as debug connection. You get informed that you must leave an ongoing debug session by hitting “Disable debugWIRE and Close”. Missing so by ending the session in any other way, even unintentional, you render the SPI interface inoperable and the chip is lost for SPI . SPI and debugWIRE are mutually exclusive and the only way to switch from debugWIRE to SPI is this very button (or its corresponding menu entry “Debug->Disable debugWIRE and Close”).

Ok, as life goes, I missed the correct way and found my Arduino left bricked when dealing with single stepping and such things…

I tried to get information on healing my Arduino via high voltage parallel programming (HVPP), an absolutely sure way to program fuses on a bricked Atmel microcontroller. Sadly all matters of doing so are targeted on the old DIP versions of the Atmels and the fact, that not all signals used for HVPP are brought to connectors on the Arduino does not help anyway.

Digging through several sources of knowledge I finally found the decisive hint.

When installing Atmel Studio a handy command line program, atprogram, finds its way to your computer. By issuing the command

     atprogram -t atmelice -i debugWIRE -d atmega328p dwdisable

Atmel-ICE lets us change back to SPI, unhampered by a crazy state machine graying out vital commands as found in the Atmel Studio IDE.

The above command has to be entered within the IDE in the command prompt window, accessed from the "Tools-> Command Prompt" menu. Immediately after executing the command one has to disable the dwenable fuse via "Tools-> Device Programming". If we cycle power of the Arduino at that point without programming the fuse we are back in debugWIRE mode again.

My thanks on this topic go to Morten Olsen in avrfreaks.net forum.


 My Atmel ICE is the PCBA-only version. A housing for the Atmel ICE would be nice ...

 


Besucher seit
25.11.2000

>