cool hardware debugger for classic tiny over debugWire, interesting

[apws]

hi, just today I found this cool thing for debugWire parts... would be nice to have it also for UPDI ;-)

https://hinterm-ziel.de/index.php/2021/12/31/dw-link-a-new-hardware-debugger-for-attinys-and-small-atmegas/
(series here)

https://www.codeproject.com/Articles/5321801/Debugging-an-Arduino-project-with-GDB-on-Classic-A?msg=5856462#xx5856462xx
(bigger article)

[felias-fogg]

I agree!

I will need some time to recover before I look into this, though. It seems that UPDI is not as secret as debugWIRE. However, Microchip relies apparently on translating UPDI to EDBG, which then can be interfaced to GDB RSP using, e.g., pyAVRdbg. Here is an almost successful attempt to integrate it into PlatformIO: https://community.platformio.org/t/debug-an-avr-4809-with-microupdi/19926

[felias-fogg]

OK, it is strange to talk to yourself. But just as a note: pymcuprog, which is the low level interface used by pyAVRdbg and is officially provided by Microchip, contains also a UPDI/serial interface. So it is just a matter of reading and understanding the two Python scripts to build a UPDI debugger.

[apws]

Hello Bernhard, thanks for the link, I am not experienced C/C++ programmer unfortunately (to hlep with this), now learning all the quirks of pointers syntax, never needed this low level language for anything, I like java and its fact that pointers dangers are difficult for me, although MANY years ago, I started in 6502 macroassembler and wrote also 8080 emulator in Atmas-II on Atari (1987, yeah). Now I want to correctly port some arduino sketch which works well on 8bit AVR chips but fails on 32bit ARM mostly (curious that Sony Spresense arduino builds and runs this well... though), so I need some debug support or some ways how to isolate issues, so I also read whole your series about Debugging 1-4 on your blog to refresh in mind all the quirks possible, and fact is, some combination of console output (but sketch depends on serial terminal heavily, so not so easy with single UART approach) and unit TESTS (as you have in dw-link sketch) together with Arduino Zero board (+IDE20rc debugger) MAY help... I in fact started with refactoring the sketch code by spliting it into many includes of related functional blocks and renaming C-style identifiers to more verbose java-like and primarily adding Ptr suffix to anything used as pointer .... ya, its very basic and begginers approach, but I desperately need mostly the READABLE source to understand what all where happens ... strange thing is, the sketch tries to be as efficient as possible and uses lots of globals and one single loop full of labels and goto ))))

... so, I am not heplful in UPDI debugging support )), only see that for example existing microchip Atmep328p-XPlain Mini board has some debugWire support for AtmelStudio too (its probably similar case as in your link ??) - while my investigated code fails on 32bit, I suspect some types/pointers/alignment bad behavior (code tries to handle it to some extent but has probably some quirks) I am now beting on Arduino Zero to seamlessly debug arduino code in 32bit world

for the 8bit Atmel328p-XPLAIN Mini I recently found this:
https://www.youtube.com/watch?v=bv7jnuv9q5k

It was huge task to support proprietary and secret debugWire and you did enormous thing with it. Its question of motivation to do this for UPDI too, probably - I tried to find EXISTING ways to debug, you are finding the way how to do it very cheap and available, so thanks for all effort :-) And yes, here in megaTinyCore/DxCore UPDI support Spence uses programming features to upload sketches already at least, thanks for all the investigated things, it lives on my breadboards too :-))

So, still learning and trying to understand also GDB world in Arduino20 IDE ... (I didnt tried platformio yet, afraid of bloated vscode node thing), plain vscode+arduino extension now works for me for quite drastic refactorings at least...

[felias-fogg]

Hi, I recommend the book "Debugging: The 9 Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems" by David J. Agans. It is fun to read and teaches you to approach a debugging problem in a systematic way (although I do not 100% agree with all of it).

Concerning your problem: Did you convert all your integer types to the "fixed width integer" such as uint8_t, int16_t, etc. before porting? This probably helps somewhat.

[felias-fogg]

The Atmel328P-EXPLAINED mini looks cool. But you are tied to Microchip Studio or MPLAB X (and I dislike both very deeply). And no debugging of Tinys, of course.

[apws]

thanks for suggestions, yeah, I even typedef-ed my own types for 8b 16b signed and unsigned, with he types you noted and refactored code to use them (more readable and defined at one place to play with - but this was ok) - ... I already found where is problem with few debug writes to console - bad behavior of (Hardware)Serial on tiny Infineon XMC2Go board, no big deal, experiences... tnx

[SpenceKonde]

I suspect reverse engineering the D of UPDI would be considerably easier, The KEY to enable it has been published - though they later pulled it from the datasheets :-P

It almost certainly builds on the UPDI programming protocol, my guess would be that it just grants access to a few registers and an instruction or two for single stepping... but with the PHY layer publicly documented, and the way commands are sent and received understood, I think it would be just filling in a few blanks to know what UPDI requires to be sent for debugging, then the drudgery of connecting that to a debugging tool.....

[felias-fogg]

Yes, and apparently it must be in he Python scripts they have published. Are you saying that there had been documents that documented the D-part more extensively? Are there copies somewhere in the dark edges of the web? ;-)

[hmeijdam]

Here is an older datasheet https://nl.mouser.com/datasheet/2/268/50002687A-1316569.pdf

chapter 30, however I am not sure yet if it offers more than the newer datasheet.

[felias-fogg]

Thanks! But no, same stuff as in the current data sheets.

[SpenceKonde]

I'm sure there are. It was in like, the old versions of the tinyAVR 0/1-series datasheets, the same round that was missing some of the pin mapping options and shit like that. I don't seem to have a copy handy though...

[apws]

is not something here?
https://ww1.microchip.com/downloads/en/DeviceDoc/50002630A.pdf

https://www.avrfreaks.net/forum/solved-standalone-medbg-updi-programmer-and-issues-avrdude

[felias-fogg]

No, thanks. I know both. They must have hidden the stuff somewhere.

[SpenceKonde]

Requested exporting of elvis and tools submenu to select from -Os, -O3 and -Og have been added to ATTinyCore.

[felias-fogg]

Thanks! That helps tremendously. Now I only have to convince Arduino to do that as well.

[per1234]

There is now a built in system to switch between compilation for debugging applications and compilation for "release" applications:

https://arduino.github.io/arduino-cli/latest/platform-specification/#sketch-debugging-configuration

You can see an example of it being used here:

https://github.com/arduino/ArduinoCore-samd/blob/1.8.12/platform.txt#L34-L38

(Compile with -Og -g3 when in "optimize for debugging" mode and -Os when in "release" mode.)

This is controlled via the Sketch > Optimize For Debugging menu item in Arduino IDE 2.x or the --optimize-for-debug flag of arduino-cli compile.

I suspect it won't be added to Arduino IDE 1.x, since most users would not have a need for such a thing due to the lack of an integrated debugger in that application.

---

Arduino IDE 2.x saves the .elf to the build subfolder of the sketch when you do a Sketch > Export Compiled Binary.

arduino-cli compile does the same when you use the --export-binaries flag, or you can use --output-dir flag if you want it saved to some custom location.

Both the IDE 2.x and Arduino CLI can be configured to always export binaries via the sketch.always_export_binaries configuration key:
https://arduino.github.io/arduino-cli/latest/configuration/

[hmeijdam]

I notice a linker error with the Arduino-IDE built-in "Serial event" example sketch.
When I compile with "-Os" or "-Og" flag everything works fine.

When I compile with the "-O3" flag it throws a linker error

Arduino: 1.8.13 (Windows 10), Board: "ATtiny85/45/25 (No Bootloader), -O3 (speed), ATtiny85, 8 MHz (internal), EEPROM retained, RX on PB1, TX on PB (default PB0), B.O.D. Disabled (saves power), Disabled (saves flash)"



E:\Arduino\arduino-1.8.13-attinycore\arduino-builder -dump-prefs -logger=machine -hardware E:\Arduino\arduino-1.8.13-attinycore\hardware -hardware E:\Arduino\arduino-1.8.13-attinycore\portable\sketchbook\hardware -tools E:\Arduino\arduino-1.8.13-attinycore\tools-builder -tools E:\Arduino\arduino-1.8.13-attinycore\hardware\tools\avr -built-in-libraries E:\Arduino\arduino-1.8.13-attinycore\libraries -libraries E:\Arduino\arduino-1.8.13-attinycore\portable\sketchbook\libraries -fqbn=ATTinyCore:avr:attinyx5:optimization=othree,chip=85,clock=internal_8m,eesave=aenable,softserial=enable,bod=disable,millis=disabled -ide-version=10813 -build-path C:\Users\Hans\AppData\Local\Temp\arduino_build_323162 -warnings=none -build-cache C:\Users\Hans\AppData\Local\Temp\arduino_cache_357362 -prefs=build.warn_data_percentage=75 -verbose E:\Arduino\arduino-1.8.13-attinycore\examples\04.Communication\SerialEvent\SerialEvent.ino

E:\Arduino\arduino-1.8.13-attinycore\arduino-builder -compile -logger=machine -hardware E:\Arduino\arduino-1.8.13-attinycore\hardware -hardware E:\Arduino\arduino-1.8.13-attinycore\portable\sketchbook\hardware -tools E:\Arduino\arduino-1.8.13-attinycore\tools-builder -tools E:\Arduino\arduino-1.8.13-attinycore\hardware\tools\avr -built-in-libraries E:\Arduino\arduino-1.8.13-attinycore\libraries -libraries E:\Arduino\arduino-1.8.13-attinycore\portable\sketchbook\libraries -fqbn=ATTinyCore:avr:attinyx5:optimization=othree,chip=85,clock=internal_8m,eesave=aenable,softserial=enable,bod=disable,millis=disabled -ide-version=10813 -build-path C:\Users\Hans\AppData\Local\Temp\arduino_build_323162 -warnings=none -build-cache C:\Users\Hans\AppData\Local\Temp\arduino_cache_357362 -prefs=build.warn_data_percentage=75 -verbose E:\Arduino\arduino-1.8.13-attinycore\examples\04.Communication\SerialEvent\SerialEvent.ino

Using board 'attinyx5' from platform in folder: E:\Arduino\arduino-1.8.13-attinycore\portable\sketchbook\hardware\ATTinyCore\avr

Using core 'tiny' from platform in folder: E:\Arduino\arduino-1.8.13-attinycore\portable\sketchbook\hardware\ATTinyCore\avr

Detecting libraries used...

"E:\\Arduino\\arduino-1.8.13-attinycore\\hardware\\tools\\avr/bin/avr-g++" -c -g -O3 -Wall -std=gnu++17 -fpermissive -Wno-sized-deallocation -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -Wno-error=narrowing -flto -mrelax -w -x c++ -E -CC -mmcu=attiny85 -DF_CPU=8000000L -DCLOCK_SOURCE=0 -DDISABLEMILLIS -DARDUINO=10813 -DARDUINO=10813 -DARDUINO_AVR_ATTINYX5 -DARDUINO_ARCH_AVR "-DATTINYCORE=\"2.0.0-dev\"" -DATTINYCORE_MAJOR=2UL -DATTINYCORE_MINOR=0UL -DATTINYCORE_PATCH=0UL -DATTINYCORE_RELEASED=0 "-IE:\\Arduino\\arduino-1.8.13-attinycore\\portable\\sketchbook\\hardware\\ATTinyCore\\avr\\cores\\tiny" "-IE:\\Arduino\\arduino-1.8.13-attinycore\\portable\\sketchbook\\hardware\\ATTinyCore\\avr\\variants\\tinyx5" "C:\\Users\\Hans\\AppData\\Local\\Temp\\arduino_build_323162\\sketch\\SerialEvent.ino.cpp" -o nul -DARDUINO_LIB_DISCOVERY_PHASE

Generating function prototypes...

"E:\\Arduino\\arduino-1.8.13-attinycore\\hardware\\tools\\avr/bin/avr-g++" -c -g -O3 -Wall -std=gnu++17 -fpermissive -Wno-sized-deallocation -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -Wno-error=narrowing -flto -mrelax -w -x c++ -E -CC -mmcu=attiny85 -DF_CPU=8000000L -DCLOCK_SOURCE=0 -DDISABLEMILLIS -DARDUINO=10813 -DARDUINO=10813 -DARDUINO_AVR_ATTINYX5 -DARDUINO_ARCH_AVR "-DATTINYCORE=\"2.0.0-dev\"" -DATTINYCORE_MAJOR=2UL -DATTINYCORE_MINOR=0UL -DATTINYCORE_PATCH=0UL -DATTINYCORE_RELEASED=0 "-IE:\\Arduino\\arduino-1.8.13-attinycore\\portable\\sketchbook\\hardware\\ATTinyCore\\avr\\cores\\tiny" "-IE:\\Arduino\\arduino-1.8.13-attinycore\\portable\\sketchbook\\hardware\\ATTinyCore\\avr\\variants\\tinyx5" "C:\\Users\\Hans\\AppData\\Local\\Temp\\arduino_build_323162\\sketch\\SerialEvent.ino.cpp" -o "C:\\Users\\Hans\\AppData\\Local\\Temp\\arduino_build_323162\\preproc\\ctags_target_for_gcc_minus_e.cpp" -DARDUINO_LIB_DISCOVERY_PHASE

"E:\\Arduino\\arduino-1.8.13-attinycore\\tools-builder\\ctags\\5.8-arduino11/ctags" -u --language-force=c++ -f - --c++-kinds=svpf --fields=KSTtzns --line-directives "C:\\Users\\Hans\\AppData\\Local\\Temp\\arduino_build_323162\\preproc\\ctags_target_for_gcc_minus_e.cpp"

Compiling sketch...

"E:\\Arduino\\arduino-1.8.13-attinycore\\hardware\\tools\\avr/bin/avr-g++" -c -g -O3 -Wall -std=gnu++17 -fpermissive -Wno-sized-deallocation -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -Wno-error=narrowing -MMD -flto -mrelax -mmcu=attiny85 -DF_CPU=8000000L -DCLOCK_SOURCE=0 -DDISABLEMILLIS -DARDUINO=10813 -DARDUINO=10813 -DARDUINO_AVR_ATTINYX5 -DARDUINO_ARCH_AVR "-DATTINYCORE=\"2.0.0-dev\"" -DATTINYCORE_MAJOR=2UL -DATTINYCORE_MINOR=0UL -DATTINYCORE_PATCH=0UL -DATTINYCORE_RELEASED=0 "-IE:\\Arduino\\arduino-1.8.13-attinycore\\portable\\sketchbook\\hardware\\ATTinyCore\\avr\\cores\\tiny" "-IE:\\Arduino\\arduino-1.8.13-attinycore\\portable\\sketchbook\\hardware\\ATTinyCore\\avr\\variants\\tinyx5" "C:\\Users\\Hans\\AppData\\Local\\Temp\\arduino_build_323162\\sketch\\SerialEvent.ino.cpp" -o "C:\\Users\\Hans\\AppData\\Local\\Temp\\arduino_build_323162\\sketch\\SerialEvent.ino.cpp.o"

Compiling libraries...

Compiling core...

Using precompiled core: C:\Users\Hans\AppData\Local\Temp\arduino_cache_357362\core\core_3d0b13c86fdad0adf47ea62b7fa335a6.a

Linking everything together...

"E:\\Arduino\\arduino-1.8.13-attinycore\\hardware\\tools\\avr/bin/avr-gcc" -Wall -Os -g -flto -fuse-linker-plugin -Wl,--gc-sections -mrelax -mmcu=attiny85 -o "C:\\Users\\Hans\\AppData\\Local\\Temp\\arduino_build_323162/SerialEvent.ino.elf" "C:\\Users\\Hans\\AppData\\Local\\Temp\\arduino_build_323162\\sketch\\SerialEvent.ino.cpp.o" "C:\\Users\\Hans\\AppData\\Local\\Temp\\arduino_build_323162/..\\arduino_cache_357362\\core\\core_3d0b13c86fdad0adf47ea62b7fa335a6.a" "-LC:\\Users\\Hans\\AppData\\Local\\Temp\\arduino_build_323162" -lm

C:\Users\Hans\AppData\Local\Temp\cc6ag8Y4.s: Assembler messages:

C:\Users\Hans\AppData\Local\Temp\cc6ag8Y4.s:309: Error: symbol `_txstart' is already defined

C:\Users\Hans\AppData\Local\Temp\cc6ag8Y4.s:312: Error: symbol `_txpart2' is already defined

C:\Users\Hans\AppData\Local\Temp\cc6ag8Y4.s:314: Error: symbol `_txdelay' is already defined

C:\Users\Hans\AppData\Local\Temp\cc6ag8Y4.s:793: Error: symbol `_txstart' is already defined

C:\Users\Hans\AppData\Local\Temp\cc6ag8Y4.s:796: Error: symbol `_txpart2' is already defined

C:\Users\Hans\AppData\Local\Temp\cc6ag8Y4.s:798: Error: symbol `_txdelay' is already defined

C:\Users\Hans\AppData\Local\Temp\cc6ag8Y4.s:865: Error: symbol `_txstart' is already defined

C:\Users\Hans\AppData\Local\Temp\cc6ag8Y4.s:868: Error: symbol `_txpart2' is already defined

C:\Users\Hans\AppData\Local\Temp\cc6ag8Y4.s:870: Error: symbol `_txdelay' is already defined

C:\Users\Hans\AppData\Local\Temp\cc6ag8Y4.s:918: Error: symbol `_txstart' is already defined

C:\Users\Hans\AppData\Local\Temp\cc6ag8Y4.s:921: Error: symbol `_txpart2' is already defined

C:\Users\Hans\AppData\Local\Temp\cc6ag8Y4.s:923: Error: symbol `_txdelay' is already defined

lto-wrapper.exe: fatal error: E:\Arduino\arduino-1.8.13-attinycore\hardware\tools\avr/bin/avr-gcc returned 1 exit status

compilation terminated.

e:/arduino/arduino-1.8.13-attinycore/hardware/tools/avr/bin/../lib/gcc/avr/7.3.0/../../../../avr/bin/ld.exe: error: lto-wrapper failed

collect2.exe: error: ld returned 1 exit status

exit status 1

Error compiling for board ATtiny85/45/25 (No Bootloader).

[SpenceKonde]

I suspect the compiler is doing something moronic to the the inline assembly. (not suspect, really, that is absolutely without a doubt what it's doing - my guess is it's unrolling a loop with a big block of inline assembly in it, which is then failing to link because after it duplicates the code many times over, there are now many copies of assembly and hence many copies of the labels.

Arguably that's a compiler bug....

In any event, thanks for reminding me to remove serial event to match my other cores (I don't know to what extent we ever even HAD Serial Event on ATTinyCore, I'll have to check. But I pounded a stake into it's heart on DxCore and megaTinyCore and nobody even noticed. So out it goes. It was a horrible idea and a godawful misfeature.
Interesting that those features are coming in 2.0 of the IDE, though thy matter far more to others here than me. I have only once wanted to have hardware debugging, and that was while tracking down #475. But what I really want for that is to know WHY creating a local variable and then writing it to a volatikle register prevents that bug, when the whole rest of setup is writing values to volatile registers right and left and doesn't (it's clearly related to the management of the stack, because I can now look at the assembly listings, and see a sequence of 5 instructions that tell me that the problem won't occur, and 2 of those are the loading of the stack pointer into R28 and R29. And I don't think all the hardware debugging in the world would tell me why the compiler is making the wacky choices that it iis.

[hmeijdam]

Serial Event is a Arduino Built-in Example. Not an example sketch from your core.
I am taking whatever sketch I have that compiles fine on the Master version and then look how it behaves in the V2.0.0-dev versiion.

[SpenceKonde]

Yeah, I know that. I have no plans to change the behavior of the core. SerialEvent is officially deprecated by Arduino and they haven't been including it in their new cores. I'd remove the example if that were within my power.