Is it possible to monitor serial using Atmel-Ice? [SOLVED]

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

Hi! I am working on a small project using an Attiny45V. 

 

I am programming it using the Atmel-Ice. This works fine.

 

However I'm away from home and I don't have much hardware to work with. So I do not have any FTDI or USART hardware available etc.

 

I was wondering if you can monitor serial (like in the Arduino IDE) over the Atmel-ICE usb connection?

 

Was having a hard time searching for this. Thanks in advance.

 

EDIT: SOLVED.

I can now monitor arbitrary messages over DGI via SPI on my Attiny45v. Thanks for all the help in this thread.

 

The SPI driver was adapter from this http://playground.arduino.cc/Code/USI-SPI  .

The pinout for DGI <--> SPI is found in http://www.atmel.com/images/atmel-42330-atmel-ice_userguide.pdf .

However what confuses me is that in code the pin PB0 is MOSI, or data in. It worked when this was connected to AVR port 3, which is MISO.

So MISO on the Attiny needed to be connected to AVR por 9, MOSI.

 

Perhaps this is because a chip is normally SPI slave, but I am using the Attiny as master.

 

Also not I had to have the chip select not grounded when connecting the DGI in Atmel Studio.

After connecting DGI, starting it and connecting SPI source to the plugin terminal sink, I simply grounded chip select (to test) and voila it works!

Last Edited: Thu. Jan 5, 2017 - 08:50 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Short answer is no, at least that I know of. Things like Xplain boards that have mDbug?? built into the board allow you a serial com channel as well as debug functionality over the USB link.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

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

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

hmm interesting, never used that feature as I usually have real ports available.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Appears that Virtual COM will be a better fit for grindv1k

http://www.atmel.com/Images/Atmel-42745-ATtiny817-Xplained-Pro_User%20Guide.pdf

(page 20)

4.4.2.  Virtual COM Port

The Embedded Debugger acts as a Virtual COM Port gateway by using one of the ATtiny817 UARTs. For

further information on how to use the Virtual COM Port, see section Embedded Debugger.

...

4.4.3.  Atmel Data Gateway Interface

...

Atmel Data Visualizer

...

EDBG User Guide

...

via

http://www.atmel.com/tools/attiny817-xpro.aspx?tab=documents

 


https://gallery.atmel.com/Products/Details/8110ea63-a8fa-48b3-a079-3fe273e5c37f (Atmel Gallery, Atmel Data Visualizer)

http://www.atmel.com/Images/Atmel-42096-Microcontrollers-Embedded-Debugger_User-Guide.pdf (page 5, 3. Virtual COM Port)

 

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

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

Don't know if this will also help but what about one of those $10 logic analysers. They have a trigger function so they only start recording when the first pulse arrives. And if it serves any purpose and there's a spare pin on your Tiny, you could also designate another output pin to the logic analyser so you could toggle that pin with each byte sent, just as some indication in the logic analyser display that a byte SHOULD have been sent at that point.

 

Toggling a pin with each byte sent would only add 2 cycles per toggle if you used inline asm to do it. For example "sbi PINB,PINB3", writing a 1 to a PINn bit toggles the port pin.

 

Keith

Last Edited: Tue. Jan 3, 2017 - 09:49 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Artandsparks wrote:
Don't know if this will also help but what about one of those $10 logic analysers. ...

And if it serves any purpose and there's a spare pin on your Tiny, ...

Though the following is an order of magnitude more expensive it will do SWI per an Atmel app note :

Saleae

Single-Wire Interface (SWI)

http://support.saleae.com/hc/en-us/articles/208666916-Single-Wire-Interface-SWI-

 

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

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

gchapman wrote:

Appears that Virtual COM will be a better fit for grindv1k

http://www.atmel.com/Images/Atmel-42745-ATtiny817-Xplained-Pro_User%20Guide.pdf

(page 20)

4.4.2.  Virtual COM Port

The Embedded Debugger acts as a Virtual COM Port gateway by using one of the ATtiny817 UARTs. For

further information on how to use the Virtual COM Port, see section Embedded Debugger.

...

4.4.3.  Atmel Data Gateway Interface

...

Atmel Data Visualizer

...

EDBG User Guide

...

via

http://www.atmel.com/tools/attiny817-xpro.aspx?tab=documents

 


https://gallery.atmel.com/Products/Details/8110ea63-a8fa-48b3-a079-3fe273e5c37f (Atmel Gallery, Atmel Data Visualizer)

http://www.atmel.com/Images/Atmel-42096-Microcontrollers-Embedded-Debugger_User-Guide.pdf (page 5, 3. Virtual COM Port)

 

 

Wow this seems really cool! Using the Attiny45v and the Data Visualizer (plugin?) in Atmel Studio I now get to press Atmel-Ice Data Gateway. Then I can press SPI, USART, and Code Profiling. I can also drag around jack cables... interesting plugin.

 

But as far as I understand I am now supposed to enter debugging while the Data Visualizer is connected.

Atmel Studio says I can not debug using ISP using the Attiny45v.

 

Is the plugin then useless? Or can you use it in some other way?

 

Thanks again.

EDIT: I also tried entering debugWire-mode. It said that since DGI is active I can't use debugWire.

Last Edited: Wed. Jan 4, 2017 - 12:45 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

grindv1k wrote:
Is the plugin then useless?
No; it's either DGI or otherwise.

There can be conflicts between debug (or ISP) and DGI; might need two Atmel-ICE.

grindv1k wrote:
Or can you use it in some other way?
Shouldn't need the DGI extension in this case (AVR UART through Atmel-ICE)

The Atmel-ICE USB interface is composite; per EDBG documentation a COM port should appear that then can be used by your preferred terminal emulator.

Might be easier to burn a bootloader, or, add a second Atmel-ICE connector on the target (1. ISP, 2. COM) and swap the Atmel-ICE between the two.

 

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

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

gchapman wrote:

grindv1k wrote:
Is the plugin then useless?
No; it's either DGI or otherwise.

There can be conflicts between debug (or ISP) and DGI; might need two Atmel-ICE.

grindv1k wrote:
Or can you use it in some other way?
Shouldn't need the DGI extension in this case (AVR UART through Atmel-ICE)

The Atmel-ICE USB interface is composite; per EDBG documentation a COM port should appear that then can be used by your preferred terminal emulator.

Might be easier to burn a bootloader, or, add a second Atmel-ICE connector on the target (1. ISP, 2. COM) and swap the Atmel-ICE between the two.

 

 

This is all a bit new to me but I am trying to follow along.

 

I do not have access to two Atmel-ICE.

 

About your second point: I now have connected up the Atmel-ICE connector on my target Attiny the default (?) way, which I think is programmed with SPI (at least it has MOSI/MISO etc.). I suppose this is the ISP-mode.

 

If I understand you correctly I can program my Attiny, then switch over this connection and then monitor the target through DGI (or a terminal)?

 

I think this then is the right way to connect it:

And then I should be able to monitor anything I send from the Attiny's MOSI pin?

 

Thanks again you have been very helpful! I appreciate if you tell me if I'm headed the wrong direction here.

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

grindv1k wrote:
If I understand you correctly I can program my Attiny, then switch over this connection and then monitor the target through DGI (or a terminal)?
DGI with the Atmel Studio DGI extension, or. your preferred terminal emulator for UART.

The DGI extension has a terminal app though you'll likely want to use your own.

EDBG is USB composite; USB HID for tiny45 ISP or tiny45 debugWIRE OCD, USB CDC ACM for UART (Windows COM)

grindv1k wrote:
And then I should be able to monitor anything I send from the Attiny's MOSI pin?
Per your first post in your thread, USART.

If you want UART through Windows COM then :

Atmel-ICE

Connecting to Data Gateway Interface

http://www.atmel.com/webdoc/GUID-DDB0017E-84E3-4E77-AAE9-7AC4290E5E8B/index.html?GUID-8D4DA50A-2099-481B-82E5-7B4885B82F11

...

Table 1. Atmel-ICE DGI USART Pinout

...

 

 

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

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

grindv1k wrote:

About your second point: I now have connected up the Atmel-ICE connector on my target Attiny the default (?) way, which I think is programmed with SPI (at least it has MOSI/MISO etc.). I suppose this is the ISP-mode.

Correct, PB0, PB1 and PB2 (SPI bus) + RESET is used to program (ISP-mode). Chapter 20.5 Serial Downloading in the datasheet.

 

grindv1k wrote:

If I understand you correctly I can program my Attiny, then switch over this connection and then monitor the target through DGI (or a terminal)?

Correct, you can program your firmware into the ATtiny using the ISP mode, then connect to the DGI interface to monitor incoming data on the DGI interfaces (SPI or USART).
Note that the Atmel-ICE does not feature a virtual COM port so you cannot use a regular terminal like you can with an FTDI / COM adapter.

 

grindv1k wrote:

I think this then is the right way to connect it:

And then I should be able to monitor anything I send from the Attiny's MOSI pin?

Remember that the SPI interface also requires chip select to work, meaning you will have to use PB3, PB4 or PB5 for chip select.
If you use the UART interface instead you can get away with only TX and RX (PB0 and PB1).

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

duzern wrote:
Note that the Atmel-ICE does not feature a virtual COM port so you cannot use a regular terminal like you can with an FTDI / COM adapter.
Thanks for I did not know that.

Could not locate "COM" in the Atmel-ICE manual.

"COM" does exist for EDBG :

Atmel XMEGA A1U Xplained Pro
Embedded Debugger implementation

Virtual COM port

http://www.atmel.com/webdoc/xmegaa1uxplainedpro/ch04s05s02.html

P.S.

Could consider tiny817 or tiny816 as a follow-on to tiny45.

http://www.atmel.com/Images/Atmel-42726-ATtiny817-Xplained-Mini_User-Guide.pdf

(page 18)

4.6.2. Virtual COM Port

via

http://www.atmel.com/tools/attiny817-xmini.aspx?tab=documents

...

ATtiny817 Xplained Mini User Guide
(file size: 1.4MB, 22 pages, revision A, updated: 10/2016)

The Atmel ATtiny817 Xplained Mini evaluation kit is a hardware platform to evaluate the Atmel ATtiny817 microcontroller. Supported by the Atmel Studio integrated development platform, the kit provides easy access to the features of the Atmel ATtiny817 and explains how to integrate the device in a custom design.

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

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

Virtual COM ports are part of all mEDBG and EDBG based products (Xplained Pro, Xplained Mini and Xplained Nano) and acts as a UART -> USB virtual COM port bridge.
DGI is available for EDBG based products (Xplained Pro), the power debugger, Atmel-ICE and JTAGICE3.
All Xplained Pro, Xplained Mini and Xplained Nano supports programming and debugging*
The exception is the ATTiny104 Xplained Nano that only supports programming as the ATtiny104 device does not support debugging to begin with.

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

Thanks for all the help so far. I think I am pretty close now.

 

Now I am trying to make UART work. I am currently seeing nothing on the DGI terminal in Atmel studio using these settings:

The picture shows my settings, and I then "plug" the USART into the terminal.

 

First a silly question in case I have made a silly error, this cable that came with the Atmel-ICE:

The cable is numbered from 0 to 9; but looking at this:

I should have pins 1 through 10 (while I was typing this I check with a multimeter that 2 is shorted to 0 on the cable. So I think that simply 0 == 10 since 2 and 10 are both ground in the Table above).

 

Another kinda silly question: Can I check the frequency of the internal oscillator in any clever way? My multimeter cannot do it, and I do not have access to an oscilloscope. If I understand correctly UART errors commonly come from wrong timing settings (baud rate etc.).

I suspect it is not 8 MHz, since I tried toggling a LED using timer0 overflowing at 0xFF and a known prescaler at 1 second intervals, and it did not work out unless I calculated about 1 MHz as the CPU rate.

But the Fuse in Atmel Studio says 8 MHz.

I suspect this is because I have an Attiny45v, and not an Attiny45. I can only choose Attiny45 in Atmel Studio.

 

 

This might be appropriate for another thread, but if anyone is extra helpful maybe there are any obvious errors in my code (which was taken from http://becomingmaker.com/usi-serial-send-attiny/):

 

/*
 * uart.h
 */ 

#ifndef UART_H_
#define UART_H_

#include <stdint.h>

// Global state
static volatile uint8_t state = 1;

uint8_t reverse_byte(uint8_t x);
void usiserial_send_byte(uint8_t data);

#endif /* UART_H_ */

And the c file:

/*
 * uart.c
 */ 
#define F_CPU 8000000
#define BAUD 9600
#define STOPBITS 1
#define CYCLES_PER_BIT ( F_CPU / BAUD )
/*
*/
#include "uart.h"
#include <avr/io.h>
#include <avr/interrupt.h>
/*
*/
#if (CYCLES_PER_BIT > 255)
#define DIVISOR 8
#define PRESCALE 2
#else
#define DIVISOR 1
#define PRESCALE 1
#endif
#define FULL_BIT_TICKS ( CYCLES_PER_BIT / DIVISOR )
/*
*/
static volatile uint8_t usiserial_tx_data;
/*
*/
uint8_t reverse_byte(uint8_t x)
{
	x = ((x >> 1) & 0x55) | ((x << 1) & 0xaa);
	x = ((x >> 2) & 0x33) | ((x << 2) & 0xcc);
	x = ((x >> 4) & 0x0f) | ((x << 4) & 0xf0);
	return x;
}

void usiserial_send_byte(uint8_t data)
{
	state = 1; // first
	usiserial_tx_data = reverse_byte(data);

	// Setup timer
	TCCR0A = 2 << WGM00; // CTC mode
	TCCR0B = PRESCALE; // Set prescaler
	GTCCR |= 1 << PSR0; // Reset prescaler
	TCNT0 = 0; // Count from 0
	OCR0A = FULL_BIT_TICKS; // Trigger every full bit width
	
	// Select three wire mode, USI counter OVF enable, Timer0 Compare Match as clock source
	USICR = (0 << USIWM1) | (1 << USIWM0) | (1 << USIOIE) | (0 << USICS1) | (1 << USICS0) | (0 << USICLK);
	// USI DO; PB1 output
	DDRB |= (1 << PB1);
	
	// Now load up first 7 bitz (also the start bit)
	USIDR = 0x00 | usiserial_tx_data >> 1;

	// Clear USI overflow flag; set USI counter to count 8 bits (by setting the start value to MAX minus 8)
	USISR = 1 << USIOIF | (16 - 8);
}

ISR(USI_OVF_vect)
{
	if (state == 1)
	{
		// First
		state = 2; // Second

		// Now set the data register to the second byte, and also set the stop bits high.
		USIDR = usiserial_tx_data << 7 | 0x7F;

		// Clear interrupt flag so ISR not serviced infty times; also set counter reflecting # of bits to send(???)
		USISR = 1 << USIOIF | (16 - (1 + (STOPBITS)));
	}
	else 
	{
		// Make sure output is HIGH
		PORTB |= (1 << PB1); 	

		DDRB |= (1 << PB1);

		// Disable USI
		USICR = 0; 

		// Clear intr flag
		USISR |= (1 << USIOIF);
		state = 0; // Available
	}
}

 

And main.c is simply:

/*
 * main.c
 */ 

#include "uart.h"

int main(void)
{
	uint8_t data = 6;
    while (1) 
    {
		usiserial_send_byte(data);
    }
}

 

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

Just to clarify/summarize:

 

SPI is the way to go, both because of the speed over UART and convenience when using ISP with ATMegas.

 

The ATTinies do not have pin direction reversal on SPI, so you will need to physically reverse MISO/MOSI when going between ISP and DGI.

 

Although the JTAGICE3 supposedly supports DGI, Atmel (Microchip) has confirmed that it was never implemented correctly and will not be.

 **** Proposed Resolution Begin ****
The JTAGICE3 only contains the timestamp DGI module. The more complete feature set was implemented on the Atmel-ICE and Power debugger.
 **** Proposed Resolution End ******

The chip select pin needs to be grounded. (If they wrote the software correctly it wouldn't need to be.)

If you are using the 0.050 10 pin to 6 pin ISP cable, you can throw in a grounding jumper to pin 5 on the 0.050 10 pin connector.

This does not interfere with the regular ISP operation.

The advantage here is that you don't have to switch cables and can go right from programming to debug logging.

 

        jtagice atmega328p /e /p /v /b250 blinky.hex
ATmega328p, 32768 flash, 1024 eeprom, 2048 ram
Atmel-ICE CMSIS-DAP J41800073519 01.26.0081
Volts:  4.621
Baud:   250 kb/s
Sig:    1E950F
Lock: FF, XFuse: FD, HFuse: DE, LFuse: FF, OscCal: BB
Erase succeeded
blinky.hex 0000 - 01C1
Program succeeded
Verify succeeded
        dgimon
Hi, I am blinky coming to you over the SPI interface at 8Mb/sec!
Hi, I am blinky coming to you over the SPI interface at 8Mb/sec!
Hi, I am blinky coming to you over the SPI interface at 8Mb/sec!

Photo showing modified SPI connector