"JTAGICE mkII IDR event 0xff" error

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

Commonly when trying to debug the atmega32 with the Jtag ice AVR studio outputs the error "JTAGICE mkII IDR event 0xff" continously to the message window while also going in and out of sleep mode. This continues until I pause the simulation which then brings me to the disassembler which states "Data of unknown opcode."

Am i doing something wrong or is this a common error?

Whenever this occurs i have to stop and restart my debugging session, it happens far to frequently to even try to debug the code.

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

I seem to remember this could happen if the JTAG comm is clocked too fast. Check the target clock frequency in the options dialog once you've connected with the JTAGICE mkII and see if this could be the cause.

Hope this helps,
Tore

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

You might also check your power. I had the same problem, " JTAG entering sleep mode" followed by a series of "IDR event 0xff". I added more filtering capacitors to the power lines. Noise on VCC was causing the problem.

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

:oops: apparently the Jtag uses several of the pins on port C, the same port i was using to power an lcd :oops:

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

I am having the same problem with AT90CAN128. The funny thing is I had it running just a couple of days ago with zero problems, the code has NOT changed, and yet I am now having the same issue stated above. I checked the power its fine. Can this problem be related to fuse setup?

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

Quote:
Can this problem be related to fuse setup?

I did have simular problems with the fuse bits another time...I had to use parallel high voltage prog. to get the chip into the "proper settings." It was with the mega32.

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

I'm having similar problems on the mega128... on 2 totally different projects (hardware) - only common to them is that CK = 7.3728MHz. The JTAG port is entirely dedicated - nothing else on the JTAG pins. VCC is fine. JTAG clock is set correctly. Fuse bits look fine too. Weird thing is that its fine sometimes, then suddenly it all goes pear shaped. ???

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

Unfortunately I just saw the same error on a Dragon connected to a Butterfly, after about an hour of debugging.

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

Hi.

I have runned into this problem from time to time but a restart have always solved the problem so I have not bothered very much about it. But today, this problem was permanent and I could not get rid of it in anyway. I have moved my tools to another desk using a maximum long USB cable, a secondary screen and so on so the situation have shanged slightly. So, I deceded that I had to solve this once and for all. A search here just told me that no one had any solution.

Finally I found that the reason, just a broken soldering on the JTAG connector... just as simple as that. So, if you get this error, you can be sure that it is some sort of communication problem. But it is easy to start hunting gosts like USB cables, JTAG speed connections and so on. Nothing of that did any difference AFTER I fixed the soldering.

My favorites:
1. My oscilloscope, Yokogawa DLM2024.
2. My soldering iron, Weller WD2M, WMRP+WMRT.
3. JTAGICE3 debugger.

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

I'm having this problem today with an ATmega164P and Dragon on JTAG. Same as greggallagher, 7.3728MHz. If I change the fuses to run off internal RC, all is fine. At least initially.

Am tempting fate in publicly stating what seemed to fix it.

Thought maybe the new ribbon cable I made for JTAG was questionable and removed my old trusty cable from a JTAG ICE-Cube. Worse! We're getting somewhere. New cable was 11", old was 12". Made a 6" cable and it has been running correctly the past 10 minutes! A new record!

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

The shorter cable was better, but not problem free.

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

Reading the ADC with devices that share the ADC inputs with the jtag causes this error
Dig

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

JTAG is on PORTC for 164P, A/D is on PORTA. So its not a conflict with A/D. Is not something that happens repeatedly at a particular line of code or anything.

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

I did have the same problem. I did have my atmega164P on internal 8MHz and changed it to external crystal 4MHz and I did get this strange problem. But the problem was the JTAG connection target clock frequency. When i did change it to 500Khz instead of 1MHz(default) it did work.

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

Same problem ....

Atmega 32, clock 8 mhz ,5 v

Solved

Avcc pin 30 connect to VCC 10 with
Gnd pin 11 connect Gnd pin 31 with

capacitor 0.1 between avcc,vcc & gnd gnd

Bye

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

Same problem...too
A)fuse setting to internal oscillator 8 MHz
and everything is fine

B)fuse setting to use external crystal 16 Mhz
everything drops dead!!!

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

kakarot wrote:
Same problem...too
A)fuse setting to internal oscillator 8 MHz
and everything is fine

B)fuse setting to use external crystal 16 Mhz
everything drops dead!!!

Did you find the solution for that?

Thanks

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

iharush wrote:
kakarot wrote:
Same problem...too
A)fuse setting to internal oscillator 8 MHz
and everything is fine

B)fuse setting to use external crystal 16 Mhz
everything drops dead!!!

Did you find the solution for that?

Thanks

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

Spurious IDR events have usually been traced to faulty wiring or incorrect clock selections.