Incircuit-Debugging wäre ja ein schöne Sache …..
Aber warum einfach ….
Ich habe mit das Modell “ATATMEL-ICE-PCBA” hier bestellt:
For nearly 35 USD, nice price … and that is what you get:
No cable included! 100mil Header!
*** ATMEL, Disappointed! ***
Here the PDF Userguide.
There are some (Erfahrungsbericht) additional sites and blogs, experiencing the same mess.
- The PC immediately recognises the ICE and can read the arduino’s avr settings on the "Tools/Device Programming" via ISP.
Then i tried to start a debug session: "You cannot debug via ISP. Only the device is programmed. Use debugWIRE for debugging …".
Ok. Program only … program running. But the arduino bootloader (enabling uploading via arduino’s USB) was gone …
Hmmh. I had seen the DWEN Fuse on the "Tools/Device Programming/Fuses" tab and enabled it.
The fuse was set immediately and i couldn’t access any of the ISP features anymore! Shock! Arduino bricked!?
On the projects settings on the "Tool" tab, there is a setting for ISP or debugWIRE. Enabled debugWIRE –
then i could upload AND debug my application – although transfer is a bit on the slow side. Yay!
-> How to get back to SPI? –> Menu “DEBUG” - “Disable debugWire and Close”
But, in sequence:
1.) manual “fabrication” of Header-Cable ( Steckverbinding 2mm 2*5pol auf 2*3pol 2,54 mm SPI use for ATmega328):
4.4.13. debugWIRE Software Breakpoints
The debugWIRE OCD is drastically scaled down when compared to the Atmel megaAVR (JTAG) OCD. This means that it does not have any program counter breakpoint comparators available to the user for debugging purposes. One such comparator does exist for purposes of run-to-cursor and single-stepping operations, but additional user breakpoints are not supported in hardware.
Instead, the debugger must make use of the AVR BREAK instruction. This instruction can be placed in FLASH, and when it is loaded for execution it will cause the AVR CPU to enter stopped mode. To support breakpoints during debugging, the debugger must insert a BREAK instruction into FLASH at the point at which the users requests a breakpoint. The original instruction must be cached for later replacement.
When single stepping over a BREAK instruction, the debugger has to execute the original cached instruction in order to preserve program behavior.
In extreme cases, the BREAK has to be removed from FLASH and replaced later.
All these scenarios can cause apparent delays when single stepping from breakpoints, which will be exacerbated when the target clock frequency is very low.
It is thus recommended to observe the following guidelines, where possible: • Always run the target at as high a frequency as possible during debugging.
The debugWIRE physical interface is clocked from the target clock.
• Try to minimize on the number of breakpoint additions and removals, as each one require a FLASH page to be replaced on the target
• Try to add or remove a small number of breakpoints at a time, to minimize the number of FLASH page write operations
• If possible, avoid placing breakpoints on double-word instructions
4.4.14. Understanding debugWIRE and the DWEN Fuse
When enabled, the debugWIRE interface takes control of the device's /RESET pin, which makes it mutually exclusive to the SPI interface, which also needs this pin. When enabling and disabling the debugWIRE module, follow one of these two approaches:
• Let Atmel Studio take care of things (recommended)
• Set and clear DWEN manually (exercise caution, advanced users only!)
Important: When manipulating DWEN manually, it is important that the SPIEN fuse remains set to avoid having to use High-Voltage programming.
So… hardware hooked up? DebugWIRE enabled? Well hell, start debugging. AVR Studio will find all your source code files and give you all the magic you need to single-step and breakpoint operate your Arduino. You’ll find your code has some extras in it you didn’t write, since that’s the nature of the preprocessor that Processing uses to get the code to compile by GCC, but that’s a story for another time.
Arduino: That’s a lot of words to say "remove a capacitor and it works." from Reset-Line!
Using in my case Arduino-Nano, remove disturbing C4 (100nF / 0603 ) :
Arduino-Nano: Solder out C4 for Reset-Line for debugWire-use!
Because of error message:
“Failed to enter programming mode. ispEnterProgMode: Error status received: Got 0xc0, expected 0x00 (Command has failed to execute on the tool)
Unable to enter programming mode. Verify device selection, interface settings, target power, security bit, and connections to the target device.”
Two choices on “Tools/Device Programming”:
Fuses fror Arduino NANO:
If BootRST-fuse is set –> Reset will start at location which is set by BOOTSZ-Fuse! Not at 0x0000 – address!
Don’t touch DWEN!
Next Step “Start with debugging” fails because DWEN isn’t set yet:
Ok, switch Nano off and on again!
And voilá (C-Highlevel & Assembler-Debugging) is available:
And how to return to SPI-progamability:
Press not “Stop Debugging” but on Menu during debug-mode:
“Debug.Disable debugWire and Close” does the trick: That is the unique location to do this!
I used demo-nonsense-code and didn’set DDRB for PortB, and set it manually afterwards in the PortIO-Window.
Knowing this code will start at begin of flash address-space, i diabled BOOTRST-Fuse and not let point reset-vector to 0x3C00h.
Going onwards ….