Narcoleptic Debugging

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

Gooday wevryone!

I'm working on an issue right now and thought I'd consult minds considerably brighter than mine:

MY JTAGICE MKII and ATM2560 Platform pair has recently developed narcoleptic tendencies on that AVRSTudio says that the target i9s entering and then leaving sleep mode. I don't see how this could be as I'm trying to debug this using a main containing only a while(1) NOP();

INterrupts are disabled. and the naps are only ocuring in RUN mode (which would suggest hardware noise as the root cause, but this target has been in use for months now).

Has anyone else come across this particularly frustrating problem?

DFR

"Life is an exothermic reaction, which increases the entropy of the universe. Save the universe! Kill all life!"

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

danafraymond wrote:
INterrupts are disabled. and the naps are only ocuring in RUN mode (which would suggest hardware noise as the root cause, but this target has been in use for months now).

Months of debugging? Couldn't this be FLASH wear?

JW

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

Swapping out the target platform was one of the first things I tried, but thanks for the thought.

DFR

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

If you have just an infinite loop with a NOP, your compiler will optimize it, probably putting it to sleep.

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

UNiXWHoRe wrote:
If you have just an infinite loop with a NOP, your compiler will optimize it, probably putting it to sleep.

Thats an interesting thought... I cheked, the NOP is there.
My compiler is ICCAVR V7.13A

DFR

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

I thought I would update this thread in case someone else trips over this one and could use some help.

Ultimately, the solution to my problem turned out to be related to the OCDEN flag. I found that it was not check-marked in the fuse settings.

I think what was happening was that since this fuse was not enabled the J TAG debugging support was not fully supported or reliable, hence getting spurious Sleep mode messages.

HTH
DFR

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

I'm getting the same thing.

AVR Dragon: IDR event 0x00.
AVR Dragon: Target has entered sleep mode.
AVR Dragon: Target has left sleep mode.
.
.
.

But for some reason the OCDEN fuse bit will not stay set.
I program the fuse bits then enter debug mode and I still see the same error. So I go back and check the fuse bits and OCDEN has been cleared. :(

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

Thats unfortunate. Perhaps you should elevate this issue up to Atmel's technical support service?

I'm not familiar with the Dragon platform. Does it support ISP as well as JTAG? if so, try using the ISP instead.

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

After you check the OCDEN box and press program do you verify the fuse settings by reading them back again right away?

In my situation I couldn't get the OCDEN fuse to stick either, until I realized that AVRSudio 4's settings had somehow changed and was set to ISP mode! Once that was corrected Fuse peogrammng via JTAG was reliable and the issue dissapeared for me.

DFR

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

The fuses would verify correctly and will stay set even if I cycle power except when I go into Debug mode.

Program mode is set to JTAG (I don't actually have the ISP wires even connected). The JTAG programming seems to work fine it's just when I try to use JTAG to Debug.

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

OCDEN fuse should be automatically enabled/disabled when you are JTAG debugging. No reason to manually enable it: http://www.mail-archive.com/avr-...

Is there any circuitry connected to the JTAG pins that may be affecting them? Some nearby noise source?

Do you have another jtag debugger or platform you can test to verify that your MK2 is ok?

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

thmjpr wrote:
OCDEN fuse should be automatically enabled/disabled when you are JTAG debugging. No reason to manually enable it: http://www.mail-archive.com/avr-...

Is there any circuitry connected to the JTAG pins that may be affecting them? Some nearby noise source?

Do you have another jtag debugger or platform you can test to verify that your MK2 is ok?


When I leave Debugging OCDEN is disabled and I've never seen a debugger disable OCDEN after leaving debug mode if OCDEN was already set previously.

I don't have anything else hooked up to the JTAG pins. I'am using the prototype area on the Dragon. This setup was working fine for awhile. It was laying in a corner for a month or two and when I came back to it this problem started up.

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

Make sure your programmer is supplying a strong 5v to the target for the fuses... This happened many times to me in the past where the programmer only supplied about 4.5v to the target and fuses wouldn't program properly...

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

Checking the supply voltage(s) is all always a good idea as one cannot expect a part to operate correctly when out of spec. in fact, it should be one of the first things to check.

The key to successful engineering (professional or otherwise) is the development of good habits. IMHO

DFR

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

Last Week I started to see the same thing: OCDEN Flag not sticking, being cleared when entering/leaving devug mode.

I asked for technical support at www.atmel.com

I finally got around the issue by upgrading to the latest version of AVRStudio 4.16 Build 638 (AKA SP1). I also forced a firmware upgrade to my JTAGICE MKII.

The OCDEN fuse still clears upon entering/leaving debvug mode but debugging works correctly now. Atmel confirms that the OCDEN fuse is automatically controlled/ Which is weird in that I don't remember seeing OCDEN clearing before.

Hope this helps.