@pfeerick could you try to compile it on Windows? We would bee glad if share your experience. So, I don’t see any problem to add 1-Click simulation for AVR.
Thanks, @msquirogac for the research!
I uploaded a minimum example to test simavr and platformio here. There are two examples, the main difference is that one of them enables the VCD output and the other doesn’t, but both of them are able to debug.
So far if the avr_mcu_section.h header and its macros aren’t used then the debugger works without major problems (besides ones stated in previous posts), both with and without the Arduino framework.
However, if those are included, which is necessary in order to get plots like this VCD, then things get a bit more challenging.
The first problem is that those macros do heavy use of “non-trivial designated initializers” and it looks like avr-gcc has support for it but avr-g++ doesn’t. That means potential problems with Arduino projects, or with projects that use avr-g++ compiler. A workaround would be to change the extension from .cpp to .c but that would be possible only for projects that don’t use specific c++ structures.
The second problem is the placement of the mmcu section inside memory. For what I understood those macros place variables and strings in a section called mmcu, then the simulator recovers them from the elf binary to configure and dump data from the specified memory addresses.
The tricky part is that any unused variable is removed when compiling, that’s why the command -Wl,–undefined=_mmcu,–section-start=.mmcu=0x910000 is added to the compiler, which I found after reviewing some examples in simavr. I also found that the -Og also has some effects so it should be left aside?
After crossing that problem a third one arises with the GDB command load. I guess that the address 0x910000 is outside the memory map of the controller and GDB refuses to load it but I’m not sure. A workaround would be to comment out the load command but I don’t know what would be the implications of that.
After all of this, the VCD capability is enabled and works fine. By the way, the generated trace file has a .vcd extension and can be open with gtkwave.
@ivankravets , should I open an issue on Platformio’s GitHub repository requesting this feature? and in which one should be, platform-atmelavr?
I would like to keep contributing to this idea and I think the repository could be a better place.
Hi @msquirogac! Thanks for your hints about simavr. I’ve already added initial support so we can use it as a debug server. But it looks like there is a problem with simavr on OS X. I simply cannot execute command load from the avr-gdb, it fails with the following error:
Remote target does not support flash erase
Any thoughts?
Also filed an issue in their repository:
@valeros, Maybe is a thing of avr-gdb itself?
I got two different results depending on which version of avr-gdb I used in the same computer and same OS. I didn’t have any problem with the version built-in platformio, but the same error appeared with the one from my old Debian.
Edit: I’ve just tested the upstream branch, the error doesn’t appear on my Debian box.
@msquirogac It works on my Ubuntu too. But on OSX this error persists. I tried different versions, even with avr-gdb + simavr from brew.
So if anyone is willing to test the debug using simavr on Windows and Linux, please try the following config:
[env:simavr]
platform = https://github.com/platformio/platform-atmelavr.git
framework = arduino
board = AT90CAN32 ; Change to desired board
debug_tool = simavr
1 Like
@valeros Maybe it’s a thing of the compilation flags of avr-gdb itself which can be recovered with this command:
avr-gdb -ex "show configuration"
Platformio’s avr-gdb for linux has this configuration (this one works for me):
GNU gdb (AVR_8_bit_GNU_Toolchain_3.6.2_1759) 7.8
This GDB was configured as follows:
configure --host=x86_64-pc-linux-gnu --target=avr
–with-auto-load-dir=$debugdir:$datadir/auto-load
–with-auto-load-safe-path=$debugdir:$datadir/auto-load
–without-expat
–with-gdb-datadir=/home/toolsbuild/workspace/avr8-gnu-toolchain/avr8-gnu-toolchain-linux_x86_64/share/gdb (relocatable)
–with-jit-reader-dir=/home/toolsbuild/workspace/avr8-gnu-toolchain/avr8-gnu-toolchain-linux_x86_64/lib/gdb (relocatable)
–without-libunwind-ia64
–without-lzma
–without-guile
–with-separate-debug-dir=/home/toolsbuild/workspace/avr8-gnu-toolchain/avr8-gnu-toolchain-linux_x86_64/lib/debug (relocatable)
–with-zlib
–without-babeltrace
While my Debian’s avr-gdb has this other (this trigger the same error as you):
GNU gdb (GDB) 7.7.1
This GDB was configured as follows:
configure --host=x86_64-linux-gnu --target=avr
–with-auto-load-dir=$debugdir:$datadir/auto-load
–with-auto-load-safe-path=$debugdir:$datadir/auto-load
–with-expat
–with-gdb-datadir=/usr/share/gdb (relocatable)
–with-jit-reader-dir=/usr/lib/gdb (relocatable)
–without-libunwind-ia64
–without-lzma
–with-separate-debug-dir=/usr/lib/debug (relocatable)
–without-zlib
–without-babeltrace
Oh… nice! So you were able to make a windows binary… I was having trouble as stuff was missing, sites with pre-built libraries no longer having valid SSL certificates, yada, yada. Linux was straightforward, just wasn’t what I wanted to try out…
And to boot, I was just going to try this, and now VSCode 1.45.0 is giving me The task provider for "C/C++" tasks unexpectedly provided a task of type "shell". FFS can’t VSCode (or is it the C/C++ extension this time?) do just one update that doesn’t break platformIO? 
So, PlatformIO is still working dispute that error… but I get this… apparently I don’t qualify! 
PackageManager: Installing tool-simavr @ ~1.6.0
Error: Could not find a version that satisfies the requirement '~1.6.0' for your system 'windows_x86'
The terminal process terminated with exit code: 1
@valeros, is this package compatible only with x64?
@pfeerick, does this Windows x64 package work for you? Service End for Bintray, JCenter, GoCenter, and ChartCenter | JFrog
It looks like VSCode bug
Thanks for linking the github issue. It looks like the fix is pending, I replied further on the github issue just now.
That simavr executable runs on my system… which is x64 bit…
so not sure what when wrong there! 
Downloaded the package, poked
"system": [
"windows",
"windows_amd64",
"windows_x86"
],
in instead of
"system": [
"windows_amd64"
],
into the package.json and it’s running nicely so far. Just a stupid simple test…
1 Like
@valeros Some news. I’ve started to dissect simavr code, especially the code related to the GDB server. After sniffing an exchange between simavr and GDB I found that one version of avr-gdb sends the vFlashErase command while the other doesn’t, and as simavr doesn’t support said that command it triggers the error you found.
The workaround would be to find a way to avoid sending that command for this target, at least until it gets implemented. I will keep reviewing that code and maybe send PR if the author doesn’t fix it.
Edit: the load command isn’t needed if the .elf file is passed as argument to simavr
simavr -g -f <freq> -m <model> firmware.elf
1 Like
@valeros
The biggest difference between both GDB compile flags is the inclusion of the expat library, and the reason why it is used in GDB is explained here.
To be able to write into flash memory, GDB needs to obtain a memory map from the target.
Also:
GDB assumes that areas of memory not covered by the memory map are RAM, and uses the ordinary ‘M’ and ‘X’ packets to write to addresses in such ranges.
So not including that lib would make avr-gdb unable to use of all the vFlash commands, or make it believe that everything is RAM, which is exactly what I captured with the sniffer. The version with expat tried to use vFlash commands while the version without it used only ‘M’ commands and the later are supported by simavr.
Could you provide a PR to simavr repository with a fix? We can rebuild binary for macOS from your branch. Thanks!
We use official Microchip toolchain to keep compatibility with Arduino projects. I recommend to keep the same official toolchains for all systems but add fix to simavr which will just ignore this “Erase” command.
1 Like
Thanks! Fixed! 
1 Like
@ivankravets I’ve started to work on that, meanwhile you could try the other workaround without having to recompile anything. That way we can start testing on OSX before the patch is ready.
simavr -g -f <freq> -m <model> firmware.elf
@ivankravets @valeros I’ve just uploaded a patch for issue #371 to my fork, please test if it works on OSX.
The fix consists of faking the memory map reporting the Flash section as RAM which forces avg-gdb to use only the M command instead of vFlashErase, vFlashWrite and vFlashDone.
I’ve tested with both my versions of avr-gdb and the load command doesn’t trigger that error anymore.
Nevertheless, I will keep working on this and also on the issue #370, so the commands monitor reset and monitor halt get supported too.
2 Likes
@ivankravets @valeros
Done, I’ve just added a fix for issue #370. Now pio_reset_halt_target and pio_reset_run_target can be populated like this:
define pio_reset_halt_target
monitor reset
end
define pio_reset_run_target
monitor halt
end
target remote :$DEBUG_PORT
$LOAD_CMDS
$INIT_BREAK
About the fix, monitor reset will put the processor to a initial state and pause, while monitor halt will gracefully terminate all execution and close the program.
Please, rebuild from my fork and test if there are any other bugs.
1 Like
@msquirogac! Many thanks for such a great contribution, it works much better on OS X, so we’ve used your fork as the source for tool-simavr package! One thing though, it looks like GDB is not able to produce disassembly for the uploaded firmware, on OS X GDB complains:
Unable to disassemble: Cannot access memory at address 0x800900 (from data-disassemble -s 0x000008b8 -e 0x0000091c -- 2)
on other platforms it mostly returns NOPes:
0x008007d2: 00 00 nop
0x008007d4: 00 00 nop
Any ideas?
Anyway, thanks again for efforts!