Atmel-Ice 'loses control' of target?

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

(Studio Ver 7.0.2397, ATMega1284p, Atmel-ICE)

 

In the course of debugging an issue which 'appears' to be an issue that causes the code to return on a destroyed stack (i.e.: execution goes to a totally unexpected code location) my Atmel-ICE or debugger exhibits this behavior:

 

* I place a single breakpoint at a location that is being executed unexpectedly (note: this module was compiled with -O0)

* command "Start Execution and break"

* artificial break at 'main' is hit

* command: Run

* the breakpoint is hit correctly during initialization

* command: Run

* application resumes normally (as indicated by serial port trace info and target board LED activity)

* command: 'break all'

* execution stops at a random (correct) location

* command: Reset (to simulate a reset button press)

* artificial break at 'main' is hit (Init1-5 assumed to have executed but I do not have a breakpoint set there)

* serial port tracing indicates that the application starts normally and the breakpoint is again hit normally during initialization ...

* But then the code (where the breakpoint is) is again executed unexpectedly (as indicated by serial port tracing) BUT the breakpoint is NOT hit. 

* If I hit 'break all' to pause execution, Atmel Studio says "The application is in break mode'. 

* No more Studio commands are effective at this point.

 

This seems to indicate that, when the program bug occurred (again, assumed return on destroyed stack), something happened to cause the Atmel-ICE to loose control of the debugging session. 

 

As I understand it, when a small number of breakpoints are set (i have two, my breakpoint and the temporary "Start Execution and break" breakpoint) the ATMega1284 stores these in a special break register set and does not modify code as it does with a large number of breakpoints.

 

(BTW: there is no bootloader code in memory that could modify flash space.)

 

What could my code have done to cause the Atmel-ICE to lose control of the target?

 

This topic has a solution.
Last Edited: Thu. Oct 1, 2020 - 03:32 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ChuckH wrote:
What could my code have done to cause the Atmel-ICE to lose control

Do you put the CPU to sleep at any point ?

 

 

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

Do you have anything connected to the JTAG lines other than the debugger?

 

If you do, maybe the hardware is affecting the jtag

 

jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

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

awneil wrote:
Do you put the CPU to sleep at any point ?

 

I have not written any code that places the processor in sleep ...

 

I suppose there is library code that was included unintentionally but that's remote ...

 

Chuck

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jgmdesign wrote:
Do you have anything connected to the JTAG lines other than the debugger?

 

There are other chips connected to the /Reset line (CAN bus controller, LED controller, etc.) but none that I know of that actively pull it down.

 

When I designed the board I had placed a reset supervisor on it but I removed that chip due to other issues.

 

BUT ... I just connected my scope to the /reset line and noticed two things:

 

* Apparently the JTAG does not use the /reset line to reset the processor when you press "Reset" in Studio?  I did not see any activity on the /reset line when i hit "Reset" in Studio.

 

* I DID see an anomaly on the /reset line when the issue occurred --- off to investigate that now ! 

 

It's always in the corner of the room you didn't think to look in!  I will report back.

 

Thank You!

 

Chuck

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

ChuckH wrote:
JTAG does not use the /reset line to reset the processor

indeed - this came up the other day: https://www.avrfreaks.net/commen...

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

ChuckH wrote:
* Apparently the JTAG does not use the /reset line to reset the processor when you press "Reset" in Studio?
indecision

I've connected my Tool through a USB Hub, and now I get Error Messages and Inconsistent Results while Programming and Debugging | Atmel Studio 7.0

...

  • If Use external reset is an option for your tool/device combination, enable this

...

 


Connecting to a JTAG Target | Atmel-ICE

 

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

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

jgmdesign wrote:
Do you have anything connected to the JTAG lines other than the debugger?

 

It turned out that, during software initialization of another card on the backplane, 8 LEDs were turned on via an LED driver that was set for too high a current.  This caused the +5 line to momentarily dip.  This was the dip that I saw reflected in the /reset line.  I don't think it was the /reset line itself that caused the 'reset' - I think it was the brownout setting in the processor but your comment and my scoping the /reset line is what led me to the issue.

 

This was probably not causing the software bug I was tracking down (unless it has to do with the brown-out restart) but now at least I can keep connected to the processor and track it down!

 

Thank you again!

 

Regards,

 

Chuck H.

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

ChuckH wrote:
This was probably not causing the software bug I was tracking down

But at least you have now found & fixed that issue - and know that it's not your nice shiny new Atmel-ICE that's broken

 

Time to mark the solution ... ?

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: 2

Bug fixed: Buffer overrun ...

 

Thanks to all for helping me locate this and understand the JTAG a bit more ...

 

Chuck H

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

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