Activity for AVaRICE
-
Viorel created ticket #41
implicit function declarations in configure logs when compiled with clang 16
-
DySprozin posted a comment on ticket #29
@kaml Many thanks for the patch! Its working! Awesome!!!
-
Joerg Wunsch committed [r427]
In jtag3::deviceAutoConfig(), fix constructor syntax
-
Joris Putcuyps committed [r426]
Reformat device code
-
Remove unused eraseProgramPage().
-
Type for daisy chain
-
Test product_string not nullptr before comparison
-
No longer need the fill_b macros
-
Pass xmega to base Jtag
-
Some exceptions cleanup.
-
No longer need the pragma in jtag.h
-
Improve expected device name handling
-
Some cleanup
-
Fix jtag device loading due to switching to pointers!
-
Also make jtag1 description a pointer so it can be optional, deprecating the MKII flag
-
The xmega_dev_desc val means it is a xmega
-
xmega device description is optional, use a pointer for that
-
atxmega128a1 revisions only differs in signature
-
Split the large MCU details files into 1 file per device
-
Some const correctness
-
Clear Jtag class type names
-
Cleanup jtag device creation
-
More code cleanup
-
Remove deprecated target flash methods
-
Consistent file naming for jtag1
-
Uniform way to lookup device details
-
More clang-tidy hints and other C++ improvements
-
Fix gdb monitor call using the wrong length.
-
Deprecate target programming
-
Clang-format all relevant files to start with a clean layout
-
Major cleanup
-
Apply a large number of clang-tidy hints, mostly NULL,0->nullptr
-
Support code formatting using clang-format
-
Prefer the modern, widely supported now, C++17 version
-
Update script so it works with python3 (python2 is being deprecated globally)
-
Remove old C-style empty method arguments
-
Start personal dev branch
-
ATmega328 entry for avrdude.conf
-
Correct. Besides, the ATmega328 used to be supported by AVRDUDE already by the time this patch was submitted.
-
I think this patch is related to avrdude, not avarice?
-
avarice segmentation fault
-
Fix #29 avarice segmentation fault
-
I've attached Kamil's patch.
-
Kamil's fix does solve the segmentation fault and I agree with the explanation and patch.
-
Kamil's fix does solves the segmentation fault and I agree with the explanation and patch.
-
I just did a small test with my Olimex Jtag mkI on Manjaro linux and also get the segmentation fault. Will see if Kamil's fix solves it. Program received signal SIGSEGV, Segmentation fault. 0x0000555555593cb3 in jtag::layoutBreakpoints (this=this@entry=0x5555556d92e0) at jtaggeneric.cc:878 878 if (deviceDef->device_flags == DEVFL_NO_SOFTBP)
-
Cannot compile avarice-2.14.tar.bz2 due to '__unused'
-
Yep, it is. Feel free to close this bug ticket.
-
Is this not fixed in r390?
-
AVaRICE 2.14 won't compile on Arch Linux
-
Fixed by patch #40
-
Remove old style exception throw specifier
-
As simple as such. ;-) Thanks a lot, applied in r391.
-
patch #40 Remove old style exception throw specifier
-
Remove old style exception throw specifier
-
I'm willing to review and apply a patch, but my C++ knowledge (in particular regarding modern C++) is close to 0, so without a lot of Internet research, I wouldn't know how to fix that properly right now.
-
I also prefer that, but this is the smallest step with the least amount of risk. When I have time I'll have a stab at a bigger patch if someone is willing to review and apply it?
-
Well, frankly, I'd very much prefer to have a patch fixing the source code so it compiles on a newer compiler without warnings, rather than back-dating the compiler.
-
I've created a small patch to specify an older C++ standard.
-
<REDACTED> created ticket #12
Option to Allow AVaRICE to Continue Running After the Debug Session has Closed
-
<REDACTED> posted a comment on ticket #34
A temporary solution was found to be to change the C++ compile version to be C++ 14. On Arch Linux, for building this package from the AUR the solution is to add CXXFLAGS="-std=c++14" to the top of the build() function in PKGBUILD. From this, I can venture a guess to say that AVaRICE just needs to be updated to support C++17.
-
<REDACTED> created ticket #34
AVaRICE 2.14 won't compile on Arch Linux
-
Giles Atkinson created ticket #33
Problem with "info io_registers"?
-
JoeS posted a comment on ticket #32
To get it successful compiled and installed for use with AVR Dragon, I had to do the following: * Install libusb-dev (libusb1.0-0-dev was already installed but not used) * Remove the __unused patterns in all sources like mentioned here * Remove the file avarice.spec. It is mistakenly included in the archive, but should be generated by configure * Then run: ./configure make sudo make install In case of errors (especially after installing libusb-dev) make clean was not sufficient. I had to remove all...
-
Maximilian Gerhardt posted a comment on ticket #31
For installing you need to give it the install directory in the initial ./configure command, like mkdir ~/avarice_installed and ./configure --prefix ~/avarice_installed and then make && make install. But for me, I just grabbed the executable in src/avarice.
-
Hi Maximilian, randomly I raised a ticket on same issue at nearly the same time. I also tried to remove "__unused", it compiled, but nothing was installed using make install. Have you the same problem? Regards, Jörg
-
Compile failed on Ubuntu 20.04
-
Support UPDI programming
-
Cannot compile avarice-2.14.tar.bz2 due to '__unused'
-
2.14 compiling issues and atmel-ice usb not found
-
You write you are trying to compile AVaRICE 2.14, but your final command messages indicate it's actually 2.12. Also, all the compile errors you mentioned seem to be old ones that have been fixed in the current codebase.
-
Christian H created ticket #30
2.14 compiling issues and atmel-ice usb not found
-
avarice segmentation fault
-
My own JTAGICEmkI clone is ready now. However, I cannot seem to make it stop at any breakpoint. I don't have the time to track that down right now, but will for sure keep the bug report open so it can be fixed before the next release.
-
Thanks for the analysis! My own mkI clone is still on its way, once here, I'll test that. @Mate Varga: the fix will the surely be in the next release (whenever that will happen ;). For the time being, you could try whether Kamil's fix solves your issue.
-
Kamil Lewandowski posted a comment on ticket #29
Hi, I have the same problem too. I was able to track down the problem. The problem is that for JtagICE mk1 in the jtag1 class there are 3 methods for handling breakpoints: addBreakpoint, deleteBreakpoint, updateBreakpoints. updateBreakpoint for jtag1 uses its own structures filled with addBreakpoint and deleteBreakoint, and should use the "bp" structure. The quickest fix for this error will be: --- a/avarice/src/jtag.h 2020-10-01 18:42:10.267554671 +0200 +++ b/avarice/src/jtag.h 2020-10-01 18:43:28.447174612...
-
Sorry, since your trace doesn't have debugging symbols - I need to build my own mkI ICE clone first, and then try reproducing the error.
-
Mate Varga posted a comment on ticket #29
hello, Is there any update? Thanks. Best regards, Mate
-
Ah yes, sorry, I tried with direct path like you wrote now. I just copy pasted what you wrote before.
-
Nope, the current version is supposed to support the "MkI" version, so we either have to declare it unsupported (and refer to an older version then), or we fix the bug. I'd prefer the latter, and as such, your bug report is welcome. But unless you can trace that yourself completely down to the respective source code line, I have to reproduce it first.
-
Turn that "gdb avarice" into a "gdb ./path/to/your/compiled/avarice". I'm afraid you might debug the one found in $PATH rather than your compilation.
-
Or maybe should I try an older version of avarice?
-
Yes it is included. Am I need to load the .elf file symbols somehow? Because If I execute these command, the .elf file is not referenced. gdb avarice (gdb) run -1 -j /dev/ttyUSB0 :4242 -P atmega32 -d
-
Offhand not. The stack trace has symbols now, but it lacks debugging symbols (compiler option -g). Unfortunately, jtag::layoutBreakpoints() performs a lot of actions on arrays where a memory access violation could happen. Can you verify your compilation included a -g option? I'm afraid I first have to build my own ICE for that.
-
Do you have any idea?
-
Ah sorry I used the wrong one. Now it seems I have something readable.
-
No problem. I have a compiled one in my Downloads folder. It seems that I have the same output that way. Am I using the command correctly to startup gdb with avarice?
-
Unfortunately, I forgot: without AVaRICE having full debugging symbols, the stack trace is pretty useless. :-( Can you compile AVaRICE yourself from sourcecode? If so, please re-run the test, and use the in-tree version (rather than an installed one) for the stack trace.
-
Thank you very much, that would be great! Please see the bt output attached.
-
OK, an old ("mkI") - I don't have one here readily available for testing. Maybe I can jumper some compatible clone on an STK500. In order to debug AVaRICE, you have to run it under control of the host system's GDB (not AVR-GDB). Just start it (in a separate terminal window) like gdb avarice (gdb) run -1 -j /dev/ttyUSB0 :4242 -P atmega32 -d then connect AVR-GDB to it. Once it crashed, type bt in that GDB window.
-
I'm trying to make this work on an Arch Linux. I'm using the following command: avarice -1 -j /dev/ttyUSB0 :4242 -P atmega32 -d So I'm using an mKI adapter. I just attached the whole output of AVaRICE. How can I check the backtrace with avr-gdb? Because after the "Segmentation fault" I can't check backtrace I just got "No stack." error message. (see picture attached)
-
I'm trying to make this work on an Arch Linux. I'm using the following command: avarice -1 -j /dev/ttyUSB0 :4242 -P atmega32 -d So I'm using an mKI adapter. I just attached the whole output of AVaRICE. How can I check the backtrace with avr-gdb? Because after the "Segmentation fault" I can't check backtrace I just got "No stack." error message. (see picture attached)
-
Well, a lot of information is missing. What kind of debug adapter is used, what's the exact commandline to start AVaRICE? Ideally, I'd be interested in a stack trace from the coredump; GDB can be used to analyze the coredump file
-
avarice segmentation fault
-
Tobias Frost posted a comment on ticket #39
On Thu, Sep 17, 2020 at 08:36:39PM -0000, Joerg Wunsch wrote: status: open --> closed assigned_to: Joerg Wunsch Comment: Well, the AX_GCC_VAR_ATTRIBUTE was missing in my autoconf version. Thus I decided it's easier to simply replace__unused by __attribute__((unused)) in the few places where it's being used. Thanks Jörg for fixing it that fast ;) I was just unsure if hardcoding was ok with you, I assumed you have some compiler that understands __unused natively and I didnt want to break stuff on your...
-
Compilation error in jtag3io.cc: (avarice 2.14)
-
Well, the AX_GCC_VAR_ATTRIBUTE was missing in my autoconf version. Thus I decided it's easier to simply replace__unused by __attribute__((unused)) in the few places where it's being used.
-
patch #39 Compilation error in jtag3io.cc: (avarice 2.14)
-
Compilation error in jtag3io.cc: (avarice 2.14)
-
AVaRICE released /avarice/avarice-2.14/README.txt
1 >
