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?
Hallo, manchmal kommt noch die Fehlermeldung: "Target has entered sleepmode". Sehr eigenartig!
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
1 | // Deaktiviert den Watchdogtimer. Dies muss beim 2561 bei jedem Systemstart geschehen.
|
2 | wdt_reset(); |
3 | MCUSR = 0; |
4 | wdt_disable(); |
5 | |
6 | |
7 | // Erlauben von OnChip Debugging auf dem ATMEGA 2561:
|
8 | // Timed Sequence. Innerhalb 4 Taktzyklen zweimal das BIT löschen:
|
9 | MCUCR &= ~(1 << JTD); |
10 | MCUCR &= ~(1 << JTD); |
11 | |
12 | // Das JTAG Reset Flag löschen (kann wohl entfallen)
|
13 | MCUCR &= ~(1 << JTRF); |
14 | 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
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.