ATATMEL ICE debugger Kit - debugging issue

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

Hi All,

 

I am working with microcontroller ATxmega32E5 for that using Basic ATATMEL ICE debugger Kit with PDI interface, running on 4 MHz frequency, I am trying to configure USART using ISR method. my code is correct and I am getting proper output on tera term / terminal after come out from debugging mode, but during debugging mode, I set one break point in ISR routine and trying to debug the code with stepwise execution and I realized that complier not reaches to ISR routine, is there any setting for breakpoint / debugger mode for debugging USART ? or if I did anything wrong please let me know..

I am facing same issue for Timer code, even I tried with another debugger kit with JTAG interface and still facing same issue. Any kind of help will be appreciate, Thanks in advance..

Last Edited: Thu. Sep 2, 2021 - 04:56 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

When debugging, use -Og optimization level!?

 

FF = PI > S.E.T

 

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

The simple answer is that you can't single step a timing-sensitive protocol like UART.

Something like SPI or I2C just depend on edges and states.

 

So the general rule of debugging is to set a Breakpoint and Run.   e.g. stop at the ISR().

 

However any queued TX data is going to get sent as soon as the current byte has completed.

It has already started before you reach the ISR() breakpoint.

 

In practice you just live with it.   e.g. stop after a uart_puts() has completed.   Allow for interrupt TX to drain.

Likewise you stop after a Linefeed has been received.

 

Otherwise you are just sending one character at a time.

 

Let's face it.   You write a uart_putchar() function once.   As long as it comes out at the correct baud rate you are "debugged".

Then you go to a higher level to test interrupts, buffer overflows, buffer draining, ...

 

You can set up the debugger to allow peripherals, interrupts etc when your main code is stopped.

 

Handy tip.  A $10 Logic Analyser can capture your UART baud rate,  SPI, I2C, ... much easier than you can use a calculator (or oscilloscope)

 

David.

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

Set this to false. 
 

Tools->Options->Tools->Mask interrupts while stepping.

“Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?” - Brian W. Kernighan
“Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.” - Antoine de Saint-Exupery

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

rnd@microsetindia.com wrote:
I am facing same issue for Timer code

 

There is also a setting for timer, which allow timers to pause when you actually pause the program while debugging. 

“Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?” - Brian W. Kernighan
“Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.” - Antoine de Saint-Exupery

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

Verify that the breakpoint really is where you think it should be. That is switch from C to C+asm view and look at exactly which opcode the breakpoint has been placed on. Is it where you hoped? One approach is to put an asm("nop") in there somewhere and place the breakpoint on that. In the Asm view is the breakpoint actually positioned on the NOP as you hoped?

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

david.prentice wrote:
you can't single step a timing-sensitive protocol like UART.

Not so sure about that?

 

the UART hardware does all the "timing-sensitive" stuff - all the software sees is the interrupt and status bits.

 

It certainly should be possible to set a breakpoint in an ISR, and step through it.

 

Of course, putting a breakpoint in an ISR will mean that you'll miss any further bytes that come in while you're halted or stepping.

 

(in other words, the bit timing is unaffected; but the byte timing is affected)

 

And, as  ki0bk and  Heisen have suggested, the project does need to be appropriately configured.    

 

Similarly for other interrupts; eg, timers ...

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

Thanks for replay, Yes I am using optimization level = -Og and debugging level = default (-g2)

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

Thanks for replay David Sir,

 

I am quite agree with you but if I wrote the receiver code means I am sending character 'A' from terminal and use ISR(USARTC0_RXC_vect), during debugging I simply set one breakpoint in ISR() and run the code after that I am sending character 'A' from terminal and checking the output on oscilloscope. when its in debugging mode I am not getting any output on oscilloscope, after come out of debugging mode I am getting frame in 1.04 milliseconds on scope which is correct as per 9600 baud rate.

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

Thank you Heisen Sir,

 

I changed setting as you told but still facing same issue, I observed one thing, for USART ISR and Timer ISR I am facing this issue, for ADC ISR and External Interrupt ISR working fine.. may be its timing issue but how I can resolve this ?

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


Try this setting also,

 

 

“Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?” - Brian W. Kernighan
“Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.” - Antoine de Saint-Exupery

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


I am working on Atmel studio 7.0 their is no any option like this...

 

 

Thank You.

 

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

Okay maybe on PDI interface timers don't run when paused during debugging. Not sure.

“Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?” - Brian W. Kernighan
“Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.” - Antoine de Saint-Exupery

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

could it be one of those settings where you have to be in ISP mode to change it ?

 

EDIT

 

Heisen's screenshot in #11 is of an ATmega324PB;

rnd@microsetindia.com is using  ATXmega32E5 

 

It is likely that settings like this will differ between chip families ...

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: Tue. Aug 31, 2021 - 12:09 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I already try with another debugger kit with JTAG interface and their also facing same issue..

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

sorry - that crossed with my update to #14

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: Tue. Aug 31, 2021 - 12:11 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil

 

If I change the MCU then my problem will solve ?

I don't think so.. I think its debugger kit issue and may be there is some setting to resolve this issue but I don't know what's setting exactly..

 

 

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

rnd@microsetindia.com wrote:
If I change the MCU then my problem will solve ?

No - just explaining why the settings you see differ from what  Heisen showed.

I think its debugger kit issue

I doubt it's a problem wit the debugger itself

 

may be there is some setting to resolve this issue but I don't know what's setting exactly

Most likely - but I've not used Xmega.

 

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

Can you be more specific about exactly what it is you are doing, what you expect to happen and what actually happens.

 

Loads of us have developed comms and timer apps using ICEs and breaking in interrupts and I'm not aware of any general problem in that area. If I write something like:

!main(void) 

#include <avr/interrupt.h>

int main(void)
{
    DDRB = 0xFF;
    UCSR0B = (1 << RXEN0) | (1 << RXCIE0);
    UBRR0 = 103;
    sei();
    while(1) {
    }
}

ISR(USART_RX_vect)
{
    PORTB = UDR0;
}

which is about as minimal as you can get to do RXC (this for mega328P in fact), then if I put a breakpoint on the PORTB= line I would expect it to breakpoint there when bytes started to arrive though this would be predicated on the UART timing being right - if not the RX interrupt may never occur.

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

Thanks for replay Clawson Sir,

 

 

please refer my code and let me know If I did anything wrong..

 

 

#include <avr/io.h>
#include <avr/interrupt.h>

 

uint16_t a;

 

int main()
{
    PORTD_DIRSET = 0x10;  // set PORTD pin 4 as a  for LED
    PORTD_OUTSET = 0x10;  // set PORTD pin 4 = 1 (LED ON)
    PORTC.DIRSET = 0x08; //Set Port Pin OUTPUT for UART TX
    PORTC.DIRCLR |= 0x04; //Set Port Pin INPUT for UART RX

    USARTC0_BAUDCTRLA = 105; // Set baud rate 9600           
    USARTC0_BAUDCTRLB = 0;
    USARTC0_CTRLC = 0x03; // Set frame format - 8 bit data, 1 stop bit, parity none
    USARTC0_CTRLB |= 0x18; // Enable TX and RX
    
    USARTC0_CTRLA = (USARTC0_CTRLA & ~USART_RXCINTLVL_gm)|USART_RXCINTLVL_MED_gc;       //Enable interrupt on Rx
    
    
    PMIC.CTRL |= PMIC_MEDLVLEX_bm; // Enable PMIC interrupt. 
    
    sei();     // Enable global interrupts. 
    while(1);
}

 

 

ISR(USARTC0_RXC_vect)
{
    a=USARTC0_DATA;
   USARTC0_STATUS = 0;      // clearing status reg.

   PORTD_OUTTGL = 0x10;    // LED will toggle
}

 

 

 

I set the only one breakpoint on PORTD_OUTTGL reg. in ISR and run the code, then I am sending character from terminal, I am expecting USARTC0_RXC_vect should be execute and complier stop at PORTD_OUTTGL line right ?

but when I run the code, and sent the character from terminal then complier is in running mode only, ISR not executing so LED also not toggling it means complier is not reaching to ISR. then I came out of debugging mode and sent the character again then my LED toggling. It means ISR not working in debugging mode and out of debugging mode its working..

 

instead of LED Toggling I am doing another task for that I want to debug the code, how I can resolve this issue?

 

 

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

Well this is not a solution but it might get you the debugging you need.

 

What ever you are trying to debug in that ISR, just replace it with a function and try placing breakpoint in that function and see what happens. Does it pause then?

 

Surely this is not a good idea to call functions from an ISR but try to keep it short do your debugging and later just remove that function and place it's code in the ISR. ( One thing we know for sure is that if your debugged code works in a function surely it will work in that ISR too later, when we remove the function)

 

OR

 

If the program does not pause. Try setting a flag in the ISR and let the control get out of the ISR.

 

volatile uint8_t test_flag = 0;

ISR(USARTC0_RXC_vect)
{
    a=USARTC0_DATA;
   USARTC0_STATUS = 0;      // clearing status reg.

   test_flag = 1;
}

 

and then later in the main while loop do this :-

 

int main()
{
    PORTD_DIRSET = 0x10;  // set PORTD pin 4 as a  for LED
    PORTD_OUTSET = 0x10;  // set PORTD pin 4 = 1 (LED ON)
    PORTC.DIRSET = 0x08; //Set Port Pin OUTPUT for UART TX
    PORTC.DIRCLR |= 0x04; //Set Port Pin INPUT for UART RX

    USARTC0_BAUDCTRLA = 105; // Set baud rate 9600
    USARTC0_BAUDCTRLB = 0;
    USARTC0_CTRLC = 0x03; // Set frame format - 8 bit data, 1 stop bit, parity none
    USARTC0_CTRLB |= 0x18; // Enable TX and RX

    USARTC0_CTRLA = (USARTC0_CTRLA & ~USART_RXCINTLVL_gm)|USART_RXCINTLVL_MED_gc;       //Enable interrupt on Rx

    PMIC.CTRL |= PMIC_MEDLVLEX_bm; // Enable PMIC interrupt. 

    sei();     // Enable global interrupts.
    while(1)
    {
        if(test_flag)
        {
            test_flag = 0   // place breakpoint here
 
            // do debugging here
        }
    }
}

Once debugged, place your code back into ISR.

“Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?” - Brian W. Kernighan
“Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.” - Antoine de Saint-Exupery

Last Edited: Wed. Sep 1, 2021 - 03:34 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Heisen Sir,

 

 

If the program does not pause. Try setting a flag in the ISR and let the control get out of the ISR.

 

I tried your code and still facing same issue, during debugging the code complier not reaching to ISR. is there any other solution / setting ?