What is the recommended development setup (with debugging)

[DaanDekoningKrekels]

Hi there,
I want to set up a good development environment that works with the Atmel-ICE and the ATmega128A (JTAG). Right now, I am using Linux with VSCodium. On cargo run, AVRDUDE programs my MCU with an Atmel-ICE.
I am trying to use the internal debugging tools from Rust-analyser and CodeLLDB, but I can't get anything to work. I also tried MPLAB X IDE with the ELF file from my Rust project, but I don't think the breakpoints I added in VSCodium are in it?
How are you guys programming and debugging AVR microcontrollers with Rust? A Windows setup is also possible for me. Most examples online are for ARM MCU's...
Thank you in advance!

[Rahix]

To be perfectly honest, I don't use a hardware debugger at all. I use "printf debugging" via serial most of the time.

There are multiple reasons:

1. Using Rust means you seldomly, if at all, have to debug memory issues. So the really nasty bugs where you can't get far without a debugger aren't really an issue. Logic bugs can be easily traced by "instrumenting" the application with a bunch of println!().
2. In a lot of applications, stopping at a breakpoint in the wrong place will throw off all timing and this can produce bad behavior that's only visible while debugging... of course with "printf debugging" can also have that issue, but you can work around that by instrumenting timing sensitive code with GPIO toggling instead.
3. As we are using LTO while compiling the Rust binaries, the code is often optimized so heavily that no debugger manages to extract much useful information. Often the variables I want to introspect just don't exist in the final binary anymore. "printf debugging" get's around that as it is optimized alongside the application code.

The only problems where I would really dig in with a debugger were compiler bugs in the past. For those I just ran sample programs in simavr and then attached to it with avr-gdb directly.

That said, I'm sure others have differing opinions, would love to hear what everyone else is doing!

[DaanDekoningKrekels]

Thank you for your answer! I have actually never used a hardware debugger before the current project, but it's part of the research I have to do for my thesis. The past few weeks, I have been using a custom panic_handler that prints the info to serial. I might try GDB for AVR again in the future.

Semihosting on ARM is fascinating, so I am going to shift my research more towards that architecture.

[Rahix]

Semihosting on ARM is fascinating, so I am going to shift my research more towards that architecture.

Yeah, the development experience on ARM is much nicer. Also Rust support for ARM is much more mature ;)

[brainstorm]

One of the biggest problems (from what I've just researched) is that many AVR boards use the partially reverse engineered debugWire protocol with other partial attempts sketched by different authors from protocol to electrical level. So unfortunately I've not seen any solid source debugging solution for VSCode that'd give the hardware debug development experience you expect in 2024... unless you want to deal with vintage boards like the AVR Dragon or the like :-S

Even modern boards like the Glasgow Interface Explorer does not (nor plans to) have support for debugWire at the time of writing.

The sim_avr + avr_gdb duo have its own limitations too as its backtraces can be a bit hard to parse but can give useful info. For instance, most programs need to be compiled with either opt-level=s or opt-level > 1, which unfortunately has the effect of having valuable debug information optimized out or elided (...) in GDB:

(gdb) bt
(...)
#5  0x00000650 in embassy_avr_as5600_encoder::panic (info=<optimized out>) at src/main.rs:43
#6  0x00003026 in core::panicking::panic_fmt (fmt=...) at src/panicking.rs:72
#7  0x0000316e in core::result::unwrap_failed (msg=..., error=...) at src/result.rs:1654
#8  0x000006f2 in core::result::Result<u16, as5600::error::Error<avr_hal_generic::i2c::Error>>::unwrap<u16, as5600::error::Error<avr_hal_generic::i2c::Error>> (self=...)
    at /home/rvalls/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/result.rs:1077
#9  embassy_avr_as5600_encoder::____embassy_main_task::{async_fn#0} () at src/main.rs:63
(...)

Not to mention that real sensor inputs (i.e I2C) would probably require generating some captures in .vcd's to appropriatedly simulate and debug in some situations :-/

Please do share that custom panic_handler @DaanDekoningKrekels, probably I can use it myself for some annoying panic I cannot easily delve into via ufmt::writeln! in my program (my Mega2560 panics while trying to read I2C angle position on a magnetic encoder)... which is most probably that u16 value being None instead of Some()...

EDIT: Turns out there's JTAG in the AtMega2560 but it's a bit involved to enable, seemingly requires an Atmel-ICE dongle and only works on Atmel Studio 7 (Windows).

/cc @jubeormk1

[DaanDekoningKrekels]

Hi Brainstorm,
I wrote a bit about the panic handler in my thesis. It prints the file and line where the panic occured using ufmt::uwriteln!. Code and a short explanation in Dutch can be found here: https://bachelorproef.daandekoning.be/einddocument/content/documentatie/atmega128a-hal.html#panicking

I used it here, but this part fell out of scope for my thesis because of the difficulties with debugging that's why the code is a mess. https://bachelorproef.daandekoning.be/rustdoc/src/alpha_transp_rust/main.rs.html#554