The title of this thread concerns the implementation of a single-step (S/S) scheme, not the development of a full-fledged debugger. If single-stepping can be implemented successfully, then a debugger should also be feasible, subject to resolving the remaining technical challenges and unforeseen implementation issues.
Does the single-step (S/S) scheme proposed in this thread contribute to Flash memory wear?
I guess it depends on how many times you have to recompile your sketch but the important think is it doesn't address even the most basic characteristics of a debugger. Maybe there isn't even room for this additional program that you will have to include along with your sketch.
What happens to all the peripherals that are running in your sketch while your interrupt service routine is busy examining values on the stack, reading data memory address, etc.?
I think the major shortcoming in your proposal is that you have to append a separate program to your sketch because there is no way to add external program and data space to your UNO R3 to accommodate all the debug functions and that you have to use project resources like I/O to implement a keypad and a display.
This is an interesting observation that I had not considered before. However, implementing such an approach would likely require a multicore processor with a multitasking operating system, such as the one used on the UNO Q, which is beyond my current level of expertise.
My intention is just to see if @westfw' approach could be implemented or not. Theoretically, the proposed scheme is feasible, and in practice it may also work, just as a similar approach has worked for the 8051. Developing a commercial debugger for an ATmega328P trainer is therefore not in plan as such a trainer is unlikely to be widely used by learners because the Arduino UNO R3 and the Arduino IDE are already readily available.
Upon further reading of the ATmega328P Xplained Mini manual it looks like it uses the debugWIRE protocol described in the 328P data sheet so it sets and removes breakpoints during debugging and will eventually wear out the onboard 328p. Their is also a 32U4 on the board that serves as a USB interface, programmer, and runs the debug program mEBDG so it's basically an UNO R3 and if the mEBDG firmware source is available you could make your own. It works in league with Atmel Studio and possibly other packages.
I don't believe it is. The binaries are bundled with Atmel Studio:
Do I understand correctly that one could recreate one then with an UNO?
I was thinking that Microchip made an in circuit debugger with a bonded out 328P like we had for the PIC processors but it looks like I was wrong.
That looks interesting. I was thinking that one could closely mimic the ATmega328P Xplained Mini that contains an onboard 328P if you based it on a through hole UNO and could replace the 328 if you ever managed to wear out the flash.
You would have to remove the resonator from the 328 and clock it externally with the 32U4 clock. There would have to be some changes to the circuitry surrounding the RESET pin as well.
Just a thought. You can buy the real thing for $16 from Digikey so it's probably not worth the effort.
I think it ends up being the case that you can theoretically implement "single stepping" in some sort of monitor program, but it turns out that this isn't very useful in creating a debug environment, because:
- it'd stop working if you ever turn off interrupts.
- It's not clear how it would work if you USE interrupts (not including the one reserved for implementing the single-step function.)
- You really don't want to single step your entire application (at some fraction of normal speed.) You want to set a breakpoint at some relevant place, and then single step over just the bit of code that you're interested in. There's no way to do the first part on the AVR (the "break" instruction only works when an external debugger is used.)
- (I suppose you could have "startSS" and "endSS" macros that get inserted into the source to mark areas that you want to debug... not great.)
Setting breakpoint will again contribute to flash wear. So, the aim is simple: single step few ASM instructions of the program and display the register/RAM contents after the execution of every instruction. It will also serve as an exercise of 'how to implement S/S in AVR?
In Arduino IDE, I set brearkpoint using while(true), and it works as a debugger for me with the help of Serial.print().
Serial.print() always helps. I don't use while(true) to stop execution but I do print variables when they change (plus the function name where that variable was printed). 3rd party terminal programs usually make it easier to copy/save for inspection afterwards.