Alternative to ATMEL-ICE, which includes UART?

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

I'm currently using Microchip Studio + ATMEL ICE to program custom PCBs via Debugwire/ISP via a 6 pin Tag-connect header. This all works fine, and I usually send UART data out via separate pins to a UART->USB cable.

 

The ATMEL-ICE apparently has a way to log data via DGI, but it looks like I'd need to use two cables for this (one to program, and another to log data) as all the pins seem mixed up for DGI, and it doesn't use the same ISP/Debugwire pins to send data back from the MCU (in this case ATMega328pb, but I also use others). I have no idea why they decided to do this rather than just accept SPI data back through the same pins used to program, but still...

 

I was thinking of either making a custom patch board to swap between programming/logging mode, but in my tests with the "Visualiser" in Microchip Studio, it seems really unstable anyway, crashing frequently and even if it did work, the visualizer needs to be shut down before programming, then started up again, which also seems to completely block any kind of debugging!

 

I'm wondering if there's a single programmer that can work the same way as the ICE, while also accepting SPI/UART data and displaying it? If not I'll stick with using a separate UART->USB dongle.

Last Edited: Sat. Jan 29, 2022 - 10:02 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

single programmer that can work the same way as the ICE, while also accepting SPI/UART data and displaying it?

Well, the programmer doesn't display anything, it's a bunch of chips & components used to do programming.  They probably just assume you'd want to keep programming connections & and data reporting lines as separable entities (if they forced them to be combined, someone would complain about that). Are you desiring a programmer PC app that also includes some sort of terminal/plotting?  Why not use any terminal program/visualizer that is readily available?    

I've seen some visualizers based upon dumping data into Excel---that seems to give the ultimate flexibility, whicha programmer-based display couldn't match (they aren't gonna reinvent Excel).

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

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

avrcandies wrote:

single programmer that can work the same way as the ICE, while also accepting SPI/UART data and displaying it?

Well, the programmer doesn't display anything, it's a bunch of chips & components used to do programming.  They probably just assume you'd want to keep programming connections & and data reporting lines as separable entities (if they forced them to be combined, someone would complain about that). Are you desiring a programmer PC app that also includes some sort of terminal/plotting?  Why not use any terminal program/visualizer that is readily available?    

I've seen some visualizers based upon dumping data into Excel---that seems to give the ultimate flexibility, whicha programmer-based display couldn't match (they aren't gonna reinvent Excel).

Well the ICE programmer /can/ be used via the DGI interface to accept data, and Microchip Studio includes visualizer tools to show the data in graphs, virtual oscilloscope displays or terminals (or a mixture, as the visualizers can be chained together as sources/sinks and filters). This is what I was referring to. Since ISP programmers like the ICE use the SPI pins to program, it seems strange to use different pins to then accept SPI data back again, since it would already be connected to the board to program...

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

Scerion wrote:
I'm wondering if there's a single programmer that can work the same way as the ICE, while also accepting SPI/UART data and displaying it?
Yes

CDC Interface | Power Debugger (UART)

Using Code Instrumentation | Power Debugger (USART)

 

edit :

Target Connection Pinout | MPLAB ICE 4 In-Circuit Emulator User's Guide

 

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

Last Edited: Sun. Jan 30, 2022 - 12:55 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks, I've spent the last couple of hours making a patch PCB though as I'd rather not deal with that cabling hell. I only have the 6 pin programming pads on the board (very small design) so the power debugger wouldn't work there. It's interesting though, and I'll probably get one.

 

It has 2 six-pin ISP headers connected together, so the ICE plugs into one, and the target PCB into the other. There's a CP2104 UART to USB chip on there connected to the MOSI/MISO pins for RX/TX so I won't need to unplug anything. Also added two jumpers to optionally power the ISP headers from USB 5V/3.3V regulator in case it's handy. Also a reset button and LEDs on the data lines.

 

It's just a variation of a previous dev board I made years ago. Just sent it off to JLC for PCBA :)

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

Maybe too early on a sunday morning to follow along, but I was under the impression that the Atmel-ICE DGI-SPI feature was intended to be able to program an AVR over SPI and then extract (mostly QTouch) data over DGI without swapping the connector.  

 

https://microchipdeveloper.com/a...

https://microchipdeveloper.com/a...

 

Edit: Ah, "UART"  

 

 

Last Edited: Sun. Jan 30, 2022 - 10:10 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Why does the debugger have to do the comms link as well anyway? Can't you just stick an ebay $2 USB-TTL between the AVR UART and a PC terminal like most of us have been doing for decades? 

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

Well,  it would be really nice if you just plugged one cable into your AVR board and you got programming, debugging, serial, I2C, apple pie, ...

 

In fact you do get programming, debugging, serial with an XMINI, XPRO, Curiosity board.

But these have a separate UART connection to the AVR.   i.e. you need more than 3-Wire UPDI or 6-Wire ISP cable.

 

An ARM lets you write to a "debug terminal" via its OCD interface.   Which is handy during development but you lose it when the target is in the field.

 

David.

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

clawson wrote:
Why does the debugger have to do the comms link as well anyway?

Of course it doesn't have to - but it can be convenient if it does.

 

As you've said yourself (and I thoroughly agree) with things like the Xplained boards - you get the debugger an the serial link all in one USB cable.

 

Then again,

avrcandies wrote:
if they forced them to be combined, someone would complain about that

So they can't win!

 

What I'd do, if I found that having separate debugger & UART connections on the target was getting a pain, would be just make a custom adaptor that combined them ...

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

david.prentice wrote:
An ARM lets you write to a "debug terminal" via its OCD interface.   Which is handy during development but you lose it when the target is in the field.
I have a feeling this may be the thing that OP is looking for. In the ARM case the C lib usually has a "hosted" version of printf() so you can simply print stuff and have it directed back up the debug channel and displayed in the IDE. I don't think there's an AVr equivalent. I know that some devices (is it just JTAG ones?) had the "OCDR" register and the plan was that bytes written to that would be readable in the IDE - that didn't allow for a debug log but you could at least put "marker" points in the code to show that it got to a certain point - except that I don't think the mechanism ever worked.

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

I would guess that JTAG OCD has been available in AVRs since ATmega16  i.e. 20 years.

 

If "hosted" printf() was possible,  someone would have done it by now.

It has certainly been present in ARM for more than 20 years.

 

I suppose that I should dig out my Rowley AVR IDE.   If something was possible,  Rowley would have implemented it.

 

David.

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

david.prentice wrote:
handy during development but you lose it when the target is in the field.

Indeed.

 

The same could be said of having it built in to an Atmel-ICE - you'd still have to make provision for a separate UART (or whatever) connection for when you're not using the ICE ...

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


You can buy just the PCBA from Microchip (and Distributors):

https://www.microchipdirect.com/dev-tools/ATATMEL-ICE-PCBA

 

so you could make up your own Atmel-ICE + USB-to-UART + whatever else you like ...

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Seriously.   I bet that 80% of the punters that buy PCBA version never use it.

 

After all,   1.27mm 5x2 headers are not usable by mere mortals.

Without a custom ribbon cable it is pretty useless.

 

In practice it is convenient to prototype with an XMINI, XPRO, Curiosity and ready made external modules.

Then re-build for the smallest, cheapest target MCU on a custom pcb with or without USB, Serial, ...

 

Or some sort of combination.

 

David.

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

david.prentice wrote:
After all,   1.27mm 5x2 headers are not usable by mere mortals.

ready-made cable assemblies are readily available; from there, it's quite easy to break out ...

 

I have done that with the mini ARM  ones ...

 

EDIT

 

But that was a case of need - in general, it's questionable whether it's worthwhile

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Mon. Jan 31, 2022 - 11:41 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

Last Edited: Sat. Apr 2, 2022 - 11:16 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gchapman wrote:
re OCDR, DWDR for a form of instrumented trace.

A good find :)

 

You are mostly right in that this 'never worked properly'...

Those "IDR messages" do work for JTAG parts (and the same features is there in UPDI parts) but debugWIRE can't access this in "run mode" IIRC...

I had some code somewhere that did a slow printf-style IDR terminal in python, but it was slow indeed - default polling rate is 50ms, so 20 characters-per-second.  Then there is the question of blocking-send (intrusive on execution) or cached send (intrusive on sram) which made it a bit of a can of worms...  Still - could be useful for some purposes...

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

mraardvark wrote:
... a slow printf-style IDR terminal in python, but it was slow indeed - ... blocking-send (intrusive on execution) or cached send (intrusive on sram) which made it a bit of a can of worms...
In lieu of, logic analyzer especially if there's a spare port.

Am uncertain when AVR port trace will arrive to MPLAB ICE 4 (present for a significant number of PIC)

 

Protocol decoder:numbers_and_state - sigrok

[end of first paragraph]

... or locations along a code path, ...

Troubleshooting real-time software issues using a logic analyzer - Embedded.com

Instrumented Trace for PIC MCUs and dsPIC DSCs | MPLAB ICE 4 In-Circuit Emulator User's Guide

MPLAB® ICE 4 | AVR Freaks

 

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