Probleme mit JTAG: Flash OK, aber kein Debugging.

[Bernhard N. (bernieserver)]

Hallo,

mein Mikrocontroller, ein ATMEGA 2561, verhält sich etwas seltsam.
Ich habe einen AVR JTAG MK2, der bisher auch immer funktionierte, 
zumindest an einem ATMEGA32 und einem anderen ATMEGA 2561.

Das Problem ist, dass ich nicht auf dem Chip debuggen kann. Ich kann das 
Programm draufladen und starten, jedoch nicht mehr über Pause bzw. 
Haltepunkte stoppen.
Das Verrückte dabei ist: Ich habe zwei identische Platinen mit dem 
ATMEGA2561. Beim einen geht JTAG, beim anderen nicht. Das Programm 
darauf ist identisch!.

Folgende Fuses sind beim Problemkind gesetzt, beim anderem weiß ich es 
nicht mehr so genau, komme da nicht direkt dran..

BODLevel 4,3V
OCDEN ob ein oder aus, bewirkt keinen Unterschied
JTAGEN ein
SPIEN ein
WDTON aus
EESAVE aus
BOOTRST aus
CKDIV8 aus
CKOUT aus
SUT_CKSEL 8Mhz+, Verzögerung 0ms. Bei 63ms ist aber das Gleiche



Was kann das also sein?

[Bernhard N. (bernieserver)]

Hallo,

manchmal kommt noch die Fehlermeldung:
"Target has entered sleepmode".

Sehr eigenartig!

[Bernhard N. (bernieserver)]

So ich habe es hinbekommen.


Ich musste in den Optionen die Zieltaktfrequenz reduzieren. Ich habe 
obwohl ich 16Mhz habe dort 1Mhz eingeben. Außerdem habe ich die 
Brownoutdetection etwas runtergesetzt und folgende Fuses gesetzt:

JTAGEN an
ISPEN an

Rest aus.
Brownout: 2,7V Limit, denke es geht aber auch 4,2.
Clock: 8Mhz+  und 63ms Startzeit

Hinweis: Beim 2561 ist auch der Watchdog ein Problem:
Daher muss man direkt beim Start folgenden Code einsetzen, falls 
Watchdogs zum Neustarten des Controllers genutzt werden

// Deaktiviert den Watchdogtimer. Dies muss beim 2561 bei jedem Systemstart geschehen.
wdt_reset();
MCUSR = 0;
wdt_disable();

  
// Erlauben von OnChip Debugging auf dem ATMEGA 2561:
// Timed Sequence. Innerhalb 4 Taktzyklen zweimal das BIT löschen:
MCUCR &= ~(1 << JTD);
MCUCR &= ~(1 << JTD);

// Das JTAG Reset Flag löschen (kann wohl entfallen)
MCUCR &= ~(1 << JTRF);
MCUCR &= ~(1 << JTRF);

Außerdem habe ich noch mehr Infos zum Fehler in einem chinesischem Forum 
gefunden:






=============================================================


IDR event 0xff (das gleiche wie "Target entered Sleepm Mode"

while doing debugging using the JTAGICE mkII or the AVR Dragon I get the 
error message: "IDR event 0xff". What is the reason for this error 
message?
Answer
There can be many reasons why you are seeing the "IDR event 0xff" error 
massage. The most common cause of spuriour IDR events is when the AVR 
target power is lost, restored, or an external reset is applied and when 
your AVR debugging tool is losing synchronisation with the AVR chip. 
Below you can find a list containing more specific examples:

You are clocking the JTAG interface faster than 1/4 of the target AVR 
system clock frequency. Programming will work, but the part runs away 
and garbage is produced in the OCDR register as the debugging tool polls 
it for status.
Make sure to set the correct target frequency in the debug settings of 
AVR Studio: Start the debug session and from the 'Debug' menu select the 
Options Window for your debugging tool. Then change the target frequency 
to the correct value. Make sure to take into consideration the system 
clock prescaler settings in your AVR, also with respect to the CKDIV8 
fuse setting.


You have changed the settings in the system clock prescaler register 
(CLKPR) in your code during debugging, causing your debugging tool to 
loose synchronisation with the AVR chip.
If you break the execution when your debugging tool loses 
synchronisation, the assembly view will probably pops up, because AVR 
Studio is unable to find the corresponding C-code. (Provided the program 
is written in C).


An error in the program makes the execution jump out of the "real 
program". This could be caused by at least two different things: 1) An 
interrupt being enabled that has no corresponding code to handle the 
interrupt request. This would cause the code to jump to a location where 
there other code or data is stored, disrupting program execution. 2) The 
return stack configuration is too small, causing the return stack to 
grow into an area populated by variables. In this case, the return 
address of a function can be overwritten by a variable, causing the 
return from a function to end up anywhere in program space. The effect 
will be much the same as in the former case.
The return stack problem can be fixed by simply increasing the return 
stack configuration in the compiler. If the problem disappears doing 
this, make sure to read the compiler documenation to understand how to 
calculate sufficient return stack size.

One way to check if the interrupts are the problem is to fill the 
interrupt vector table with "reti" instructions. Be warned though, that 
this will only hide the symptoms, not fix the problem. If this fixes the 
problem, the program probably still has a serious bug that must be 
fixed.


Electrical noise or a hardware error interferes with the TCK, TDO, TMS 
or TDI signal or lower the Vcc or nRST voltage level.

The length of the ribbon cable between your debugging tool and your 
target AVR is too long.

If the JTD bit in the MCUCSR register is set in code during debugging, 
this will disable debugging resulting in the error message "IDR event 
0xff", and if the reset line is not connected to the device it will also 
disable programming.
If this does not solve the issue, please inspect your cables and 
connections to make sure that you do not have any bends in the ribbon 
cable and that connection is good.


=============================================




Gruß
Bernhard